On Sun, 30 Jul 2000, Derek Martin wrote:
> Yesterday, Oliver Xymoron gleaned this insight:
>
> > 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.
>
> Seems to me the user would need to be local in order to do what you
> describe, provided there was no other way of remotely, correctly
> identifying which distribution the target system was running (correct me
> if I'm wrong). So we've at least made it significantly harder for remote
> attackers to get in. This strikes me as a good thing.
So you just try your exploit n times, in order of decreasing popularity.
Or you just scan a large net, trying Redhat exploit on all of them and be
content to own only the machines running Redhat. Or.. (etc.)
> Also, scanning the executable would be more difficult if more
> distributions/administrators installed programs (especially SUID ones) as
> ---x--x--x (insert s where appropriate) preventing a user from reading the
> content of the executable file.
That's fine for a proprietary program, but not for one that's distributed
for free in source and binary forms. The attack model we have to assume is
that the attacker knows everything about your system configuration except
for passwords.
> We have holes A B and C in our dam. Hole A is very large, and it's low on
> the dam so currently lots of water is flowing through it. Holes B and C
> are maybe a little smaller and are much higher up in the dam, so it's
> harder for water to get through them, and currently very little water is
> flowing throught them, as the leakage from hole A is keeping the water
> level below hole B and C. But even though there's an easy way to fill hole
> A, we shouldn't bother because it's much harder to fill B and C (for
> whatever reason -- maybe there's a school of piranha living near B and C),
> and once we do fix A the water will start leaking through B and C, though
> probably not as quickly.
>
> That just seems ridiculous. Wouldn't you fix hole A ASAP? Certainly by
> plugging A, you have not achieved perfection, but you're a bit closer, no?
> And you have gained yourself some time to figure out how to plug holes B
> and C before exploits for them become widespread. To me, this seems like
> a Good Thing(tm).
We're not talking about single holes. We have n exploitable buffer
overruns. The non-exec patch will leave us with n exploitable buffer
overruns next week and a false sense of security. Meanwhile the patch
is disgusting complex - it's like putting four deadbolts on your front
door while leaving your back door open..
> It also seems to me that the text pages should not be writable. I've
> heard that they are because gcc does certain things that requires them to
> be writable, but from my perspective as a system administrator using Linux
> systems in a production environment, if those things introduce exploits
> (i.e. by forcing text pages to be writable), the drawbacks far outweigh
> whatever performance gains might be had, and gcc should be fixed...
But the exploit would still be there. Progressively crippling the system
in a vain attempt to cover up holes in poorly-written applications is not
the way to go.
Look, _auditing is a must for security_. Even languages that do
bounds-checking and taint checking or work in a sandbox are not
automatically safe. There are many other security flaws besides buffer
overflows with new classes of them being discovered regularly. There is no
substitute for regular audits.
-- "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@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:31 EST