UPDATED 13:53 EDT / SEPTEMBER 01 2011

NEWS

Breach Embarrasses Kernel.org, Doesn’t Threaten Linux Security

This week brings dread news to the Linux community when many have learned that an unknown intruder managed to breach the fortified walls of Kernel.org—the storage home and distribution center for the Linux kernel. The intruder managed to gain root access to a server known as Hera and “a number of servers in the kernel.org infrastructure were compromised” according to a notice posted on Kernel.org.

It is believed that the intruder gained access via a compromised user credential and then used an exploit on the server to gain root access—although the exact nature of the tool and hack are still being investigated. Investigators discovered that files belonging to ssh (the application stack that run Secure Shell Host) were modified; a trojan startup file was added to the system start scripts. The bullet points mention user interactions were logged and some exploit code captured but that Kernel.org are keeping those close to the vest.

European authorities will be assisting in the investigation into the intrusion.

What does this mean for the Linux kernel?

Nothing much really.

The incident of someone hacking into Kernel.org, compromising user security, meaning that everyone who uses the system will need to re-roll their security certificates, change their passwords, and otherwise regenerate their credentials will be the most meaningful short-term damage the intruder could have done.

A malicious hacker could certainly want access to the kernel for an operating system distributed as code to millions of computers worldwide—and that’s just the kernel development code, there’s numerous other projects housed there as well—so that they could insert their own malware into the source. However, it’s not so simple. An article written on Linux.com by Jonathan Corbet explains why it would be extremely difficult, if not downright impossible, for any intruder to poison the Linux kernel distribution stack,

A cryptographic “hashing function” is a mathematical formula which boils the contents of a file down to a small number. “Small” is relative; git’s hash function produces 160-bit numbers, which are quite big by normal standards – it is roughly equal to the number of atoms in the Earth. The key to the hash function is that, if the contents of the file change, the hash will change too. Creating any new file matching the hash of an existing file is not really possible; if you want that new file to look like the old one with the exception of a bit of hostile code, the challenge is even bigger. So an attacker would be unable to change a file without changing its hash as well. Git checks hashes regularly, so a simplistic attempt to corrupt a file would be flagged almost immediately.

The hashing does not stop there. For any given state of the kernel source tree, git calculates a hash based on (1) the hashes of all the files contained within that tree, and (2) the hashes of all of the previous states of the tree. So, for example, the hash for the kernel at the 3.0 release is 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe. There is no way to change any of the files within that release – or within any previous release – without changing that hash. If anybody (even the kernel.org repository) were to present a 3.0 kernel with a different hash, it would be immediately apparent that something was not right.

Cryptography is more than just a tool for protecting private information from prying eyes: it can also be used to authenticate information.

In the field, cryptography can be used to verify that a particular document (in this case a bit of source code) had been produced and submitted by a singular individual, at a singular time, and currently retains the features it had when it was produced. This “signature” allows a future program to check to make sure that nothing about the document or the signature had changed in the interim. In a way, this is the best protection possible against an intruder getting into an open source project, such as the Linux kernel, and making their own changes willy nilly.

The only way they’d manage to get malware into the code is if they also managed to compromise the cryptographic certificates used to sign the code, changed the code to their linking, re-signed the code with the proper certificates, and then resubmitted it. Of course, then enterprising kernel hackers would still probably discover what happened when they updated their source and found out that the code had changed, check it out, and possibly even contact the person attributed to the change (who would probably deny it.)

This is the power of not just cryptographic hash checks, but having a thriving community constantly using a particular product.

Also, it should be pointed out that Kernel.org isn’t a repository itself; it’s just a distribution point for the kernel source and other projects. Compromising Kernel.org doesn’t allow an attacker to mess with the Linux kernel source in any meaningful way that wouldn’t be quickly discovered and overturned (if not instantly so.)

It’s a brassy move, whoever did this; but they probably messed with the wrong community.


A message from John Furrier, co-founder of SiliconANGLE:

Your vote of support is important to us and it helps us keep the content FREE.

One click below supports our mission to provide free, deep, and relevant content.  

Join our community on YouTube

Join the community that includes more than 15,000 #CubeAlumni experts, including Amazon.com CEO Andy Jassy, Dell Technologies founder and CEO Michael Dell, Intel CEO Pat Gelsinger, and many more luminaries and experts.

“TheCUBE is an important partner to the industry. You guys really are a part of our events and we really appreciate you coming and I know people appreciate the content you create as well” – Andy Jassy

THANK YOU