On the Desktop
Linux in the news
All in one big page
See also: last week's Security page.
News and EditorialsHoneynet Forensic Challenge results posted. The Honeynet Project Forensic Challenge contest was launched on January 15. The purpose of the challenge was to allow security investigators to show off their forensic skills, to help publish useful forensic techniques, and to show just how difficult and expensive responding to security events really is. Contestants were given a set of disk images taken from a compromised system; their task was to figure out how the system was broken, where the attack came from, and what changes had been made to the system. Anybody who has ever had to go through this process knows how little fun it really is.
The contest is now over, and an announcement has gone out with the results. Thirteen submissions came in and were judged, and three of them were considered good enough to win - the winners will get a T-shirt and a book for their efforts.
That's a pretty small payback, given that the participants spent 34 hours each on this project. That is one of the big points that this challenge was designed to make: recovering from this sort of incident takes, generally, a week of a professional's time. Security incidents, in other words, are expensive, even if no real damage is done by the perpetrator.
Recovery is also not a sure thing - nearly every participant in the challenge found at least one thing that was passed over by the other teams. Modern computing systems are complicated things; it's not easy to find every single change made by a hostile intruder. It's hard enough, after all, to get a handle on what the person in the next cubicle has done.
Much security-related effort goes into prevention techniques - passwords, encryption, firewalls, etc. There is an increase in interest in intrusion detection technologies as well. Counterpane is pushing insurance policies (see next item). But recovery from compromises receives a relatively small amount of attention. We would not like to hazard a guess as to what percentage of system administrators will be faced with a recovery task at some point in their careers, but one would presume it would be high. The Honeynet Project is doing a great service by focusing some attention on that aspect of the problem. After all, many of us are going to have a mess to clean up, sooner or later.
A bug in PGP? A company called ICZ has put out a press release claiming that a serious bug has been found in PGP. Essentially, a flaw in the format used by PGP makes it possible, in some conditions, to decrypt a message without knowing the recipients private key.
This sounds scary, but this is a very hard vulnerability to exploit. It requires that the attacker be able to modify the file containing the victim's private key. Somebody with that level of access can probably come up with more straightforward ways to get the desired information. Still, it could be a useful technique for some sorts of "black bag" jobs perpetrated by well-funded, inquisitive agencies.
So, it's worth fixing, but most PGP users need not panic.
March CRYPTO-GRAM newsletter. Bruce Schneier's CRYPTO-GRAM newsletter for March is out. It has, if anything, more than the usual amount of interesting news from the security area, including discussions of the "security patch treadmill," how network security will be an insurance company issue in the future, the new crypto scheme out of Harvard, the TCP/IP sequence number problem, and more.
What will happen when the CFO looks at his premium and realizes that it will go down 50% if he gets rid of all his insecure Windows operating systems and replaces them with a secure version of Linux? The choice of which operating system to use will no longer be 100% technical. Microsoft, and other companies with shoddy security, will start losing sales because companies don't want to pay the insurance premiums.
Those who prefer it can also read this issue on the Counterpane site. (Thanks to Jose Nazario).
Passive analysis attacks on ssh.Here's a bit of a disturbing item: Solar Designer has posted a lengthy writeup on a number of "passive analysis" attacks on the ssh protocols which can make it much easier to break users' passwords. It's amazing how hard it can be to get these things right. Most ssh users need not panic at the moment, but it is good to know that these problems exist. Patches for a number of the vulnerabilities are included with the report.
XFree86 4.0.3 - time to dump version 3.x. Here's a note from Andrew van der Stock on XFree86 4.0.3, and, in particular, on the various security bugs that have been fixed in that release. The list of fixes is growing, to the point that it is really getting to be time to upgrade any systems still using XFree86 3.x.
Security ReportsDenial-of-service vulnerability in FTP server implementations. A report went out this week on a method to confuse a number of FTP server. Essentially, it just takes a line like:
ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*The server will then go off for a very long time trying to expand this wildcard filename.
FTP servers known to be vulnerable include ProFTPd, NetBSD FTP, PureFTPd (to some variants on this attack), BeroFTPD, and FreeBSD FTP. Known not vulnerable are wu-ftpd and publicfile.
This bug was publicly posted with essentially no notice to the maintainers of the various FTP daemon maintainers, which annoyed a number of people. The poster is also the author of PureFTPd, so it was with some relish that others pointed out that PureFTPd, too, was vulnerable to a form of this attack.
An advisory for ProFTPd has gone out. There is not, however, a patch available at this time; the advisory simply suggests a configuration change to minimize vulnerability to the problem.
It has been noted that the real problem could be said to lie elsewhere - simply typing the above "ls" command at a shell prompt will cause, at best, a long delay and a lot of disk rattling. But the problem gets worse, of course, when it is made available to anonymous remote users.
Format string vulnerability in mutt. The mutt mailer contains a format string vulnerability which may be remotely exploited by a hostile IMAP server. Updates seen so far include:
licq URL checking problem.MandrakeSoft has issued a security update to licq fixing what appears to be a new problem in that package. It seems that URLs passed to licq are passed on to the web browser with no sanity checking; the result is that an attacker can send commands to be executed on the victim's system. This, needless to say, is not good. Those with licq running on their systems are encouraged to upgrade. RPM building races? Ian Lynagh noticed that a number of RPM "spec" files use /tmp in an unsafe way. A clever attacker could, conceivably, make use of this problem to change system files. In this case, the race is very difficult to exploit; it depends, among other things, on knowing when somebody will decide to rebuild a package from the RPM source file.
CUPS buffer overflow and temporary file creation problems. Check the March 1st LWN Security Summary for the initial report.
This week's updates:March 15, 2001 LWN.
This week's updates:
This week's update:
sgml-tools temporary file vulnerability.See the March 15th LWN security page for the initial report.
This week's updates:
slrn buffer overflow. (First reported in March 15, 2001 LWN).
This week's updates:
EventsNew security paradigms workshop - time is running out. The call for papers for the New Security Paradigms Workshop has a deadline of March 30 - in other words, soon. Since attendance requires the submission of an interesting paper, those who don't get something in before the deadline won't be at the workshop. If you were thinking of going, now is the time to get that abstract together.
Upcoming security events.
For additional security-related events, included training courses (which we don't list above) and events further in the future, check out Security Focus' calendar, one of the primary resources we use for building the above list. To submit an event directly to us, please send a plain-text message to email@example.com.
Section Editor: Liz Coolbaugh
March 22, 2001