A bad week [LWN.net]

As a quick perusal of this week's "new vulnerabilities" section will confirm, this has not been a good week for the security of Linux systems. New holes have turned up in KDE, MySQL, OpenSSH (twice), pine, sendmail, XFree86, and more. Almost every Linux system out there will be affected by at least one of these problems.

The OpenSSH and sendmail vulnerabilities are of particular concern. Almost every system of interest runs OpenSSH, and vast portions of the net still run sendmail. Any vulnerability in those programs automatically opens up large numbers of systems to exploitation. These are the sorts of problems that will, someday, be used for the creation of a virulent worm which attacks Linux systems. If we are lucky, no such event will strike us this time around, but let there be no doubt about it: as long as software which is so widely deployed has remotely exploitable holes, we are vulnerable to that sort of mass attack.

Now that the obligatory scary talk is done, let's take a look at the better news here. It is not clear that the bugs in either OpenSSH or sendmail are exploitable in any large-scale way. Even if they are, once again the problems have been found first by the good guys and fixes have been made quickly available by the Linux distributors. The patches being released are small and relatively non-disruptive; administrators can apply them quickly and with confidence. So most systems will be patched in a relatively short period of time. These vulnerabilities were a scary warning, but it does not appear that there will be any great consequences this time around.

Nonetheless, this episode is a warning. Our security, while arguably better than that of the competition, is nowhere near good enough. We are still encountering bugs in crucial, highly-audited code; one can only imagine what lurks in programs which get less attention. And the network environment we are creating is still too monocultural. The network as a whole will be safer when there are multiple, interoperable programs capable of performing the basic infrastructural tasks.

to post comments

A bad week

Posted Sep 18, 2003 4:35 UTC (Thu) by proski (guest, #104) [Link] (1 responses)

When it comes to computer security, being better than competition is not enough. If somebody is determined to ruin your business, the are not chosing between your server and Joe's internet enabled typewriter. They are chosing between attacking your network and attacking you by other means, e.g. by spying on you or bribing your employees. In many cases an attack on the network is the easiest approach.

A bad week

Posted Sep 18, 2003 18:10 UTC (Thu) by tkreagan (subscriber, #4548) [Link]

of course, if they are that concerned with attacking you specifically, they'll just go through your dumpsters or break into your office and burn the thing to the ground.

i think that the majority of the time, internet attacks are opportunistic and specifically targeted. those who would specifically target you are generally not those who would have the ability to attack you.

A bad week

Posted Sep 18, 2003 14:07 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (5 responses)

IMO the story proves one more time that C is just not suitable for writing safe code. If OpenSSH would be written in OCaml, Java, C# or any other language where it is just impossible to write code with buffer overflow, the bug would not exists.

And it is really pity that such projects as Cyclone do not get widespread attention and usage.

RE: C is bad

Posted Sep 18, 2003 14:16 UTC (Thu) by cdmiller (guest, #2813) [Link] (1 responses)

Well then have at it Mr. Cyclone. Where is your sshd implementation in Cyclone? And while your at it we are waiting for you to port over the necessary libraries as well. Until this is done you have no proof of your claims about how much more secure the Cyclone sshd will be.

RE: C is bad

Posted Sep 18, 2003 19:01 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

I did not wrote any Cyclone code besides simple hello-world like programs since I do not have time to contribute more. But if somebody asks me to write network-related code in C, I would simply refuse. Thanks to Java I know that network-related code that I wrote so far does not have any buffer overflows leading to remote exploits.

And if Java or C# is not acceptable, then at least I can use Cyclone or any other language with enough built-in protection and easy integration with C to write my part of the code.

For better security, use better tools

Posted Sep 18, 2003 22:01 UTC (Thu) by brouhaha (guest, #1698) [Link]

I agree, C and C++ are terrible for software engineering. There are many better choices, including some you mentioned, as well as Ada, Eiffel, Modula 3, and Sather. Scheme, Self, and Smalltalk also are possibilities, though they may have more run-time overhead.

C is like a table saw without a finger guard. You might be able to use it dozens of times without problems, but eventually the lack of even the simplest safety features present in other languages will bite you.

Only as safe as the language implementation

Posted Sep 18, 2003 22:02 UTC (Thu) by hazelsct (guest, #3659) [Link] (1 responses)

One little problem with your analysis: an ssh server written in, say, python is only as safe as the python implementation. If there are buffer overruns in python, then every server written using python will immediately be vulnerable.

And most interpreted "buffer-safe" languages (Java, Python, Perl, C++, etc.) are implemented in -- guess what -- C! So in addition to the kernel, libc and user-space network etc. interface layers, you have an extra layer of vulnerability in the language, which is only as safe as the language implementer's ability to code safe C.

Sorry, no easy panacea here.

Only as safe as the language implementation

Posted Sep 19, 2003 8:06 UTC (Fri) by ibukanov (subscriber, #3942) [Link]

Coding in a safe language does NOT increase amount of potentially unsafe code, while writing a new C code very much does. One may hope that a compiler or runtime with a minimal C or assembler core will be made bug free while coding new staff in C will only incease amount of efforts to check.

Also, such runtime cores themselves do not use dynamic memory allocation (they have to implement it!) or extensive operations on C-style strings and it is easier to proove soundness of the implementation. In addition, bugs there much harder to explore since an exploit has to penetrate first working defences.

A bad week

Posted Sep 18, 2003 14:34 UTC (Thu) by cdmiller (guest, #2813) [Link]

It all comes down to the administrator. Poor administration = security problems. I maintain there is no monoculture where easy customization is available and widely utilized.

A bad week

Posted Sep 18, 2003 16:02 UTC (Thu) by addw (guest, #1771) [Link]

I quite agree that we need to be more concerned with security issues, we will get hit at some point. LWN is right to bang the 'dont be complacent' drum.

I just wish to note that it was a bad week because of the number of holes that were found by code inspection; I contrast this to other software where holes become known because they are being exploited.

Baddest of weeks, bestest of weeks

Posted Sep 19, 2003 0:05 UTC (Fri) by maney (subscriber, #12630) [Link]

Sendmail remains a disaster waiting to happen, with a MTBD that probably doesn't approach one year. I can't imagine why anyone would expect it to be otherwise. Despite all the efforts of those who have helped patch it up over the years, sendmail retains the disaster-prone free root with every succesful 'sploit monolithic design of an earlier, far more innocent age. In a world where more secure designs are readily available, sendmail's continued widespread use is mind-boggling. Distributions that ship with it as the default MTA need to be shaken to their senses. Or is it that having a universally used service which requires fairly regular patches right now! feels to them like a form of job security?

This program [sendmail] is included free in most UNIX software distributions, but you get less than you pay for. Cheswick, Bellovin & Rubin

Unfortunately, I have to disagree about this having been a really bad week. I fear that we'll see far worse when someone gets around to employing these vulnerabilities - not against my machines, thanks to the Debian crew, both the security boffins who get the patched packages out so promptly as well as all those who have made it both quick and easy to acquire and install updates all the many years I've been using Debian. But the awful reality is that many machines just don't get patched in a timely manner, and I can see little reason to expect that pattern to change this time.