Too Cool For Secure Code? 471
An anonymous reader writes "Looks like not everyone believes Linux is the monolith of security folks might like us to think. Jon Lasser raises some interesting points in this article over at Security Focus. Though it has to be said, that whilst he focuses on the Linux/Unix side of things, a good proportion of programmers (no matter what they work on) are guilty of similar conceit to some extent."
Too cool for security (Score:2, Insightful)
Everyone likes to brag about what they are doing and to be nice to people. The best security is social in nature: clam the fuck up about what you are working on, isolate yourself from others who are trained to know the meaning of what you are doing. That's the best security - it leaves you free of determined attempts and leaves only the random attempts at hacking which can be dealt with by techniques mentioned in the article link.
So true (Score:3, Insightful)
Only too often have I sat in on meetings with immature little dweebs who rant on and on about XML or the technolofy flavour of the month or hacking at code to achieve Olog(n) cahche hits instead of focusing on making proper underlying designs.
Frank Brooks talks quite a bit about this in his book "The Mythical Man Month" where he states that secure computing is getting worse on the level of one order per generation of new programming languages. That book should be required reading by all CS students.
Warmest regards,
--Jack
Languages not necessarily the problem (Score:4, Insightful)
In C, it just requires using a library like glib for your string handling, and some similar library to provide bounds-checked arrays.
In C++, it means avoiding char * strings like the plague and using the standard 'string' class instead; similarly using 'vector' or other STL containers instead of C-style arrays.
I think it would help if there were a standard, minimal C string library, and if existing APIs including system calls were given equivalents using these. So open() could take a pointer to a 'const struct String' rather than a char *. Having done this, the existing functions like strlen() and strdup() could be declared deprecated. There are plenty of decent string manipulation libraries for C, what's lacking is a single one library which everyone can agree to support.
At least in C++ there is a standard 'string' type, although some people insist on reinventing the wheel (Microsoft's MFC with CString, Qt with QString).
Ignoring certain realities (Score:5, Insightful)
I don't think this macho thing plays into it nearly as much as he states. I think it has to do with comfort and laziness. I've been programming in C/C++ for over 15 years, so obviously, if I have a programming task to tackle, I will lean towards using those languages. I can do a minimal amount of vb, so if I need to slap together a ui, I can, but not anything that did anything interesting. If I have a task, how much time should I spend learning a new language if that language is better suited for the task than a language I know? Since I'm new to this language, how much worse is the code going to be than what I could have written in a less suitable language?
I'm not saying that I'm against learning new languages, but a programmer can only realisticly be "good" at a small set of languages. And the realities are that unless I'm working on a pet project, I don't have the time to learn something new or try to come back up to speed on a language I last used two years ago. Perl is an excellent example in my case, I don't know a lick of it. If I have simple text processing to do, I use the "simpler" text utilities (awk and sed primarily), unless the problem is very simple, in which case I fire up my text editor. If it's more complex, then I use C/C++. Could it be done quicker in Perl, maybe, maybe not. If by quicker you allow me to ignore the ramp up time to learn the language. If I were doing this type of thing all the time, then the rampup could be amortized in the long run. If it's onsie twosie, then forget it, out comes the c compiler.
This guy doesn't get it. (Score:4, Insightful)
This sounds like Microsoft's philosophy - bloat because we can afford to.
HLL's are NOT a substitute for secure programming (Score:4, Insightful)
The thrust of the article is that most programmers are not skilled enough to write secure code, so they should be using HLL's that do the security for them, and leave C/C++ code to the "experts."
Hogwash.
Repeat after me: Security is a process, not a product. HLL's can be misused just as effectively as LLL's.
Back to this columnist's soapbox rant. It ends up reveling in an admittedly fallacious comparison:
> Real programmers manipulate the system at the lowest possible level,
> for the maximum possible effect.
I'll accept that, in the diversity of programmers, there are some that are writing insecure code. But stereotyping of this sort is an act of the columnist. Even if there are some programmers who adopt this stereotype, they do not nearly comprise the entire population. The existence of many professional, responsible programmers is completely discounted by the columnist.
> The fallacy of the comparison should be obvious...(
> I think it's safe to say that programmers spent less time at
> self-criticism than pilots.)...
It's safe to say in the one-way communication of the columnist's world. It's safe to say when your profession is to write sassy, not-too-verifiable copy. It's safe to say if you don't have to have your article vetted by fact-checkers.
> 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.
Here the columnist exercises the same comparison he recognized as fallacious. Programmers are not pilots. Not airline pilots, not fighter pilots. While I believe there is a need for the computing industry to move towards more responsibility for security, focusing just on C/C++ programmers will not do the job. There is plenty of improvement to be made by the end users, and the columnists as well!
> There is also a macho streak in programmers:
There's a macho streak in this columnist who disparages professions that he probably hasn't been participating in as of late.
Pfft!
Too Busy for Secure Code, Unfortunately (Score:3, Insightful)
Well, perhaps its because of one of the following reasons:
1) Too many programmers aren't granted adequate debugging time by companies who'd rather get any code to market on time rather than test it thoroughly and miss deadlines.
2) How many programmers do you know who actually know how to audit code for security issues? How many companies are going to invest time and effort (and money) in hiring these people (or training their own?)
3) As people learn new languages, do they learn secure practices too? No, they learn how to write functional code. For some, thats enough to get the job done.
"In an age where processing power is cheap, there's no excuse for a mail client written in C or C++."
How about portability? Or efficiency? Or the fact that the guys writing the code would rather work on the mail client than go and learn a new language first? If they are writing bad code in a language they have been using for years, why move the problem to an area where they have even less expertise?
Writing secure code is a black art to many, and we can only hope that peer review and open source will help to spread the word amongst today's developers.
Re:Bullshit? (Score:2, Insightful)
In my previous comment my arguments for calling the article bullshit was a bit weak. Here are some more:
1. The programs and security-flaws he mentions are stuff like: linux kernel, openssl and mysql.
2. He proposes to solve the problem by using higher level (and he admits: slower) programming languages.
3. So is he suggesting to write the Linux kernel in Java, OpenSSL in Perl and an database in Visual Basic?
What is this guy smoking, and can I have some?
You can, but it's hard, and why would you want to? (Score:4, Insightful)
What you're describing, is, in fact, a modern high-level language. Except that if you were to do all this stuff in C, you'd be in such an environment that even the simplest stuff is a pain in the ass... calling special functions or macros to access arrays, etc. Nobody wants to do this, and nobody wants to read code that does -- and that's why nobody does. These high-level safe languages do all this stuff automatically, and transparently, so that you can write clean natural code and it is secure against the most common kinds of holes. Java is an example if you like Object Oriented programming, for my part I like SML.
Of course it's possible to write bug-free C code. But it's really hard when you are at the scale of even a modest network daemon. Even our best programmers make security bugs when writing in C though (see: Quake I, II, III, Half-Life, Linux Kernel, sshd, ftpd, apache, perl, mozilla, and just about every other software package you think is written by great programmers), so how can we expect the rest of the world to do it?
Re:Right... (Score:3, Insightful)
Or Python. Or Ruby. Or Lisp. Or REBOL.
Maybe this guy buys a new supercomputer every month, but my Duron at work isn't getting faster any time soon.
I assume that you're trolling. An email client is so lightweight--mostly GUI and waiting for sockets--that you could write it in *anything* and even on 200MHz Pentium, and it would be just fine.
There has gotten to be some misplaced angst among younger coders, those who are frustrated at the lack of perceived performance in Windows and KDE and various large applications. They come up with pet excuses for that slowness, most of which are invariably, flamingly wrong.
Not language as much as library (Score:5, Insightful)
Also there are Language biggots that say "C is better than X because it's faster" or "Just because we have a 2Ghz, doesn't mean we should waste it."
C is faster than X?
A language isn't fast, only it's compiler has had more time to be optimized. Natively compiled programs in fact have less of a chance to be fast for these reasons:
1) compiled for a specific architecture, usually 386.
2) can not inline shared library calls.
At the moment C may be faster than X, but in a lot of cases, X (where X is an interpretted or VM compiled language) will eventually over-run C in terms of performance.
Just because we have 2Ghz, doesn't mean we should waste it?
Also, you have to consider that these languages usually have enormous libraries and abstractions like Java so that developers don't have to code as much. This means there is less code that has to be checked for security issues. It means more efficient developers. At some point, the time of the developer out ways the time spent on the CPU. I would rather people were making this choice rather than to skimp on security. Security is often implemented after the fact in C.
Security is always more important than performance to me. You are playing with data. Data is the single most important asset that anyone has. People cry for hours over loosing just 4K-10K of data. I would say to those that don't have the time to make a program right in C (takes more time than Java if you consider security and performance) then don't write it in C. You could end up causing a lot of people a lot of pain.
If you don't like Java, use Python. If you don't like Python, write a good VM. If you don't like VM's, you better take the time to check your code well. If you don't have time either, don't even bother programming. You are just going do more bad than good.
Yup, Slashdotters are too cool... (Score:2, Insightful)
Having spent a few minutes reviewing the comments to this article, it's obvious to me that there is quite a lot of truth to what this guy is saying.
There is dangerous tendency to believe that real coders, like fighter pilots, work as close as possible to the bare metal.
Many comments rebutting the arguments he makes about this are classic straw man arguments - they rebut an argument that is related to, but weaker than, the argument actually made by the author. The author provided an an example that working with higher level languages could reduce code errors. A number of comments attack this example, rather than the argument itself, which is that programmers who think that they must do everything themselves risk more errors. To provide an example: My company has a variety of well secured thin client applications. The other day, a new web application popped up. When I forgot my password, I managed found a way to circumvent its security in a matter of minutes. The developers of this app were simply too macho to draw on the code and solutions already existing within the same company. They rolled their own, and made mistakes.
My developer cohorts and I have a running joke about Wheel v2 (actually, we're probably on Wheel v 98.2). Developers love to reinvent the wheel. Good programming practice always needs to start with taking the specification and asking "Is there a product out there that solves this" Often, you find a set of libraries that solve 90% of your problem - costing much less than the development time it'd take to roll your own. Often you'll find that the developer next door has already built that. But it is just so much more fun to write your own than learn to use someone elses code! The authors point - not well rebutted by argueing about C versus V.M. based languages - speaks to the conceit of programmers who think that they can do it better than the third party library or their co-worker. A number of slashdot comments support his contention that programmers are conceited - "He's not a real programmer ..." etc.
Also worth noting: A large percentage of code written is not for embedded systems and palms. It's used within corporate intranets. At my company, is easy enough to make standards for libraries and languages and languages used - making an app dependant on a few other components is really not so evil. Arguing that your palm apps must be written in C does not address the authors point!
Re:Too cool for security (Score:2, Insightful)
Or something like that. I'm not really sure.