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?
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.
|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.|
|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.|
|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.|
Resourcesa 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.
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