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."
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.
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); }
I've been trying to r00t GORILLAS.BAS on my DOS box for years with no luck.
Trolling is a art,
I've found over the years that most new coders aren't taught the proper basics of coding because they focus on learning high level languages and arcane algorithms, instead of focusing on the art of computing, like Donald Knuth's books.
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
Wagner LLC Consulting Co. - Getting it right the first time
The thing is, you can program in a low-level language yet still avoid bugs like buffer overflows and failing to handle NUL characters in strings.
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).
-- Ed Avis ed@membled.com
After programmers take responsibility, perhaps they can consider using the right tool for the job, rather than the right tool for the job of their dreams.
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.
"In an age where processing power is cheap, there's no excuse for a mail client written in C or C++."
This sounds like Microsoft's philosophy - bloat because we can afford to.
Please, spare me from the armchair drivel of these SecurityFocus columnists! (Okay, I should spare myself, but I'm compelled to comment.)
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!
Well, he wants everyone to write everything in perl, except for the fact that he brings up, that perl is just as insecure itself.
So what will everything be written in??? Every part of the OS in java? Nevermind the performance, and the lack of a good, Open Source JVM/JDE.
If you want secure programs, start putting strong-typing, and other security measures into GCC. You can't have a string overflow if GCC checks everywhere data is input, and makes sure the input can be no longer than the string...
A bit different, but it deserves to be mentioned that OpenBSD 3.3 (which will be released VERY soon-already tagged), has numerous protections as described here, by Theo. Yes, that's right... OpenBSD has been doing the job before Lasser even lifted a finger to complain.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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.
Bad style to reply to your own comment, but what the hell.
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?
How do you prevent against double-frees ... Use a garbage collector? Integer overflow ... use a package that checks for overflow on each integer op? Bad pointer arithmetic ... disallow it? Force the programmer to check error conditions on system calls ... use exceptions?
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?
It's bad programming habits and the lack of tools that catch those program time errors.
Static analysis, the use of programs to analysis code that has not been compile completely to machine code, has historically been undeveloped in open source. I use to have a list, was my research focus for a while, but basically we have one decent static analyzer Splint, and it's not that hot compared to commercial offerings.
For instance the HANDS group from stanford has tracked down lots of kernel bugs using their in house analyzer, in lots of obscure places. MS has an in house program I hear they guard closer than the kernel itself! I have a friend that did kernel work for them that agreed with this, they give him the kernel source but not the ananlyzer binaries even. The guy who wrote it, known in pointer analysis circles often goes on about how he's found tons of bugs in open source projects ( bet you he's not filing bug reports )
There are lots of groups working on static analysis, but no one wants to open source their code.
Hind, Michael http://www.research.ibm.com/people/h/hind/
Hind has written amongst other things probably the best and most recent introductory papers on pointer analysis at http://www.research.ibm.com/people/h/hind/paste01. ps.
stanford checker
SUIF compiler suif
I had a few other links, but the lameness filter is complaining about "too many junk characters". You'd think slashcode would have a better filter by now.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Tell me what my mail client should be written in? Java? C#?
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.
Try Aleph1's excellent article from phrack.org:1 4
http://www.phrack.org/phrack/49/P49-
Use source analyzers to find common mistakes, here are a few
Flawfinder
RATS
ITS4
Splint
also look at Splint's Links page for more on the topic
we learned at skool
Looks like you need to go back and take Internet%20Lingo%20?101 again. It's spelled sk00l not skool.
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
The biggest problem with C/C++ is the complete lack of a standard safe library. Developers don't like to say "You need to install these 20 other packages before my program will run on your system."
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.
Karma Clown
The basic problem was that file i/o is slow in Emacs Lisp.
This is like saying that a particular implementation of the C++ STL is slow, therefore C++ is slow. You can't blame the high level language for a particularly crappy implementation. Emacs Lisp is so famously bad that even Lisp programmers won't touch it.
That said, I still stand by using high level languages for these kind of applications. These days you can write a well-designed program in Python that appears lightning fast and a poorly designed application in C that's several times slower, despite being compiled to native code.
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!
My motto: "A cat is no trade for integrity."
This is a bunch of hogwash. This guy sounds more like a MS rep than a security-focus programmer. Because RAM and CPU is so cheap now and so powerful, it doesn't matter if we write crappy bloated code? That's such bullshit. Consider that writing crappy bloated slow code in fact reduces system stability, by adding to CPU and RAM strain. Just as a security breach can result in data-loss, so can a system or program crash.
And, if this author not know, not everyone is buying the latest 2GHz CPUs. For most people's needs, a 100MHz PC is still fine and dandy -- that is, unless fuckwits like him and the genius' at MS continue to make ever-more bloated and slow code.
And why is RAM-usage so important, even with typical PC's having 256MB of RAM? Well, apparently this guy is still stuck in the good old one-program-at-a-time days. People run many programs concurrently -- the more resources each one takes up, the less happy the user is, because that means everything is slower overall, and may even mean the system has to switch over to virtual memory.
And why is it that we always get complacent jackasses like this always assuming that speed, memory-usage, stability, and security are always inversely related to one-another? They aren't. For the most part, writing smaller faster code isn't necessarily going to make the program less secure, nor is writing more secure stable code going to make it perform worse. There a *few* specific cases where there are trade-offs: in those cases, it's up to the programmer to decide what's best based on his target audience. If he's targetting home-users, a little bit of security can be sacraficed for increased performance. If he's targetting business users, a little bit of performance can be sacraficed for security. Stability is always a priority.
Alas, I'm sick of hearing "this programming language (C) is faster than that one (Perl), and assembly is faster than them all". Programming languages aren't "fast". Assembly allows a programmer to produce very highly optimized, fast, code. However, poor assembly will run much worse than C compiled with GCC. Comparing C to other languages, C programs tend to be faster because C allows for more direct control and compilers have had more time to be optimized. I doubt other languages will ever catch up to C in that regard, but a crappily written C program will still be beaten by a well-written Perl programmer (personally, I suggest Objective-C, because it provides OO with only a few additions to C).
social sciences can never use experience to verify their statemen
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.