On Thu, Apr 20, 2000 at 07:06:54PM -0700, lamont@icopyright.com wrote:
> Readers of this thread might want to hop over to VULN-DEV where I've been
That's vuln-dev@securityfocus.com, where discussions of
vulnerability development takes place, for those who don't know
what what he's referring to.
> actually trying to impliment various non-exec-stack smashing techniques
> with the help of a few readers there. Pretty much what Michael writes is
> correct, its not too hard to get around non-exec-stack protection and it
> looks like even with the way Solar Designer's patch moves libc to an
> address with a zero you can still jump to mapped dynamic library calls to
> do what you need. So, on x86 he's entirely correct. On Alpha its not so
> simple and its definitely not so simple that you can
> write-once-run-anywhere an exploit. Also, for a binary that doesn't use
True... Bit of an oversimplification on my part which is rather
obvious just from the point that not all systems have inetd in /usr/sbin
or call it by that name. So, of course, it's all platform dependent
anyways (think endianness and address size too).
> the system() call, you can't use it either and you're stuck doing
> something like a strcpy() of shellcode to someplace executable and running
> it there.
> I'm definitely wishing that they'd release the StackGuard port to egcs
> pretty soon. That isn't a silver bullet, but it does appear that for
> vanilla buffer overflow coding mistakes it will protect you.
Have you seen the new release from Bell labs? Here's another
twist to out foxing the buffer overruns.
http://www.bell-labs.com/news/2000/april/20/1.html
I suspect that this isn't a silver bullet either but it looks like
it comes with less of a performance price tag than stack guard, should be
damn near as effected as stack guard, be one hell of a lot MORE effective
than the NES and LWN patches, doesn't require kernel mods like the
mobile stack starting point, and doesn't require recompiling all the
applications.
Anyone got comments on the Bell Labs approach?
> On Tue, 18 Apr 2000, Michael H. Warfield wrote:
> > On Tue, Apr 18, 2000 at 05:38:37AM -0700, Linda Walsh wrote:
> >
> > > -- Vandoorselaere Yoann wrote:
> > > > Agree,
> > > > but executable stack will, *in all case* give a false sence of security.
> > > ---
> > > Just had to comment on this "false sense" stuff. Anything that
> > > makes it more difficult for someone to break in "raises" security. There
> > > isn't a binary value of security where a system goes from "unsecure" to
> > > "secure". It is a continuum of increasing security. Having a non
> > > executable stack is like hiding the shadow file. The don't make your
> > > system secure, but both make it more difficult for certain types of
> > > hacks to occur. Like cryptography -- it's not 100% secure -- it just
> > > delays an attacker (hopefully for long enough that it's not worth it to
> > > the attacker). But given the possibilities of quantum computers, today's
> > > key's will seem like yesturday's 32-bit keys. Nano-computers w/more power
> > > than today's fastest. Hello Borg, here we come. We better hope we have
> > > alot more security on the internet before then...:-)
> > > -l
> >
> > I use to be in the same school of though on this vis-a-vis
> > the non-executable stack and then saw one example that changed my mind
> > forever. It's basically a proof that for each and every executable
> > stack exploit, there must be at least one non-executable stack exploit
> > that is as easy or easier to impliment (no assembly required :-) ) than
> > the executable stack exploit. All it requires is two addresses and a
> > string for the payload of the exploit. The addresses are the address
> > to access the system call and the address of the string and would be
> > platform, application, and implimentation specific. Here is the string:
> >
> > echo "2222 stream tcp nowait root /bin/sh sh -i">> /tmp/h;/usr/sbin/inetd /tmp/h
> >
> > Smash the stack so the function returns back into the system()
> > function with the parameter pointing at that string and it's game over.
> > The attacker now can have as many shells on your system that he wants
> > and you didn't execute a single byte of code on the stack.
> >
> > I use to think that making the stack non-executable would at
> > least make it tougher. The existance of such a simple payload requiring
> > no assembly language work at all, points out just what a lie that idea is.
> > Sad to say but non-executable stacks are no help at all.
> >
> > > --
> > > Linda A Walsh | Trust Technology, Core Linux, SGI
> > > law@sgi.com | Voice: (650) 933-5338
> >
> > Mike
> > --
> > Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
> > (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/
> > NIC whois: MHW9 | An optimist believes we live in the best of all
> > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
> >
> >
> > -
> > 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/
> >
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- 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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:18 EST