Slashdot Mirror
Too Cool For Secure Code?
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."
But it is OPEN meaning a COMPETANT admin can MAKE it very secure. About the closest thing to 'out of the box' security is OpenBSD. My Linux (RH71) box was rooted in less than a day after putting it on the 'net. My OpenBSD box has lasted for almost a year.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Yes. Unless you are writing in machine code, you are depending on the quality of at least one other layer of software, so if you want to be paranoid only machine code should be considered "secure" -- well, least likely to be insecure, anyway. My real point was the cost of layering -- with C you already have several dependent layers of software of high complexity and potential for failure. Programming in something based on C, say Perl, has one more. Something writen in Perl itself adds yet another, etc. The supposed benefit of not having to be as careful a programmer because one is using a higher level language needs to be balanced against the cost of having to trust that all the products used to create said higher level language are better than what you could do if you carefully used a lower level one. The real problem today is lazy coders who can't be bothered to check return values or program defensively against probable problems. You may be able to move most of them to some high level language where they can be sloppy without fear of (as much) reprisal, but someone else will still need to be a programmer good enough to create or maintain said higher level language.
I'm just not convinced that recompiling under the tools Mr. Lasser mentioned are going to fix the problems with C/C++.
Look, the big issue for about 75% of all programmers in the world is that the whole institution of computer programming is based around the idea of "Think how the program can crash itself" and not "think what can someone can do to intentionally bust your program". Now we've got literally millions of programs with trillions of lines of code between them, and all of them have some part where the coder(s) had to implement something that *just worked* instead of something that was particularly well thought-out.
Look at the list of vulnerabilities in common software and you see problems with string formatting and buffer overflows in input in places where, frankly, the programmers never believed that someone would poke around.
I'd say that the only way to force people not to force the boundaries of allowable input is to only provide a fixed list of choices, drop-down text box style. Except that's just about useless for much, if not most, tasks we need our machines to handle.
I also believe that when we're learning to program, we get almost zero education on how to do bounds checking.
Have you ever asked a univeristy professor about bufer overflows? You usualy get a blank stare and some comment about how that would probably crash the program. Only a few really consider that there are real consequences to crashing a program.
The funny thing is, if you think about it, a program's natural state is crashed. Everything line of code basicly props the program up so it can continue on and do something else.
What are we going to do? Rewrite *everything*? This makes y2k look like pretty small potatoes.
Personally, I'd say that the big problem isn't programming languages that allow us access to low-level services but that the operating systems that we know and love and use all the time are written with the idea that programs are to be trusted at some level. It's possible to run a program with root priv. because that priv. level exists at all. Why not use systems that don't even have the concept of root?
We don't because a) they would (and are) amazingly tough to get any real work done on and b) they're slow or at least have the perception of being slow and c) none of the super-secure operating systems have been written as something you can game and write documents and all the other things we use computers for.
As far as being "macho", yeah, I've had long discussions with C programmers who are pretty "macho" about their ability to manage memory by hand. Those conversations usually end with me saying, "but most people use aplications" and the programmer saying "applications are for weenies." So I'm not suprised Mr. Lasser claims a high level of ego in programmers as a whole.
Peer review has been doing little good. It is a mission critical application used ubiquitously yet it has such a major flaw that you can steal the server's private key. Maybe you say, it's the age of the program. Look at sendmail, it's 20 years old and we're still getting critical exploit security bulletins for it. Not to mention EVERYONE uses sendmail, it's widely reviewed, and anciently deployed.
No, it is not peer review, widespread use, open source, full disclosure. It is engineering that gives security. Proper process, proper technique. We have eyes, but they are blind and dumb.