Date: Tue, 21 Jul 1998 15:37:15 +0200 From: Martin Cracauer <cracauer@bik-gmbh.de> To: security@FreeBSD.ORG Subject: Re: Projects to improve security (related to C) Message-ID: <19980721153715.A714@bik-gmbh.de> In-Reply-To: <v04011703b1d98657693f@[128.113.24.47]>; from Garance A Drosihn on Mon, Jul 20, 1998 at 09:48:11PM -0400 References: <199807201732.LAA20377@lariat.lariat.org> <Pine.BSI.3.96.980720142915.6556A-100000@anchovy.orem.iserver.com> <v04011703b1d98657693f@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
All this talk about "unsave" C being the reason for breakable programs is mislead in my opinion. If you switch to a language with bound checks, you will depend of the language runtime and I think that makes matter worse, not better. Even if you wrote correct code yourself, you might be vulnerable. Examples: Sun's JVM isn't a real example of excellent memory management, I would bet it has buffer overruns as well. I certainly trust my own C coding in usualy chunks more than trust the JVM coding for the entire runtime. If you use a highly-optimizing Just-in-time compiler for whatever language you will have the compiler remove bounds checks in cases when it thinks it is save. This is a very complex task, hopefully not so complex that the program doesn't work, but solving this task so that the system is resistent against intentioal attacks by highly-skilled people is a different matter. In Common Lisp you usually have a switch to control bound checking at runtime, a high-performance network server software will probably have switched it off by default. As comfortable as Common Lisp with is default to bounds checks may be, as unintuitive can it become when you want to know exactly what the compiler did with your code. Also, with garbage-collected runtimes denial-of-service attacks become easier. I'm certainly not a gainst garbage collection in general, but IMO it somewhwat depends on choosing the right GC system for the task and intended input. If I had to choose GC scheme that might be faced with input that has no other intention than to cause excessive GC pauses, I wouldn't be so sure how much research that would take. In languages that support threadings, things become even worse, since in most (all?) major runtimes all threads are being stopped for GC. Not to speak of dynamically code loading (Java) or generating (Common Lisp). Considering how much time of highly-skilled people is being put into conventional buffer-overrun exploits, I certainly can't be sure to protect my dynamic-code scheme when the same enery is being focused on attacking it. As Java has shown a number of times. I love a number of languages that have bounds checking, but security is one reason I mainly code in C. It's not that difficult to protect your code from being tricked into something else, at least with regards to buffer overruns if your knowledge is somewhat adaequate for the task at hand. It is much more difficult to judge over your language compiler and runtime. You might say: Yes, but if I run third-party software I feel better if it's written in java than in C, because the author doesn't have sp much opportunity to do things wrong, I'd say, don't run code you don't trust. Security problems are more than buffer overflows. If some person isn't capable or willing to avoid buffer overflows in C (as I said, one of the easier solvable security problems), he/she probably doesn't have a clue or doesn't care about other problems as well. So don't run the code. You might even use the easily reviewable bounds issue to judge over the code. If he/she didn't get that one right, you know what you will get. If it's written in Java, you don't have such an easy indicator. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer BSD User Group Hamburg, Germany http://www.bsdhh.org/ 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?19980721153715.A714>