Intruder signed tampered OpenSSH RPMs with Red Hat key

The Fedora and Red Hat intrusion started in public with silence, which is why the incident still reads like a case study in distribution trust. On August 14, Fedora warned users not to download or update packages while it investigated an infrastructure issue. A week later, Fedora confirmed that one of the compromised servers was a system used for signing Fedora packages, but said the signing passphrase had not been used during the intrusion and source/package checks had found no evidence of Fedora package tampering. Fedora rotated signing keys anyway.

Red Hat's disclosure landed inside RHSA-2008:0855, an OpenSSH security update. The important supply-chain fact was separate from the ordinary OpenSSH X11-cookie fix in the same advisory: an intruder had managed to sign a small number of tampered OpenSSH packages for RHEL 4 on i386 and x86_64, and RHEL 5 on x86_64. That made the trust boundary different from a random mirrored RPM. The packages carried a legitimate Red Hat signature, which is the exact signal RPM tooling and administrators normally use to decide that an update came from the vendor.

Red Hat said it remained "highly confident" that its systems and processes had prevented the intrusion from compromising Red Hat Network or the content distributed via RHN, and accordingly believed customers updating through RHN were not at risk. The risk sat with people who might have obtained Red Hat binary packages outside the subscriber channel. To make that concrete, Red Hat published openssh-blacklist-1.0.sh, a signed detection script that checked installed packages or candidate RPM files against a list of the known tampered packages. The published page documents its PASS and ALERT output and its RPM-filename arguments; how it compares them is not stated there.

The tampered versions were compact but high-value: openssh-3.9p1-8.RHEL4.24, openssh-3.9p1-9.el4, openssh-4.3p2-26, and openssh-4.3p2-26.el5, across the OpenSSH client, server, askpass, debuginfo, and related subpackages. Public CVE records later tracked the trojaned package issue as CVE-2008-3844 with unknown impact. The lasting lesson is that package signing protects the distribution path only while the signing environment remains controlled; once that boundary is crossed, a signature can authenticate the attacker's artifact.