Until Unix and Linux programmers get over their macho love for low-level programming languages, the security holes will continue to flow freely.
There is dangerous tendency to believe that real coders, like fighter pilots, work as close as possible to the bare metal.
Most notable among these is the Linux kernel ptrace vulnerability, which allows local users to acquire root privileges. Next, there is a clever timing attack against OpenSSL that can reveal a site's private key and thus compromise all of its traffic. There is also the mysql configuration file vulnerability, whereby a malicious user can write out a file that will allow him to acquire full privileges; a buffer overflow and local root exploit in the venerable lpr print daemon; a buffer overflow and potential root exploit in the Mutt mail reader's IMAP code; and a glibc integer overflow that allows remote code execution via RPC.
Also reported in the last three weeks are perhaps a dozen more security holes in programs including file, ethereal, ircii, qpopper, Evolution, rxvt, Samba, and others. These are, by and large, holes discovered and reported by the good guys -- there's no telling what black-hat hackers have discovered.
Most of these bugs are buffer overflows, format string vulnerabilities and input validation errors. In short, these are the same sort of holes that we've seen over and over again for years. Format string vulnerabilities are new, discovered circa 1999; the other two classes of bugs have been known and actively exploited on Unix for quite a while: the
Why do we still see these bugs?
In no small part, it's because programmers aren't using appropriate tools. In an age where processing power is cheap, there's no excuse for a mail client written in C or C++. For users accessing mail via IMAP or POP, network speed and congestion have a greater influence over performance than anything done on the client side; even for users with local mailboxes, I doubt that we're looking at a huge performance hit.
Studies have shown that programmer productivity, measured by lines of code over time, varies little between languages. Languages that automate more of the low-level work allow a programmer to accomplish more in fewer lines of code and also, perhaps not incidentally, avoid certain types of security bugs: the low-level constructs that C and C++ programmers spend time managing are the same ones that can get them into trouble.
To be sure, some software must continue to be written in lower-level languages: Database servers such as MySQL will inevitably be written in lower-level languages for legitimate performance reasons. And it would be both unlikely and counterproductive for the Linux kernel or the system library to be rewritten in Perl, Java, or Python.
But none of those concerns justify writing an IRC client in C. And if it seems unimaginable for a print server to be rewritten in a high-level language, the reality is the benefit would be substantial and the performance costs negligible.
I don't believe that software written in high-level languages is free of security holes: the number of bugs in Web applications written in Perl and PHP is astounding. Applications written in those languages have no immunity from data validation errors that can be abused to provide remote access to files or even remote execution capability. Perl's taint mode can reduce the risks from these bugs, at the cost of modest effort on the part of the programmer.
If coders must use C or C++ for everything, there are tools to make these languages a little less dangerous: WireX's StackGuard and FormatGuard come immediately to mind, as do various high-level string libraries.
Why are these tools not used more widely? FormatGuard and StackGuard are relatively simple to implement, and the performance penalties are typically in the single-digit percent range. However, using these tools requires modifications to standard infrastructure: StackGuard is essentially a modified version of the GCC compiler suite; FormatGuard is a modified version of the standard GNU C libraries. Neither programmers nor system administrators like diversity in the underlying environment: it makes debugging much more difficult.
There is also a macho streak in programmers: a tendency to believe that one's own code is well-written, and a corresponding belief that real coders, like fighter pilots, work as close as possible to the bare metal: Real programmers manipulate the system at the lowest possible level, for the maximum possible effect.
The fallacy of the comparison should be obvious. Modern fighter jets are fly-by-wire, and, while still relying on the exquisite skill of the pilot, the jets systems handle the bare-metal aeronautical tasks on their own. Furthermore, fighter pilots are highly-trained, spending much of their time on simulators and analyzing their mistakes. (I think it's safe to say that programmers spent less time at self-criticism than pilots.) Finally, very few pilots are qualified to fly modern military aircraft.
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.
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.