Too cool for secure code

Mucho Macho

  • alert
  • submit to reddit

Beginner's guide to SSL certificates

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

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.

eXXXtreme Coding

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. ©SecurityFocus Online

SecurityFocus columnist Jon Lasser is the author of Think Unix (2000, Que), an introduction to Linux and Unix for power users. Jon has been involved with Linux and Unix since 1993 and is project coordinator for Bastille Linux, a security hardening package for various Linux distributions. He is a computer security consultant in Baltimore, MD.

Protecting users from Firesheep and other Sidejacking attacks with SSL

More from The Register

next story
Spies would need SUPER POWERS to tap undersea cables
Why mess with armoured 10kV cables when land-based, and legal, snoop tools are easier?
Early result from Scots indyref vote? NAW, Jimmy - it's a SCAM
Anyone claiming to know before tomorrow is telling porkies
TOR users become FBI's No.1 hacking target after legal power grab
Be afeared, me hearties, these scoundrels be spying our signals
Jihadi terrorists DIDN'T encrypt their comms 'cos of Snowden leaks
Intel bods' analysis concludes 'no significant change' after whistle was blown
Home Depot: 56 million bank cards pwned by malware in our tills
That's about 50 per cent bigger than the Target tills mega-hack
Hackers pop Brazil newspaper to root home routers
Step One: try default passwords. Step Two: Repeat Step One until success
China hacked US Army transport orgs TWENTY TIMES in ONE YEAR
FBI et al knew of nine hacks - but didn't tell TRANSCOM
Microsoft to patch ASP.NET mess even if you don't
We know what's good for you, because we made the mess says Redmond
NORKS ban Wi-Fi and satellite internet at embassies
Crackdown on tardy diplomatic sysadmins providing accidental unfiltered internet access
prev story


Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
WIN a very cool portable ZX Spectrum
Win a one-off portable Spectrum built by legendary hardware hacker Ben Heck
Saudi Petroleum chooses Tegile storage solution
A storage solution that addresses company growth and performance for business-critical applications of caseware archive and search along with other key operational systems.
Protecting users from Firesheep and other Sidejacking attacks with SSL
Discussing the vulnerabilities inherent in Wi-Fi networks, and how using TLS/SSL for your entire site will assure security.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.