User: Password:
Subscribe / Log in / New account


Brief items

Lessons from the Debian compromise

December 10, 2003

This article was contributed by Robert Bernier

It's been said that what doesn't kill you makes you stronger: if so then Debian must be very strong these days. The recent attack on Debian's servers is well known. It has been well documented and explained in detail. What remains to do is to consider the aftermath; have lessons been learned?

Recall the sequence of events. In the month of November, an unknown person developed a crack that exploited that now famous kernel flaw and found his way into a Debian developer's machine. Although it's not known if the attack was focused on the developer's machine in particular, it was quickly understood by the attacker that this PC presented a means to accessing the Debian servers. He installed the requisite tools that took over the machine and sniffed out the passwords. The attacker then obtained the password that enabled him to compromise a Debian project server. In quick succession, he penetrated a number of machines which spanned North-America and Europe.

It must be understood that up to this point the attack had not been detected. The machines were penetrated and had been successfully subverted. The attacks were executed in such a manner that none of the installed security mechanisms caught the activity. So why didn't the archives get compromised? And how was it that the attack, was even discovered?

The hand-crafted kernel exploit was not perfect. According to a group of Debian contributors who were interviewed at a recent Linux User's Group meeting (LUG), the exploit worked on all of the Intel machines but failed against one Sparc system, which is where the archives happen to reside. Another crack imperfection was that it generated strange messages in the log files which led to the attack's discovery. It turns out that one of the system administrators became uneasy as he was looking through the log files of one of his machines. He quickly understood that the messages were not normal and the other machines were checked out in short order. This is how the attack and its point of entry (the developer's compromised machine) were discovered.

What are the lessons learned?

  • Crackers can make bad code: the existence of those log messages indicates a lack of professionalism and sloppiness that eventually led to the attack's discovery.

  • The bio-diversity of mixed environments defeats mono-culture weaknesses: it's easy to criticize the fragility attributed by the dominance of a Microsoft centric work environment. But we seemed to have missed the fact that a Linux-only environment is monoculture too. Things could have been worse if it wasn't for the inherent differences between Intel and Sun System architectures.

  • Good people make a difference: a sharp brain and active curiosity are a great combination. Given the time and resources, all exploits can be caught.

Has anything been learned from this event that can help us formulate a more proactive policy? That answer depends on how much we, the open source community, are willing to work to eliminate these violations. These kinds of people can exploit a hundred machines before they stumble over one that can really hurt us. And that's the irony, for every attack that is noticed there are ten more that are unseen. By increasing the diversity of our systems and the alertness of our administration, we improve our chances of detecting and shutting down this sort of attack before it does real damage.

Comments (17 posted)

Discontinued SuSE Linux Distributions

SuSE has announced an end of life for SuSE Linux 7.3. Vulnerabilities found after December 15, 2003 will not be fixed for SuSE Linux 7.3.

Full Story (comments: none)

New vulnerabilities

cvs: unauthorized file creation

Package(s):cvs CVE #(s):
Created:December 9, 2003 Updated:December 17, 2003
Description: Stable CVS 1.11.10 has been released, fixing a security issue with no known exploits (as of this writing) that could cause previous versions of CVS to attempt to create files and directories in the filesystem root. This release also fixes several issues relevant to case insensitive filesystems and some other bugs.
OpenPKG OpenPKG-SA-2003.052 cvs 2003-12-17
Slackware SSA:2003-345-01 cvs 2003-12-11
Gentoo 200312-04 cvs 2003-12-08
Mandrake MDKSA-2003:112-1 cvs 2003-12-10
Mandrake MDKSA-2003:112 cvs 2003-12-08

Comments (none posted)

FreeRADIUS: Denial of service vulnerability

Package(s):FreeRADIUS CVE #(s):CAN-2003-0967
Created:December 10, 2003 Updated:December 10, 2003
Description: Versions of FreeRADIUS through 0.9.2 have a vulnerability wherein a remote attacker can cause the daemon to crash.
Red Hat RHSA-2003:386-01 FreeRADIUS 2003-12-10

Comments (none posted)

rsync - remotely exploitable heap overflow

Package(s):rsync CVE #(s):CAN-2003-0962
Created:December 4, 2003 Updated:March 3, 2004
Description: An advisory has gone out warning of a remotely exploitable heap overflow vulnerability in rsync versions 2.5.6 and prior. If you are running an rsync server, you will want to apply a distributor patch or upgrade to 2.5.7 in the near future.
SCO Group CSSA-2004-010.0 rsync 2004-03-02
Immunix IMNX-2003-73-001-01 rsync 2003-12-05
Mandrake MDKSA-2003:111 rsync 2003-12-04
Red Hat RHSA-2003:399-01 rsync 2003-12-04
Red Hat RHSA-2003:398-01 rsync 2003-12-04
Fedora FEDORA-2003-030 rsync 2003-12-04
Conectiva CLA-2003:794 rsync 2003-12-04
Gentoo 200312-03 rsync 2003-12-04
EnGarde ESA-20031204-032 rsync 2003-12-04
Debian DSA-404-1 rsync 2003-12-04
OpenPKG OpenPKG-SA-2003.051 rsync 2003-12-04
SuSE SuSE-SA:2003:050 rsync 2003-12-04
Trustix 2003-0048 rsync 2003-12-04
Slackware SSA:2003-337-01 rsync 2003-12-03

Comments (none posted)

Resources has been launched as a moderated mailing list where interested parties can talk about patch management.

Full Story (comments: none)

A FAQ on the OpenSSL FIPS 140-2 validation effort

The Open Source Software Institute has posted a FAQ describing the current OpenSSL FIPS 140-2 validation effort. This work, which is sponsored by HP and the Defense Medical Logistics Standard Support program of the DoD Military Health System, seeks to have the OpenSSL cryptographic modules certified as complying with the FIPS 140-2 standard. At that point, it would be possible for vendors to create applications which carry the same validation. See the document for lots of details.

Comments (none posted)


Black Hat Briefings Amsterdam Call for Papers

The 2004 version of the Black Hat Briefings will be held in Amsterdam on May 17 to 20. The call for papers is out now, with a submission deadline of March 25.

Full Story (comments: none)

Page editor: Jonathan Corbet
Next page: Kernel development>>

Copyright © 2003, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds