Long-lived security holes

Long-lived security holes

Posted Jun 24, 2004 18:16 UTC (Thu) by vonbrand (subscriber, #4458)
In reply to: Long-lived security holes by mjr
Parent article: Long-lived security holes

Problem with any such proposal is that it is often very hard to see exactly what the implications of a bug are. Sure, found a potential buffer overflow. Is it for real, or is impossible to get there? Is the overflow large enough to inject shellcode? Can an attacker tweak the overflowing data enough to inject shellcode? Or return into something "interesting"? Can he destroy other variables, with unforeseen later efects? And a long etcetera. To fully answer all these questions is a lot of work. Most would just fix it, make sure it is really fixed, and move on.

A long while back I looked over dip (a proggie for connecting via SLIP), found some suspicious code, and sent a patch upstream. It turned out later that this fixed an exploitable root compromise. I just did not have the expertise to check for that (neither did I have the inclination to search for exploits).

At most, you could say the bug is potentially serious... but all bugs are. If the program is SUID, or a network server, it is clearly more dangerous. But even root may run any random program (like more(1)) on non-trusted data, so...

---

(Log in to post comments)