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.
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.
I'm not overly familiar with the nuiances of accessing the text pages of a
running process, but it seems like at a minimum a user would already need
to be root in order to scan an executable in memory which was running as
root. Based on my understanding of the VM system, I would suspect that
more likely, a user would need to be root to read the memory of *ANY*
running process, aside from the case of one program accessing its own text
pages. So it strikes me that this would help eliminate additional cases of
such exploits. Again, please correct me if I'm wrong.
> As for the number of exploits this would stop, including this in the
> mainstream kernel would only be a stopgap measure. All it took to open the
> floodgates for stack smashing exploits was a single well-written article -
> Aleph One's "Smashing the Stack for Fun and Profit". Now writing an
> exploit once you find an overflow is a cookbook exercise. A 2nd edition of
> the cookbook would be all it would take to render the patch meaningless.
I've never really been able to understand the logic behind this
argument:
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).
Said another way, what significant drawback is there to including such a
patch into the kernel proper? Are there any? If not, would seem that
REDUCING the potential vulnerabilities would be well worth the effort,
despite the fact that they have not been eliminated.
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... I
haven't really ever been given a satisfactory explanation of the problem
with doing this, so if someone can provide one, I'm all ears. And I do
have a web browser, so links are great too... ;)
-- --------------------------------------------------------------- Derek D. Martin | Unix/Linux Geek ddm@MissionCriticalLinux.com | derek@cerberus.ne.mediaone.net ---------------------------------------------------------------- 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