SRCF compromise

[mas90]

I've spent the past couple of days dealing with a major security incident on the SRCF's main server, pip (almost exactly 18 months since our last such incident). Now that things have calmed down a bit, I thought I'd write something about it for those who expressed an interest in the details.

Comments

Slight addendum

[doismellburning]

(Yes I know you know this, mas90, as you were there - feel free to steal this and append it to your entry, I just wanted to add it as soon as possible)

In a chat with Scotsman at work the following day, he mentioned that he'd tried the exploit on his server, had it work, installed the patch, _not rebooted_, tried the exploit again, and had it fail.

Some post-pub investigation that night with mas90 demonstrated that simply installing the patch (no reboot / (explicit) udevd restart) fixed Debian 5.0 Lenny (on one of my machines), and whichever Debian flavour Scotsman runs, while leaving Ubuntu 8.04 (on one of mas90's machines) and presumably 8.10 (as run by pip) vulnerable until an explicit udevd restart.

Slight correction to slight addendum

[mas90]

Pip runs Ubuntu 8.04.2 too. I haven't investigated the vulnerability in a more recent version yet.

Re: Slight addendum

[mas90]

Also, having patched a few of my machines overnight, I'm beginning to get a feel for why Ubuntu does not automatically restart udevd. This interacted very badly with Xen's userspace components in domain 0 (requiring a complete reboot); I suspect some other things which do magic in /dev would also end up broken.

Re: Slight addendum

[doismellburning]

Lenny Xen Dom0 was fine. umbongo may well have lost its way in the congo.

painter 11

[anonymous]

This is a good,common sense article.Very helpful to one who is just finding the resouces about this part.It will certainly help educate me.

[anonymous]

Good dispatch and this post helped me alot in my college assignement. Gratefulness you as your information..