|
|
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
|
|
|
 |
|
No Comments Allowed for Anonymous, please register |
|
| |
|
Login |
|
 |
|
|
|
|
· New User? · Click here to create a registered account.
|
|
|
Article Rating |
|
|
|
|
|
|
Average Score: 0
Votes: 0
|
|
|
