Security breach on kernel.org

Earlier this month, a number of servers in the kernel.org infrastructure were compromised. We discovered this August 28th. While we currently believe that the source code repositories were unaffected, we are in the process of verifying this and taking steps to enhance security across the kernel.org infrastructure.

What happened?

Intruders gained root access on the server Hera. We believe they may have gained this access via a compromised user credential; how they managed to exploit that to root access is currently unknown and is being investigated.
Files belonging to ssh (openssh, openssh-server and openssh-clients) were modified and running live.
A trojan startup file was added to the system start up scripts
User interactions were logged, as well as some exploit code. We have retained this for now.
Trojan initially discovered due to the Xnest /dev/mem error message w/o Xnest installed; have been seen on other systems. It is unclear if systems that exhibit this message are susceptible, compromised or not. If developers see this, and you don't have Xnest installed, please investigate.
It *appears* that 3.1-rc2 might have blocked the exploit injector, we don't know if this is intentional or a side affect of another bugfix or change.

What Has Been Done so far:

We have currently taken boxes off line to do a backup and are in the process of doing complete reinstalls.
We have notified authorities in the United States and in Europe to assist with the investigation
We will be doing a full reinstall on all boxes on kernel.org
We are in the process of doing an analysis on the code within git, and the tarballs to confirm that nothing has been modified

The Linux community and kernel.org take the security of the kernel.org domain extremely seriously, and are pursuing all avenues to investigate this attack and prevent future ones.

However, it's also useful to note that the potential damage of cracking kernel.org is far less than typical software repositories. That's because kernel development takes place using the git distributed revision control system, designed by Linus Torvalds. For each of the nearly 40,000 files in the Linux kernel, a cryptographically secure SHA-1 hash is calculated to uniquely define the exact contents of that file. Git is designed so that the name of each version of the kernel depends upon the complete development history leading up to that version. Once it is published, it is not possible to change the old versions without it being noticed.

Those files and the corresponding hashes exist not just on the kernel.org machine and its mirrors, but on the hard drives of each several thousand kernel developers, distribution maintainers, and other users of kernel.org. Any tampering with any file in the kernel.org repository would immediately be noticed by each developer as they updated their personal repository, which most do daily.

We are currently working with the 448 users of kernel.org to change their credentials and change their SSH keys.

We are also currently auditing all security policies to make kernel.org more secure, but are confident that our systems, specifically git, have excellent design to prevent real damage from these types of attacks.
On Aug 25, 2011 Happy 20th Birthday Linux!
For everyone who doesn't know, on this day 20 years ago, a Helsinki Grad student named Linus declared he had a little hobby OS to share with everyone. That original e-mail can be found here.
The rest, as they say, is history!
On June 8, 2011 starting at midnight UTC the Linux Kernel Archives will participate in World IPv6 Day; we will enable IPv6 on as many of our services as possible on that date. At that time the ipv6.kernel.org test address (see below) will be removed.
Currently our e-mail is offline, due to the primary mail server being one of those infected.
May 12, 2011: For testing purposes only, we now have an IPv6 site at http://ipv6.kernel.org. This is a temporary name, and will go away on June 8, 2011. Supported services are http, ftp, rsync, and git.
April 1, 2011: Kernel.org would like to officially unveil are long existing parrallel infrastructure. Since it's inception we've been concerned with total and catastrophic failure of our systems, and have secretely and quietly run a full and parallel infrastructure. Today, we have decided to lift the veil and no longer hide behind the security through obscurity.
Kernel.org would like to Officially announce Kernel.org Skynet.
And for such an unveiling of such an important piece of our infrastructure I would also like to announce the generous donation from Google to help support Skynet: the purchase of an set of aircraft to keep kernel.org in the air at all times, making kernel.org the first flying datacenter! Further details are over on the Skynet website.
Nov 3, 2010: We would like to announce that we have done some fairly major system upgrades to several pieces of our infrastructure. These upgrades were made possible by the generosity of both Google and HP. These upgrades add two new machines to the infrastructure and replace two aging machines that have serve us quite well over the years.
On the replacement front we have replaced mirrors1 and mirrors2, the US based mirror machines, with two new machines.
Mirrors1: Is now an HP DL380 G7 with dual Quad Core E5640 Xeon CPUs, 144G of Ram and 66 x 300G 10K RPM 2.5in drives.
Mirrors2: Is now an HP DL380 G6 with dual Quad Core X5550 Xeon CPUs, 144G of Ram and 66 x 300G 10K RPM 2.5in drives.
UPDATE: Because I've gotten so many e-mails on this, no the 66 drives is not a typo we have two HP MSA70 chassis' attached to each machine. Giving us 25 per chassis, and 16 in the head node meaning 25 + 25 + 16 = 66.
On the new machine front we have acquired two machines, both based out of the US at OSUOSL
Demeter2: We have acquired a machine to run in parallel with our existing dynamic web machine, which hosts such things as bugzilla, the wikis, kerneloops, etc. The new box is an HP HP DL380 G6 with dual Quad Core X5550 Xeon CPUs, 32G of Ram and 8 x 300G 10K RPM 2.5in drives.
Master - Backup: We have acquired a machine to run as a 'live' backup to our master backend machine. What will happen is that we will replace the current master backend machine with the new hardware, and the current master backend machine will become the backup. The new box is an HP HP DL380 G6 with dual Quad Core X5550 Xeon CPUs, 32G of Ram and an external msa70 drive chassis.
Again, a HUGE thanks goes out to Google and HP, with specific shout outs to Chris DiBona and Bdale Garbee for helping make this happen. It's been a long process to get this far, but the equipment is up, and it is proving its worth already!
April 2, 2010: Would like to thank everyone for putting up with, and hopefully enjoying our little April Fools day joke this year. The commentary from various outlets seems to have been generally positive. If you're here and you didn't see it, a semi-permanent home for it will now be at http://userweb.kernel.org/~warthog9/april1/2010/.
We now return you to your regularly scheduled kernel.org, already in progress.
March 18, 2010: We would like to announce the general availability of SSL support for a number of the services on kernel.org! This should help provide an additional level of security, in particular for our dynamic content like the wiki's, patchwork and bugzilla.

The certificates have been very graciously donated and signed by Thawte, and we at kernel.org greatly appreciate their support of Open Source! These signed certificates make it trivial for our users to make use of this additional layer of security, and alleviates a large amount of support effort that self-signed certificates would have incurred.

"Thawte is proud of its open source lineage. Providing free certificates to community
projects is just a small way of not only supporting the community but returning the favor.
Please spread the word."

Services that are now by default using SSL:
Bugzilla
Wikis
Account Requests
Patchwork
Services that can optionally use SSL:
git.kernel.org
android.git.kernel.org
boot.kernel.org
www.kernel.org
Services that DO NOT offer SSL*:
mirrors.kernel.org
* This is because the load on the servers would be too great to adequately support the large amount of content offered there.


From kernel.org。