Messages in this thread | | | Date | Thu, 30 Dec 1999 13:34:11 -0000 (GMT) | From | Anton Ivanov <> | Subject | Re: Unexecutable Stack / Buffer Overflow Exploits... |
| |
-----BEGIN PGP SIGNED MESSAGE-----
On 30-Dec-1999 Khimenko Victor wrote: > In <Pine.LNX.4.10.9912291834180.2558-100000@anime.net> Dan Hollis > (goemon@sasami.anime.net) wrote: >> On Wed, 29 Dec 1999, Horst von Brand wrote: >>> If you want to install it, go right ahead: this is free software in a free >>> world. It might help you some for some time, but does _not_ help everybody, >>> at least not in the long run. > >> Thats why it should be a kernel *option*. Then everyone can enable it >> except you. > > No. It SHOULD not be kernel option. Linus already said final verdict on > subject: no way for standard kernel. If you are scilled enough to apply > patch you at least not newbee, who thinks "hey, it's some security tool... > I my enable it just in case". And Linus personally thinks that subj will > not improve security much (he showed idea how to convert "normal" exploit > in "unxecutable stack" exploit if I recall correcly). It's general > technique_: > (when standard glibc is used: you DO NOT NEED TO EXECUTE anything except > ONE syscall to make /bin/sh suid -- you just push arguments for > libc's internal function __chmod in buffer, push return address for > __chmod there (with right offset, of course) and viala: you have suid /bin/sh > to start with (server will crash afterwards but it's other story). Is it > REALLY > that harder then playing tricks with executable stack ? Or all you vulnerable > daemons are not using shared libc ??? Get real. > > P.S. It's just simple sample. Of course this generalisation does not work for > remote attacks -- you should be little more clever. LOTS OF attacks can be > similarly generalised: just find appropriate routine in glibc -- there are > enough interesting funstions. Just VERY few will be unexploitable with > unxecutable stack at all. And they WILL be if unxecutable stack option will > be popular enough. And such versions will be available for downloads in > "usual > places". Now we are in square one.
Nope.
See Alan's mail, same thread as well as a few others. Solar's patches also realign where your libs are mapped. As a result the offset you are referring to always contains a 0x00. So no exploit. Bad luck...
I maybe mistaken, but the only currently well known buffer overrun cases that do not fall here and where you can pass a null inside the code and do the "return from libc trick" are some sendmail and imap exploits where the exploit code is decoded from a quoted or encoded fragment (mime decode/encode overruns and friends). And these are very version/compiler speicific and are actually a very high bar for the average kiddiez
- ---------------------------------- Anton R. Ivanov IP Engineer Level3 Communications RIPE: ARI2-RIPE E-Mail: Anton Ivanov <aivanov@eu.level3.net> @*** Drucker's Dicta: (No 5 of 15) *** Marketing is a fashionable term. The sales manager becomes a marketing vice-president. But a gravedigger is still a gravedigger even when he is called a mortician -- only the price of burial goes up.
- ---------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org
iQEVAwUBOGtfUSlWAw/bM84zAQHU/wgAoqrNSP+K1hjW62rclm2ECcCzSZ16rZkb K/EA/o33YkCnAKCDVj4I+GUAPnJOIPiDoqPP2+Q0O3d9mH2+Io1aVT9P+c4fCNVR RdO4wUQlnFicVwJtbZX++4kZd6abffxVJs3uX0hDygNKwCVPY6GSvkKAtswj+Mc2 Cy+K3yNi8QDJV8RqdF6WoZjP5Nrn5GJ5C4j32mESrxBsurx1kLVZ3VVW180mt/+2 LAuqXyhZERNBUtXjaqaiXN4QkEyqVyGdvoUHIIBMy7D65lIx7IEz19Mq9aLTPIK8 2j0PJ36HaVih+V4Rl7OPS/wR3s/xmSZN/RniV1bnE3B6TtUIBzriOA== =3+Jj -----END PGP SIGNATURE-----
- 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.tux.org/lkml/
| |