Re: Security in general (was Re: Proposal "LUID")

From: Michael Warfield (mhw@chaos.iss.net)
Date: Tue Apr 18 2000 - 13:03:14 EST


On Tue, Apr 18, 2000 at 11:28:41AM -0700, Steve VanDevender wrote:
> Michael H. Warfield writes:
> > I'm not arguing against any other layer than just the non-executable
> > stack option. Some would argue that it provides less than a defense simply
> > because it provides a sham or an illusion of a defense when the attackers
> > really know better. I'm not sure I totally agree with that position, but
> > I do know, now, that it offers zero protection. It closes no holes and
> > provides no increased difficulty in exploit creation or deployment. None.
> > Zero. Worthless.

> If it's really so much easier to create a stack overrun exploit that
> points a return address to the code to issue a system call in the text
> segment, why have all the script kiddies been wasting their time making
> stack overrun exploits that put the code into the stack buffer instead?

        Hindsight is always 20:20. If they knew then what we know now,
maybe they would have never bothered.

        They're largely not using executable stacks anymore. Lot's of
newer exploits are using non-executable tricks. It's really pretty common.
The exploits are easily ported to other platforms, architectures, OS's,
and versions, too. Just just have to update the magic cookie values
of the buffer smash offset, the return address and the parameter address.
Everything else (the exploit payload string) is "portable code". ;-)
Write once, run everywhere, just need a couple of fine tuning knobs
(and knowing where executables like inetd live).

> It's true that you can create a stack overrun exploit that points the
> stack frame return address into the text segment, but I think it's a
> stretch to claim that it's much easier to make that work compared to the
> traditional exploits. The reason that it's been easier to create
> traditional exploits that overwrite a stack buffer with appropriate
> executable code is that they work without having to know any details of
> the binary that is targeted and such exploits can be easily tested and
> applied remotely via the network; one finds a binary that has a buffer
> overrun that's invocable from the network, and tries a few different
> overrun strings with different offsets and padding. In fact, the same
> exploit technique can be applied to a lot of different programs with
> very little change.

        You're claiming that it's easier to create executable binaries
without knowledge of the underlying binaries? Now that's a stretch.
All you need is gdm and the binary you want to exploit. Gdb will give
you the two addresses you need and testing is a snap. You don't even
need to understand assembly language to do it. Set a trap at the entry
point to the routine you're going to trap and you've got it in the stack
frame. The address of the system calls take what, about 5 seconds to
get from gdb?

> And it's just hyperbole to claim that a non-executable stack offers _no_
> protection at all; you can only do so in complete ignorance of the
> systems that do use a non-executable stack that do resist common
> exploits.

        No... Ted 'Tso convinced me and I've seen both the proof and the
demonstration. If you have an executable stack exploit, you are positively
guarenteeded of at least one exploit, and more than likely many more
than one, which does not require executable code. I haven't heard of
a single platform where that was not true. It's even true on Windows. :-)
I saw one for Windows where the code that was exploited did a copy that
would only allow printable ASCII. With the non-executable tricks, it's
a snap since most of what you are passing IS ASCII. That vuln writer
had to pull the trick of passing his exploit through an sscanf to get
to some values he needed, but it still worked and he claimed it was less
than a couple of hours work.

        Mike

--
Michael H. Warfield,            | Voice: (678)443-6000  (678)443-6123
Senior Researcher - X-Force     | Fax:   (678)443-6477
Internet Security Systems, Inc. | E-Mail:  mhw@iss.net  mhw@wittsend.com
6600 Peachtree Dunwoody RD NE   | http://www.iss.net/
300 Embassy Row, Suite 500      | http://www.wittsend.com/mhw/
Atlanta, GA 30328               | PGP Key: 0xDF1DD471

-- 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:14 EST