[conspire] Compromise of a Debian Project host

[Rick Moen]

Early in the morning (European time) of last Wednesday, July 12, the
Debian Project figured out that one of its shared Internet hosts,
"gluck.debian.org", had been security compromised, and immediately took
it down to be studied, rebuilt from trusted program files, and back
within a day.  It look like, as with last time this sort of thing
happened, they detected the compromise pretty much immediately --
probably courtesy of monitoring from the intrusion detetion software
"AIDE".  As before, the package archives weren't penetrated.  ("gluck"
currently fills these roles via DNS aliases:  "cvs", "ddtp", "lintian",
"people", "popcon", "planet", "ports", and "release".  The machines
where packages are created and cryptographically signed are much more
heavily restricted.)

Their quick detection and correction are worth noting.  So is the avenue
of compromise (detailed below).  

Also worth noting is that, if you use your security token on a
compromised machine _anywhere_, it's equally prone to be stolen
regardless of whether it's a strong or weak password, or a public SSH
keypair, etc.  

Debian believes in transparency on security matters, which is why the
earlier (2003) compromise of "klecker", "gluck", "master", and "murphy"
was immediately and extensively analysed in public, on a set of pages
maintained by Wichert Akkerman:  http://www.wiggy.net/debian/explanation/
...which I then wrote about, here:  http://linuxgazette.net/issue98/moen.html
I'm looking forward to a similar disclosure about the 2006 compromise.
Meanwhile, there's this Debian News article:
http://www.debian.org/News/2006/20060713

   At least one developer account has been compromised a while ago and
   has been used by an attacker to gain access to the Debian server. A
   recently discovered local root vulnerability in the Linux kernel has
   then been used to gain root access to the machine.

   At 02:43 UTC on July 12th suspicious mails were received and alarmed
   the Debian admins. The following investigation turned out that a
   developer account was compromised and that a local kernel
   vulnerability has been exploited to gain root access.

This reminds me a lot of the infamous circa-2001 compromise at VA Linux
Systems, where a developer's shell account at public shared server
shells.sourceforge.net was stolen because his SSH credentials were
stolen from him at yet _another_ shared-resource machine (probably a
college shell server), the bad guy SSHed into shells.sourceforge.net 
masquerading as him and rooted & trojaned that host, and then that 
same bad guy stole an SSH token exposed there by a careless VA Linux
Systems sysadmin, and used it to invade the corporate network and
compromise everything there on account of Swiss-cheese internal security
on the corporate LAN, hanging out there until out of boredom he logged
onto the internal IRC server and taunted the CTO.

The Debian Project didn't have that order of disaster, detected
_their_ breach(es) much sooner and more competently, and did not have
the crown jewels (master software archives) exposed to risk from shared
developer boxes.  

Stealing a developer's SSH login credentials, in itself, just gets the
bad guys _in_ (as a grunt user).  What they really want over the long
term is root-user authority.  Ergo, they must find some way to _escalate
privilege_.  In this (last Tuesday's) case, it was a _very_ recently
discovered 2.6 kernel bug:

  The kernel vulnerability that has been used for this compromise is
  referenced as CVE-2006-2451. It only exists in the Linux kernel 2.6.13
  up to versions before 2.6.17.4, and 2.6.16 before 2.6.16.24. The bug
  allows a local user to gain root privileges via the PR_SET_DUMPABLE
  argument of the prctl function and a program that causes a core dump
  file to be created in a directory for which the user does not have
  permissions.

  The current stable release, Debian GNU/Linux 3.1 alias 'sarge',
  contains Linux 2.6.8 and is thus not affected by this problem. The
  compromised server ran Linux 2.6.16.18.

  If you run Linux 2.6.13 up to versions before 2.6.17.4, or Linux
  2.6.16 up to versions before 2.6.16.24, please update your kernel
  immediately.

Note that the 2.4.x kernels are not affected.  (2.6 kernels have been a
bit harder to keep security-fixed, for reasons that would take a while
to explain.)

I'll keep an eye out for a write-up similar to Akkerman's 2003 pages.