Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers.
In connection with the incident, the intruder was able to sign a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64 architecture only). As a precautionary measure, we are releasing an updated version of these packages, and have published a list of the tampered packages and how to detect them at http://www.redhat.com/security/data/openssh-blacklist.html
Man, would I love to see how package signing occurs at Red Hat. I’m going to guess that they’re doing it wrong.
Basically, someone’s managed to get a trojaned SSH package signed by the RH signing authority. Since they were (apparently) unable to get the compromised package into the Red Hat Network, all RHEL customers that use RHN for their updates should be okay.
However, if you use… say… CentOS in your enterprise, it’s probably a good idea for you to take a long hard look at your package repository. You can’t rely on “hey, signature checks out!” to verify trustworthiness.
This is one of those security announcements that is of small immediate practical impact, but worrisome in implications. How does RH sign their packages? How did this occur? How do we know it won’t occur again? I expect the answers to those questions are (a) we’re not going to tell you (b) we’re not going to tell you and (c) trust us, nothing really bad happened this time, right? Slashdot thread.
Full disclosure time, boys. Who screwed up?
Here’s an interesting blog post detailing… well, not much.
The risks mean we’ve had to be really careful who has signing privileges with the legacy key and how the key signing is handled.
The new key, in contrast, was created in a hardware cryptographic device which does not allow the unprotected key material to be exported. This means we can give authorised signers the ability to sign with the key, but no one can ever can get access to the key material itself. This is an important distinction. If for example a current authorised signer switches roles and is no longer responsible for package signing we can instantly revoke their rights and know that they no longer have the ability to sign any more packages with that key.
Two immediate possibilities spring to mind: someone was able to socially engineer a signer into signing a package, or the process has some level of automation in it, and the attacker was able to inject the bad package somewhere in the automation. Either way, it illustrates the point that cryptography isn’t generally the hardest part of security, it’s process that’s the sticky widget.