--------------A6E20F281811CD2EDAC7F4F7
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mozilla-Status2: 00000000
Message-ID: <35CA17E5.EF9A0A18@clampton.com>
Date: Thu, 06 Aug 1998 16:53:57 -0400
From: Joseph Malicki <jmalicki@clampton.com>
Reply-To: jmalickI@bigfoot.com
X-Mailer: Mozilla 4.5b1 [en] (X11; I; Linux 2.1.112 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Frost <sfrost@snowman.net>
Subject: Re: [PATCH] [SECURITY] suid procs exec'd with bad 0,1,2 fds
References: <199808061236.IAA20570@ns.snowman.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
>
>
>
> Except that the patch won't fix that. The ONLY reason the patch
> is good for anything at the moment is that hackers have yet to start coding
> around it because not all that many people have it installed. Security
> through obscourity, which is all well and good, but if you put it in the
> mainstream kernel it's no longer obscoure, the hackers will just code around
> it and you've done absolutely nothing usefull.
>
> As best I understand it this patch does NOT fix buffer overflows,
> it just makes the code a hacker has to find to run after exploiting a
> buffer overflow a tad bit harder to use.
>
> This ultimitely is a userspace problem, and NOT one the kernel CAN
> fix, installing this patch would only fix it for the week (at most) or so
> it would take the hackers to happily code around it, and post the new code
> on rootshell.
>
> Stephen
Hmm. I take it you've never written a buffer overflow. With this patch
included, it will be an order of magnitude harder to write a buffer overflow.
Let me explain how it is done:
When a function call is made, the address of the next instruction after
the CALL is pushed onto the stack, so it looks like this (ESP is the
stack pointer on Intel, that points to the top of the stack):
ESP: Return-address
Now, when the function is entered, it saves any state it needs to,
such as registers it will use (but the way I understand it, gcc assumes
that most will be trashed across a function call). It also sets up
the frame pointer. Now the stack looks like this:
ESP: old EBP
return-address
and EBP=ESP now, and local variables are next to go on top of the
stack. So now it looks like this:
ESP: buffer[1024];
int x;
old EBP
return-address
now... since, in an expand-down stack, which AFAIK most architecures
use, if you strcpy() to buffer with a string value of greater than 1024+
sizeof(int)+sizeof(old EBP), you will have overwritten the return address,
and when the function returns, it will be executing arbitrary code wherever
you pointed it to (and the obvious place is, of course, buffer). Now, a non-
executable stack would allow you to overflow the buffer, but the return
address would have to point somewhere else. Now, you may be able
to get to a buffer for another variable in the data segment, but that
depends how the application was written.
IMPORTANT::
Now, this leads to a way to have a truly secure system: an EXPAND-UP
STACK. With an expand up stack, where the ESP increments rather than
decrements on a push, you can not overwrite the return address with
the address of your own function. This could probably be implementable
as an ELF flag, or maybe as a separate "architecture" with its own set
of compiled libraries (as the current system would not work, since you
would be calling a library that uses an expand-down stack). The
Intel architecture, at least, allows you to specify an expand-up
stack via the descriptor table segment type flag by setting it up
like a normal data segment.
This may not be extremely feasible, but for firewalls etc. where Alan
recommends the patch, there could be distributions built that use
an expand-up stack, which basically eliminates the current
system of buffer overflows, completely closing a hole that has been
in existance since 1988.
Joseph Malicki
NOTE: for another way of preventing buffer overflows in
suid programs, see the Immunix project at
http://www.cse.ogi.edu/DISC/projects/immunix/
--------------A6E20F281811CD2EDAC7F4F7--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html