Weekly Edition
Return to the Press page
| |||||||||||||
|
| |||||||||||||
Too cool for secure code (Register)
Jon Lasser takes programmers to task for insecure software in The Register.
"It would be nice if we could expect that our programmers would act more like
airline pilots than fighter pilots: that they acknowledge, and accept, the
responsibility that they take for the well-being of others. Until they take
this step, I doubt that the quality and security of the code that we all rely
on will improve."
(Log in to post comments)
Author confused Posted Mar 26, 2003 22:17 UTC (Wed) by ncm (subscriber, #165) [Link] Jon Lasser is confused.In particular, he confuses the distinction between safe and unsafe programming practices with the choice of language, and an makes a specious distinction between "high-" and "low-level" languages. He further fails to recognize why "the number of bugs in Web applications written in Perl and PHP is astounding" despite their supposed high level. An advantage of some languages that are very unlike Perl and PHP (such as C++ and O'Caml) is the ability to perform a variety of error checks at compile time. That these languages tend also to support "low-level" operations does not, by itself, make coding in them less safe. Rather, what matters is whether there are inherently safe ways to do all the common operations a programmer needs to do. What Jon Lasser should call for, if he wants to be taken seriously, is for better use of well-tested libraries that present high-level interfaces for common functions. Safe libraries may be written in any language strong enough to support a sound library interface. The more error checking that can be automated or obviated, the safer the code can be. C++ offers library authors strong tools for safe library implementations. Python enables sound interfaces, albeit checked only at runtime. C offers much less to the library designer, mainly because resource management in C cannot be automated. Perl offers the least of all, because global state may may affect the semantics of primitives used in a library more or less at random, and because the language semantics themselves tend to chaos. Java encapsulates memory management but offers little help in managing other resources. These languages don't fall neatly into "high-" and "low-level" bins that imply safety or unsafety. Safety comes, to a large degree, from use of well-designed, -implemented, and -tested libraries. Language choice affects safety in the availability and usability of such libraries.
Too cool for secure code (Register) Posted Mar 26, 2003 22:28 UTC (Wed) by stuart (subscriber, #623) [Link] Well let's not be too critical - in the main these programmers are coding for my benefit and I certainly don't pay them! Progammers I could pay would be the one's at Microsft where you have to wait upto 3 years for a bug to maybe be fixed in the next release.It's not perfect, yes there's room for improvement but I value it and *choose* to use it knowing that these errors will continue to occur. Talking recently to someone who had to review the Openssl code, I realise the problems are little to do in the main with the choice of C as the language its written in. The state machine for ssl is so horrendously spaghetti like that there is bound to be flaws in it regardless of the language used to implement it. What is needed then is a 'better' state machine. But I'll take working mostly today over perfect next year. Stu.
Too cool for secure code (Register) Posted Mar 26, 2003 22:48 UTC (Wed) by tjc (guest, #137) [Link] In an age where processing power is cheap, there's no excuse for a mail client written in C or C++.This statement seems to imply that one needs an escuse for writing a program in C or C++. I don't believe this is the case at all. People aren't born good programmers. Providing a novice (or careless) programmer with a "safer" language will only mask the real problem, which is a lack of knowledge, skill, and/or experience. Rather that focusing on better tools perhaps we should put more emphasis on improving our knowledge and programming skills, since there's much more room for improvement in this area. It's much more rewarding to the individual.
Too cool for secure code (Register) Posted Mar 26, 2003 23:37 UTC (Wed) by cbcbcb (guest, #10350) [Link] No, he is right. A compiler and/or language runtime environment can use the enormousamount of CPU power to do a lot of things which simplify the task of programming. These include (with varying amounts of controversy) checking array bounds, garbage collection, static type checking, and exception handling. This doesn't automatically mean the programmer doesn't have to worry about (for example) array bounds any more - an invalid array access will lead to a crash (eg uncaught exception), but not an EXPLOITABLE crash. There are no real solutions to bugs caused by race conditions or the timing attacks on OpenSSL other than programming properly and THESE are the problems programmer brainpower should be spent on. The real problem is that most sensible alternatives to C or C++ are interpreted eg python and/or have a big/uncommon runtime environment eg Java, have very little 3rd party library support, eg eiffel, ocaml, and/or the language is not very standardised with differing implementations and/or there is only one implementation in existence. In the (more risk averse) commercial world the latter problems are considered by most to be show stoppers for using alternative languages which means the number of people trained in better languages is limited. I would love to see a programming language emerge as a real alternative to C and C++ which has benefitted from the last 35 years of programming language research. Unfortunately it looks like applying more and more obtuse design methodology to C++ is the way the industry is heading :(
Too cool for secure code (Register) Posted Mar 26, 2003 23:52 UTC (Wed) by proski (subscriber, #104) [Link] I don't know what "commercial world" you are talking about, but Java is quite popular in the applications where correctness is paramount.The reason for choosing C and C++ is usually speed and ability to interoperate with just about everything. If the application is printing checks for millions of dollars, it's most certainly not written in C or C++. If the application is sold to millions of end users, it's probably written in C or C++ to satisfy customers with slow computers.
Too cool for secure code (Register) Posted Mar 27, 2003 9:24 UTC (Thu) by cbcbcb (guest, #10350) [Link] No, Java is used on large web applications where perl is inappropriate dueto performance concerns, or because the application is highly complex which perl is not really suited for. It is only really used on the server where the platform is known so that the portability issue is less important. The speed issue in C/C++ would be irrelevant if there was a suitable compiled language with more safety features - they add very little cost when appropriate optimisations have been applied. C++ compiles to pretty inefficient code a lot of the time anyway.
Too cool for secure code (Register) Posted Mar 27, 2003 15:19 UTC (Thu) by cdmiller (subscriber, #2813) [Link] PHP is used on large web applications where Java is inappropriate due to performance concerns.Compiled languages with more safety features have existed for quite a while. Witness pascal, modula, and ada, which are often translated into C for compilation. C is not the problem. Languages don't create security problems, programmers do.
Too cool for secure code (Register) Posted Mar 29, 2003 16:00 UTC (Sat) by vonbrand (subscriber, #4458) [Link] Sure, Pascal et al are more secure _when the runtime checks are enabled_. They aren't, most of the time, because they are so slooow...Same goes to the "C++ is inefficient" quip: The compilers just aren't up to getting efficient code out of code littered with random safety checks (yet?). Even getting C to be as efficient as it is today is _hard_. If you want proof of advances, just compare C as it was written 20 or so years ago and how it goes today.
Too cool for secure code (Register) Posted Mar 27, 2003 2:09 UTC (Thu) by parimi (guest, #5773) [Link] A little thought on novice programmers and safer languages. Now-a-days I see many people learning the so called "high" level languages like Java, Perl, Python etc...IMHO, they do learn programming, but what about topics such as linked lists in these languages? By not learning C, these people are losing out a great deal on learning one of the very important aspects of any programming language - data structures. Working with pointers and spending some debugging the core dumps definitely builds a good sense for safe programming. Using other languages automatically doesn't make programs any safer..Perhaps, a program is only as safe as its author makes it, irrespective of which language is used..
Too cool for secure code (Register) Posted Mar 27, 2003 15:16 UTC (Thu) by mrshiny (subscriber, #4266) [Link] As far as teaching about data structures, Java has 'references' which act just like pointers. They can be null. You can create structures (Java calls them objects). You can create a bunch of C-like static functions if you want, or you can have objects with methods in an OO manner. Heck, a core dump is really a type of exception, when you think about it, and Java lets you go past the end of an array, it just throws an ArrayIndexOutOfBoundsException. So basically the only class of errors you can't have in Java are where memory is corrupted silently and your program continues to execute, improperly. I think that makes Java a suitable language for teaching any CS principles, except maybe the ones where you care about the hardware itself, like embedded systems or operating systems or device control.
Too cool for secure code (Register) Posted Mar 27, 2003 15:31 UTC (Thu) by cdmiller (subscriber, #2813) [Link] I have often thought programming curricula were taught backwards. Programming should start with hardware principles and end with high level languages like Java.I have yet to meet a Java trained CS student who could easily pick up C, but I see a lot of C trained CS students who learn Java and other languages pretty easily. Throw a Java trained CS student into a compiler or OS course and watch the fun.
Too cool for secure code (Register) Posted Mar 27, 2003 17:15 UTC (Thu) by parimi (guest, #5773) [Link] I agree with you :) The good students learn any language/concept without much problem..However, those who learn Java and feel on top of the world struggle with pointers in C, and often end up abusing C for its poor design..
Too cool for secure code (Register) Posted Mar 27, 2003 22:18 UTC (Thu) by tjc (guest, #137) [Link] However, those who learn Java and feel on top of the world struggle with pointers in C, and often end up abusing C for its poor design..Poor design? There is a very small "semantic gap" between C and the hardware. If you don't like C, what you probably really don't like is computers and the way they work.
Even more important: learn how to write secure programs! Posted Mar 26, 2003 23:42 UTC (Wed) by dwheeler (guest, #1216) [Link] Certainly, the use of inappropriate tools can be a problem. But the biggest problem, I believe, is that so few programmers even understand what they need to do; they don't understand the trades, or what they have to do if they choose C/C++ for example. That's why I give away a whole book on how to write secure programs; see http://www.dwheeler.com/secure-programs.
Too cool for secure code (Register) Posted Mar 27, 2003 13:57 UTC (Thu) by elvolio (guest, #9549) [Link] I don't really agree that low-level languages are the problem: use the tools properly and life will be much better. That said, his fundamental point — that programmers often can't be bothered to write secure code — still stands. Programmers need to learn to take pride in secure code as much as they do functional or fast code (though that latter seems to have fallen by the wayside as well). This has almost nothing to do with proprietary versus open source and everything to do with the programmer's outlook. Fix that, and the current barrage of vulnerability discoveries would at least slow down.
Low level languages DO contribute to the problem Posted Mar 27, 2003 19:38 UTC (Thu) by cbcbcb (guest, #10350) [Link] To use an analogy:I don't really think that unsafe cars are a problem: drive properly and life will be much better. That said, the fundamental point -- that drivers often can't be bothered to put their seatbelts on or pay extra for a car with airbags -- still stands. Drivers need to learn to take pride in careful driving as much as they do about fast driving. The point is that the choice of programming language can dramatically reduce the risk of security problems in the same way that the choice to drive a car with airbags and wearing a seatbelt can dramatically reduce the risk of injury in an accident. Yes, it is possible to write secure stable software in C or C++, but programmers will always mistakes. A good programmer will often include internal consistency checks so that if a bug is encountered the program will abort safely, but that can be incomplete and in many cases the compiler (for a better programming language) could do part of that automatically. This is particularly important if code is developed in a situation where the developers do not know the whole of the source and cannot know the full consequences of a change. For example, consider a C function which is used to process a configuration file and contains an unchecked buffer. This is not exploitable or a problem because the configuration file is only modifiable by the sysadmin. However, if another developer later adds a feature which uses the same function to process user data, then a security problem has now been introduced by the new code even though the new code may contain no bugs. The principle behind designing a large software project is to make sure that you don't have to understand every line of code in a module in order to use it because it does not have unexpected weird side effects. C and C++ do not allow you to make that assumption because of the possibility of implementation errors which lead to undefined behaviour (potential security problems). And it is possible for undiscovered classes of bug to exist which means that even fully audited code may be insecure (eg the relatively recent discovery of format string attacks) I'm not saying that C/C++ have no place, they are clearly great languages for low level tasks or tasks where fine control of the resulting code is important, but mailing list servers, most network clients, some classes of network servers, web applications, desktop card games etc would be much better in a safer language. A safer language doesn't mean a dumbed down language; back to the car analogy, Michael Schumacher is no less of a driver just because he wears a seatbelt while he is racing.
Low level languages DO contribute to the problem Posted Mar 27, 2003 21:38 UTC (Thu) by Ross (subscriber, #4065) [Link] Unchecked inputs from untrusted sources are a problem in any language. If the program has the power to do anything useful, then it has the power to be destructive if it is mislead. Take your example with configuration files. Any time code is designed to work with trusted input, and is later fed untrusted input, there is likely a security hole waiting to be exploited. Overflowing a static buffer in C is just one kind of mistake. Improper bounds checking on numeric inputs is another, and Java doesn't help you there.In any case, if you are only worried about stack-based exploits there are plenty of tools you can use to "secure" C and C++ programs. But if that is all you do to secure software that is a false sense of security.
Prove it. Posted Mar 28, 2003 14:30 UTC (Fri) by GreyWizard (subscriber, #1026) [Link] The point is that the choice of programming language can dramatically reduce the risk of security problems in the same way that the choice to drive a car with airbags and wearing a seatbelt can dramatically reduce the risk of injury in an accident. Yes, it is possible to write secure stable software in C or C++, but programmers will always [make] mistakes. Nothing in that post provides meaningful support for this claim. Programmers don't stop making mistakes, whether those are buffer overflows or access control issues, simply because they're using Java or whatever language is trendiest this month. Security problems can hide in functions originally not intended for use with untrusted data in any complex project regardless of the language. Implementation errors with undefined behavior can be found in every programming environment. Good library design can and should be done for any language. The only meaningful point raised in this debate so far is that the number of bugs in a program is roughly proportional to the number of lines of code. That means langauges that are more expressive are likely to be more secure. Which langauges are more expressive than C or C++? None of the languages usually thought of as "high-level" qualify here. They offer nothing more than garbage collection and array bounds checking, both of which actually can be done relatively easily in C and C++ (C++ examples are everywhere, but see glib and GTK+ for examples in C). Only Lisp actually offers truly powerful language features. Creating functions that generate functions in C or C++ is most easily done by writing a Lisp interpreter and using that. So go ahead, write your mail server, web application or desktop card game in Lisp if you want to use less code. Or write it in whatever language you like best, but make your claims about security based on field experience and analysis of working code rather than hand waving about "high-level" languages.
|
|
||||||||||||