Date: Mon, 20 Jul 1998 21:48:11 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Brett Glass <brett@lariat.org> Cc: security@FreeBSD.ORG Subject: Projects to improve security (related to C) Message-ID: <v04011703b1d98657693f@[128.113.24.47]> In-Reply-To: <Pine.BSI.3.96.980720142915.6556A-100000@anchovy.orem.iserver.com> References: <199807201732.LAA20377@lariat.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Jul 1998, Brett Glass wrote: > 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. I agree with this. At a different time, and a different place than the security mailing list, I would tempted to go into the details of just how much I agree with it. 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 living with C for many years whether we like it or not. This particular problem was in QPOPPER. Would you have been happy to do without any POP service until someone had the time to rewrite that in some other language? 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. 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 rewrite everything, there still could be things we could do to force programmers to at least *think* about some of the most common pitfalls. 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 that by default, applications can not execute code in a stack, but that they just need to make some system call for that to work? Is that feasible? Would it save us from some security problems? For instance, does QPOPPER (that one specific application) really need to execute any code on the stack? Another idea might be to have a #define that makes it more tedious to use routines like "sprintf". It's one thing to have a page of wise programming tips stashed away somewhere, and quite another if the program you are porting won't compile (a very effective reminder) when it includes calls to sprintf. I'm thinking of some flag that a person could set as a part of CFLAGS in /etc/make.conf, and which would turn all these more-dangerous routines into compile-time errors. Not warnings. Errors. And then for people in a hurry, allow a second #define for each routine, so you can stll use that routine if you "need" it's "power" (translation: you don't have the time to rewrite all of it). Say, a global flag (effecting all such risky routines) called "DO_NOT_ALLOW_BAD_PRACTICES". And then a escape-hatch define for each routine, such as "ALLOW_BAD_PRACTICE_OF_USING_SPRINTF". People will switch to snprintf just to avoid typing such a stupid name... And if they *do* #define such variables, at least you have a red flag sitting in the source code for that port which someone else could find with a 'grep' if they feel ambitous some day. (note that this means *one* grep, one for 'ALLOW_BAD_PRACTICE', would find references to *all* of these risky routines...). I have no idea if these suggestions are feasible, or if they'd really help all that much. On the other hand, I do think it is valuable to consider security issues related to the C language. If we argue which language is the best, we'll spend six months just arguing with each other and not really improve anything. If we just throw up our hands and pretend C is perfect, then we will just keep having these security issues pop up when we least want them to. It'd be better to come up with suggestions of realistic projects we could do, and which might produce some positive results. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute 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?v04011703b1d98657693f>