[conspire] Compromise of a Debian Project host

[Rick Moen]

I wrote:

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

One of the reasons I look forward to the write-up is to see the
rationale for what they're doing to improve security prospectively, and
why.  Quoting
http://news.com.com/Debian+locks+out+developers+after+server+hack/2100-7349_3-6094335.html :  

  "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,"
  Schulze wrote.

  The developer said the attacker then used a recently discovered
  vulnerability in the Linux kernel to gain root--or admin--access on
  the server.

  "An investigation of developer passwords revealed a number of weak
  passwords whose accounts have been locked in response," Schulze wrote. 

Encouraging shell users on shared machine to use strong passwords is 
perhaps worthwhile, but failures to do so on "gluck.debian.org" might
well have been fundamentally irrelevant -- depending on how and where 
the developer account got compromised.

Let me give an example:  Let's say I let about a dozen of my friends and
acquaintances have shell accounts on my Linux box.  Let's say I'm being
something of a security fascist, and configure my local password
management to require eight-character passwords of mixed lettercase
including at least one digit and one special character, with dictionary
words disallowed, mandatory password changes every two months, and an
enforced prohibition against re-using any of the prior 20 expired
passwords.

Friend George, like basically all the rest of us, can't remember very
many passwords accurately, and so he tends to use the same passwords for
his accounts on multiple systems.  One day, one of those _other_ systems
has a security breach.  The bad guys manage to steal George's password
on that system.  They see from his .bash_history file that he SSHes to 
linuxmafia.com, and on speculation try SSHing into my machine using the
same username/password George uses elsewhere.  Because of George's
memory-assisting shortcut, it works.  

Or:

Trying to be even _more_ of a security fascist, I disallow incoming
password authentication entirely, permitting use only of prearranged
SSH public keypairs.  George uses such a keypair, and uses it to SSH 
in from a remote host -- which for entirely local reasons becomes
root-compromised by the bad guys.  The bad guys use their surreptitious
root access to install a "trojaned" SSH client, rigged to capture
outbound sessions' security credentials and secretly convey those to the
intruders.  George in all innocence SSHes into linuxmafia.com, and his
private key and passphrase get captured.  The next day, the bad guys are
able to enter linuxmafia.com, masquerading as George -- and then seek
there a path to root escalation, as they did on "gluck".

My point is that these paths to compromise would work against my machine
_even though_ I was doing everything right.  From what we know of last
Tuesday's Debian compromise, such might well have been the case there,
too -- which would make Martin Schulze's better-passwords effort (quote
above) almost completely irrelevant to the problem.

My Internet systems live with essentially the same risk that "gluck"
faces, and my planning must include the possibility of compromise
through theft elsewhere of user-access credentials, even if I implement
my own security policy flawlessly.  Short of adding a second category
of authenticdation (e.g., SecureID tokens or biometrics), it's not a
problem with a ready solution.


Oddly enough, Jon Corbet at Linux Weekly News is probably feeling like
Cassandra right now:  On July 12, 2006 -- the very same day that "gluck"
was compromised -- he castigated, echoing correspondent Paul Starzetz
(http://lwn.net/Articles/191089/) two authors (for "rpath" and Ubuntu)
who'd described a 2.6 kernel bug as (merely) a "denial of service attack"
bug, when very obviously it was a likely path to local root escalation:
"Denial of reality vulnerabilities" (http://lwn.net/Articles/191080/ -- 
readable by non-LWN-subscribers starting Thursday, July 20).  And that
_was_ the exact kernel bug used to crack root on "gluck".

I'll not quote extensively from Jon's editorial for the obvious reason
that it's a subscription-supported magazine (and deserves all of our
support), but I _will_ quote one very important sentence:

   Lest it seem that rPath and Ubuntu are receiving too much grief: as
   of this writing, five days after disclosure, rPath, Ubuntu, and Red Hat
   are the only distributors to have fixed this problem.

If you're running a 2.6-kernel-based system with remote shell access,
especially from multiple users, you should take careful note.

(Feedback to the LWN editorial reveals that Fedora Core 4 and 5 had
2.6.17.4 kernel updates in the testing area on July 12, Gentoo had
updates to 2.6.16.24 and 2.6.17.4 on July 6 and 7, and Debian "stable" 
aka sarge's default 2.6 kernel, 2.6.8, didn't include the vulnerable code.
Other 2.6 distros may remain unfixed, and are of significant concern.)