On Tue, Apr 18, 2000 at 09:26:36AM -0700, Linda Walsh wrote:
> "Michael H. Warfield" wrote:
> > The point
> > here is that you can ALWAYS execute a command without recourse to
> > executing code on the stack under ANY circumstance where you could
> > execute a command by executing code on the stack. If you don't
> > like the system call, use another call. The increase in complexity
> > is insignificant compared to the complexity of the executable stack
> > exploits, so it's still a win.
> ---
> But buffer-stack overruns are one of the most common exploits.
> It seems making that more difficult to exploit would help. But a single
> brick does not build a wall. It's part of a wall.
But not all of them are executable stack exploits. In fact, I
could argue that the majority of the modern ones aren't even executable
stack exploits to begin with and the older ones won't work against the
modern code anyway (offsets and addresses change with each software version).
More and more of the new ones don't even bother with the old
executable code gaffs. The non-executable ones are easier to create,
more reliable, and portable to more platforms and versions. You just
have to tweek the addresses, you don't have to recode the exploit. You
can use the same code against x86, Sparc, and Alpha, you just detect
the OS and version, then adapt the addresses appropriately. The trend
is already taking place for single platform exploits.
> > Five, the non-executable stack option does not even add a layer
> > of complexity. If anything, it forces to lamers to use and distribute
> > exploits that are actually easier to develop and deploy. Instant
> > backdoor in a can. Why bother with all that assembly language gunk
> > which takes more work, when all you have to do is know where the data
> > falls (which you would need for the executable stack even more) and
> > the entry point to the system call.
> ---
> Cool! Let's help hackers save time. Let's get to the real
> hacking tools and find ways to counter them. If we don't have exec stack,
> then they'll stop wasting time there and look for a different exploit.
> As long as the stack exploit is there, though, you've left 1 window open.
No you haven't. You haven't closed squat. You've still got a hole
that's just as bing and just as dangerous as before. The end result is
still the same. The stack smash exploit is still there, just in another
form. Who cares if he executed code off your stack to screw you or if
he just daisy chained a series of call returns. As the old joke goes,
you can dress up fancy or dress like trash, you're still gonna get screwed
(old Jewish Rabbi joke referring to a tax audit).
> > 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.
> ---
> Didn't you just say above that the hackers would have to develop
> and deploy other hacking tools? That seems like at least *some* effort.
Bzzt... Wrong answer. The tools are canned and they are already
abandoning the old executable stack stuff anyways. Where do you think I
got that string, anyways? It was taken from an Apache exploit. Do you
really think that they are even going to bother writing flakey executable
code when they have these available. These things are in circulation
now. You're already a couple of years behind the power curve in state
of the art intruder tricks. You're not even slowing them up.
Even the "exec the command" is unnecessary. I'll leave it as
an intellectual exersize but with several addresses, two strings, and a
few constants, I can write to anything the process has permission to
write to. Might even be able to do better than that. Consider the havock
therein. Again, no executable stack and simple enough that any lame
script kiddie can do it.
The one thing that can help with some of these is lots of zeros
in the addresses of the library functions so you can screw up the strcpy().
Doesn't help with functions that copy memory based on size (rpc marshalling
and unmarshalling code is a prime target there where the data contains the
size of the data to be copied). Also gets more complicated with double
byte unicode functions. You can also get around a lot of these limitations
just by frontending your exploit with a loop through sscanf, but that IS a
complication (but doable if you really need those zeros).
> --
> Linda A Walsh | Trust Technology, Core Linux, SGI
> law@sgi.com | Voice: (650) 933-5338
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:13 EST