Date: Mon, 20 Jul 1998 11:32:51 -0600 From: Brett Glass <brett@lariat.org> To: Paul Hart <hart@iserver.com> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, dg@root.com, security@FreeBSD.ORG Subject: Re: The 99,999-bug question: Why can you execute from the stack? Message-ID: <199807201732.LAA20377@lariat.lariat.org> In-Reply-To: <Pine.BSI.3.96.980720090640.6101B-100000@anchovy.orem.iserv er.com> References: <199807200140.TAA06705@lariat.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 09:35 AM 7/20/98 -0600, Paul Hart wrote: >Brett, this type of exploit has been around for many years (one element of >the original Internet worm was based on a buffer overflow in fingerd). >And each time someone gets hacked they have the same grandiose visions for >building elaborate kludges to make sure they're never hacked again. But, >alas, these visions are only Band-Aid solutions. The real problem is >flawed application code. I would argue that the real problem is unsafe tools. C and its libraries have, from the start, been rusty, and unsafe, with no safeguards against cutting one's head off. Heck, the C language was more than 20 years old before compiler writers even thought to warn programmers that they might have typed "=" instead of "=="! And that's one of the few warnings against serious lexical/semantic problems that has EVER been put in. Believe me, I would not use UNIX were the currently available alternatives not so much worse. What I've always wanted (and I find it hard to believe that no one has done it) is opt for an OS written in a language designed to prevent, rather than encourage, the creation of the sorts of bugs we're seeing here. But, of course, people don't take the long view; they ignore security and reliability at the design level. It makes me want to quit the business. >Instead of dreaming up fancy kernel kludges, >let's direct our efforts toward auditing code, thus attacking the problem >at the root. Quality can't (and shouldn't) be tested or audited in. It should be DESIGNED in. The development tools we use to develop the system in the first place should not admit themselves to such easy creation of dangerous holes and bugs. >I don't want to seem callous to your plight because I know how you must >feel, but does not the old adage "once bitten, twice shy" apply to your >situation? You were hacked. Now you know better. Can we assume that >this will not happen again? No, we can't. I'm sure there will be more holes -- both in third party utilities and in FreeBSD itself -- that will leave my system vulnerable. (As I mentioned in an earlier message, we are even irresponsibly TURNING OFF features of the hardware that are designed to catch many such problems.) And I will not have the time to audit all the code or rewrite it to prevent that. Unless I abandon my livelihood (sorry, guys, I'm not rich), I'll be forced to rely on systems that are built without reliability and security as Goal #1. Any change in the status quo will require a change of attitude -- a level of professionalism that I haven't seen yet in most developers. And I don't see that maturity coming. Look at all the fuss I've encountered when asking that JUST ONE AVENUE OF ATTACK be closed! I keep hearing excuses of the form, "Well, there will still be other ways to break in, so why fix even one?" Guys, we have to close them ALL. --Brett Glass To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807201732.LAA20377>