Date: Mon, 20 Jul 1998 20:51:03 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: Brett Glass <brett@lariat.org>, security@FreeBSD.ORG Subject: Re: Projects to improve security (related to C) Message-ID: <27231.900993063@time.cdrom.com> In-Reply-To: Your message of "Mon, 20 Jul 1998 21:48:11 EDT." <v04011703b1d98657693f@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
> However, that entire argument would be worthless. Let us stay in > the real world for now. We have an operating system with a lot of C > code already written, and on top of that 1,000 ports, most of which > are also already written in C. There is no sense in getting into a > debate about the "best" computer language, because we're going to be Thank you, that's essentially what I just said to Brett in private email. It is highly unlikely that we're going to be rewriting FreeBSD in Java or Modula-3 anytime soon, so why even debate the point? :) > Let us ignore the language war, and just start with the assumption > that we're going to have to live with a lot of C code for a long > time into the future. Even if the entire FreeBSD project managed > to agree that some other language was better, we will still pick > up a lot of programs from other unixes. It is, in my opinion, much > too ambitious to suggest that we rewrite everything. Amen bruddah. > However, I don't want to just drop this issue either. Could we think > of projects we could do in the next few months, for instance, which > might help us to improve security? Even if we won't have time to Audit. Audit audit audit. Like I said in my previous email, just *five minutes* looking through the popper sources was enough time to have my jaw dropping in sheer horror at how badly we'd dropped that particular ball and I don't think it would take a rocket scientist to identify the top 10 ports in need of first attention. Start with ports/net and ports/mail and you'll have more than enough to work on. This whole auditing idea is also hardly new or innovative - those who remember back a year or so will recall my starting a "FreeBSD auditing project" complete with its own web page, auditors list, etc. Almost nothing came of it because people just weren't willing to actually DO THE WORK of auditing the code, they only wanted to talk about how much it was necessary. :-) > One pitfall is this ability to execute code from the stack. If it > is not feasible to completely remove this ability, because too much > would need to be rewritten, can we partially remove it? Have it so It wouldn't help you, as David has already pointed out. You'd just cause the exploit writers to hack a different region in libc and the problem would still be there. Again, it's not as if everyone needs to be a rocket scientist in order to get exploits, all you need is ONE person to hack out the exploit, using the stack or not, and the Internet will take care of the rest. Moving the symptoms of a problem has never been a more profitless exercise in history than it is right now. There's only one solution, one which OpenBSD has made significant marketing points out of, and that's to go through the code and look for holes resulting from poor programming practices. As the nature of exploits change and get harder and harder to "band-aid" over with technical trickery, this will only become all the more important and you all might as well start forming good habits now while it's still comparatively easy to jump aboard and make a difference. :-) - Jordan 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?27231.900993063>