buffer overflow - prunik

[Milan Kerslager]

On 3 Aug 2000 uhlar na fantomas.sk wrote:

> Solar designerov patch (http://www.openwall.com/linux/) urobi taku srandu ze
> stranky v pamati na ktorych je zasobnik (teda tie kam sa vacsinou dzubne ten
> vami zadany kod) oznaci ako nespustitelne a procesor pri pokuse o spustenie
> vyvola vynimku. davno som nekukal architekturu 386 a ktosi vravel ze sa to
> robi cez nejaku srandu, zevraj ochrana tohoto nie je v x86 celkom cista a da
> sa obist, v kazdom pripade to odstranuje vacsinu (velku vacsinu) exploitov.

To je evergreen v linux-kernel. Non-executable patch v oficialnim jadre
nebude, protoze se da obejit. Proto existuji ruzne patche na non-exec
stack, ktere umoznuji adminum odchytavat pokusy o "testovani" exploitu na
jejich systemu. To je uzus, u kterem ctenar l-k FAQ vi a neda se zmenit, i
kdyz lameri to omilaji jednou za par mesicu znovu kolem dokola :-)

Prikladam mail l-k (kdyz se v nem pise o 'big performace hit' u
bound-checking, mysli se nejmene 50%, ale spise 2x az 30x zpomaleni kodu +
jeho prodlouzeni).

Je tam take odkaz "primarni zdroj" o prepisovani stacku :-)

--
                        Milan Kerslager
                        E-mail: milan.kerslager na spsselib.hiedu.cz
                        WWW:    http://www.spsselib.hiedu.cz/~kerslage/

------------- další část ---------------
>From oxymoron na waste.org Thu Aug  3 13:42:57 2000
Date: Sat, 29 Jul 2000 12:49:54 -0500 (CDT)
From: Oliver Xymoron <oxymoron na waste.org>
To: Bruce Perens <bruce na perens.com>
Cc: linux-kernel na vger.rutgers.edu
Subject: Re: Stopping buffer-overflow security exploits using page protection

On Fri, 28 Jul 2000, Bruce Perens wrote:

> Please see http://technocrat.net/964824712/ . Is there any good
> reason that we can not run Linux executables with the execute permission
> turned off, by default, on all stack and data pages? Wouldn't this stop
> buffer-overflow security exploits that try to inject executable code onto
> the stack or into function tables? i386 won't support it, but other
> architectures do.

Writable+executable isn't the problem. Scan executable for pointers to
string "/bin/sh". Locate entry point of exec in libc. Smash the stack so
that function calls exec with "/bin/sh" as an argument. Solar Designer's
patch makes this a little trickier by making libraries have zero bytes in
their addresses, but a little knowledge of the dynamic linker got around
this. Read the exploit you linked carefully - it's exploiting things that
can't be bandaided over.

As for the number of exploits this would stop, including this in the
mainstream kernel would only be a stopgap measure. All it took to open the
floodgates for stack smashing exploits was a single well-written article -
Aleph One's "Smashing the Stack for Fun and Profit". Now writing an
exploit once you find an overflow is a cookbook exercise. A 2nd edition of
the cookbook would be all it would take to render the patch meaningless.

The problem isn't Intel's fault or any OS's, it's a problem in the C
language and compiler. There are 5 fixes:

a) write safe code (which has so far proved hard)
b) compile with bounds-checking (big performance hit)
c) compile with StackGuard, etc. (doesn't stop exploits that corrupt
   other locals)
d) separate the return address stack from the automatic variable stack
   (ditto)
e) use another language (performance)

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo na vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/