By Jon Lasser Mar 26, 2003

Until Unix and Linux programmers get over their macho love for low-level programming languages, the security holes will continue to flow freely.

The last several weeks, as always, have brought a constant flow of security advisories. Perhaps not a torrent, but certainly more than a mere trickle.

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 first Internet worm exploited a buffer overflow in Finger in 1988.
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.

Source and more: Security Focus