The intrusion was reported to
kernel.org users earlier this week by site administrator John Hawley. The attack is believed to have occurred on August 12 but wasn’t detected until August 28. The attack vector isn’t known for certain, but it is thought that the attacker somehow obtained a legitimate user’s login credentials and then exploited an unknown privilege escalation vulnerability. The attack was discovered when an Xnest error message was found in the system logs on a server that did not have Xnest installed.
This irregularity prompted further investigation, leading to the discovery of a trojan. The SSH server software on the system was modified and a script to initiate the trojan was found among the system startup scripts. The official statement on
kernel.org says that it’s still not clear whether the Xnest error message is actually a symptom of the attack or an anomaly.
The
kernel.org administrators have responded to the security failure by by taking the affected systems offline and contacting law enforcement authorities. All of the
kernel.org servers will be wiped and fully reinstalled. An audit is underway to determine if any of the source or release packages were modified by the attacker. The login credentials and SSH keys of all 448
kernel.org users will also be changed.
The code repositories of the Android Open Source Project (AOSP) are also hosted on
kernel.org. Hawley took down the Android code at Google’s request after the attack was detected. The AOSP git page currently shows a message explaining the situation and indicating that service could possibly be restored as early as September 1.
The extent of the damage is still not clear, but it’s considered highly unlikely that the attacker injected code into the active Linux kernel tree. In a blog post on the
Linux.com website, kernel developer and Linux Weekly News writer Jon Corbet published a detailed explanation of how the Linux kernel development workflow, which has multiple layers of code review and relies on distributed version control, poses barriers to such tampering. As Corbet points out,
kernel.org is more like a distribution channel for the Linux kernel rather than a hub of development activity.
Although the damage is probably not significant, the incident is still an embarrassment for the Linux kernel development community. This attack occurred one week before the Linux Foundation’s annual LinuxCon event, at which the Linux development community celebrated the kernel’s 20th anniversary.
Although successful attacks of this nature against Linux development infrastructure are not common, they do occasionally happen. Red Hat servers were compromised in 2008 and a Debian server was compromised in 2006. It serves as a chilling reminder of the breadth of the threat landscape and the challenges of keeping important systems secured against attacks.
