Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Witty worm

Reflections on Witty by Nicholas Weaver and Dan Ellis. Very good.

On March 20th, 2004, an attacker released a single-packet UDP worm, Witty, into the wild. Although only infecting roughly 12,000 machines, and less than 700 bytes long, this worm represents a dangerous trend in malicious code. The attack is well understood: there have been several analyses [lurhq, disassembly] of the worm itself, and an excellent analysis by Moore and Shannon on the network propagation [caida_witty], including the presence of seeding or hitlisting (starting the worm on a group of systems to speed the initial propagation). But what can we learn about the attacker?

Examining the timeline of events, the worm itself, its malicious payload, and the skills required all point to a sophisticated attacker. Witty was written by an author who was motivated, sophisticated, skilled, and malicious. Although there have been previous well-engineered worms (notably the Morris worm and Nimda), Witty represents a dangerous new trend, combining both skill and malice.

It's actually unfortunate that Witty hasn't gotten the attention lavished on previous worms, as it was a very significant attack. This worm contained a payload malicious to the host computer, was released with almost no time to patch systems. The worm contained no significant bugs, and was written by a malicious author deeply familiar with the theoretical and practical state-of-the-art in worm construction and computer security.

Analysis of Witty worm spread by CAIDA.

posted Mon 7 Jun 2004 in /software/security | link

SSL sucks

mpt has a great post on why SSL sucks.

To me, SSL security certificates have always seemed particularly stupid usability-wise. As I understand it, the system works like this:

1. Alice trusts Fred.
2. Fred trusts Bob.
3. Bob gets a certificate of trustworthiness from Fred.
4. When Alice visits Bob's page, Bob shows Alice his certificate to demonstrate his trustworthiness.

The problems with this system are as follows:

1. Alice doesn't really trust Fred.
2. Fred doesn't really trust Bob.
3. Getting a certificate is too hard, so Bob doesn't bother.
4. When Bob shows Alice his certificate, Alice isn't paying attention.

Nice example of security having nothing to do with the length of your keypairs. (Or rather, I suppose, proper crypto is a necessary but far from sufficient condition.)

Compare and contrast to SSH host and user certificates: no key-distribution infrastructure by default, although you can build it. In the way they're normally used, all it does is give you some kind of indication that the host you're talking to is the same one that was previously on this address: and the remarkable thing is, much of the time that is an adequate protection. If you want a stronger assurance on the first connection, you can authenticate the host's fingerprint by some other means, such as getting it in signed email. If you're really hardcore you can do things like publishing a signed key in secure DNS. At no point is there a bogus requirement to pay Verisign.

biglumber.com is trying to bootstrap SSL certificates from the GPG web of trust. I think this is a pretty good concept, at least for sites accessed by the kind of nerd who knows what a GPG key is. It might be nice if this could be integrated into the client, rather than requiring eyeball comparison of hex fingerprints.

I suppose you could have a little standalone program that checked certificates on demand, and fed them to Mozilla...

posted Tue 16 Dec 2003 in /software/security | link

/tmp sucks

Since January 2003, Debian has had six security advisories relating to insecure temporary files. Most of these are not Debian-specific, but rather problems in the upstream source.

A typical problem is that a program will create a file with a predictable name in /tmp, without adequate checks for whether it already exists. Because /tmp is world-writable, a local attacker can create the file before the program runs, and either make the program write somewhere it shouldn't, or examine what is written.

Many of these are not enormous problems: in the first place, they can only be exploited by an attacker who already has an account on the machine, which is not a problem for most hosts. (Either they are single-user, or the users can be held accountable.) Secondly most of these problems have been in packages that I suspect are not used by the majority of people, such as an emacs IRC client. They're still important to fix, but not as bad as the Windows worms that seem to be currently bringing some companies to a standstill.

SuSE have an article discussing other temporary file security problems from the developer's perspective.

What really annoys me is that most of them could be systematically avoided by using per-user private temporary directories. I suppose this might cause trouble for files that really need to be shared between users but I think those cases are the exception. Of course individual users can set TMPDIR=~/tmp but it would be nice to see it made the system-wide default.

libpam-tmpdir will apparently do this, including creating the temporary directory as needed. It might be nice if it were on by default. I can't see a homepage for it aside from the Debian package page so I don't know if it would be in any other systems.

posted Wed 23 Jul 2003 in /software/security | link

Copyright (C) 1999-2007 Martin Pool.