Slashdot Mirror
Kernel.org Compromised
First time accepted submitter JoeF writes "There is a note posted on the main kernel.org page indicating that kernel.org was compromised earlier this month: '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.' The note goes on to say that it is unlikely to have affected the source code repositories, due to the nature of git."
This is bad. Would the same thing happen to MS i dont think /.ers would skip the possibility to bash them.
And seriously, why else would you hack kernel.org?
The post on kernel.org states that it was possibly due to a compromised user account. They stated that they discovered it through some errors related to Xnest /dev/mem and that they captured some of the exploit code. I believe they're still looking at everything to figure how how the intruders got in and what they touched.
Kudos to the kernel.org team for their prompt action and immediate disclosure.
Not really. Try reading the summary all the way through.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
The files are in a git repository. That's what matters, not what you wrap around it to provide for requests.
So http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.4.tar.bz2 gets pulled dynamically from git?
the kernel developers Who Matter
Are you saying users don't?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The post on kernel.org states that it was possibly due to a compromised user account. They stated that they discovered it through some errors related to Xnest /dev/mem and that they captured some of the exploit code. I believe they're still looking at everything to figure how how the intruders got in and what they touched.
Kudos to the kernel.org team for their prompt action and immediate disclosure.
How did the so called user account compromise result in root access? Care to explain?
This space for rent.
If the attackers were worth their salt, after gaining access they would drop in their own custom replacements for patch, make and gcc. For such a large code base, it is not easy to tell if the code going in is yielding the expected instructions.
You know what? Linux users will go right on using plain Linux. Not SE Linux, not OpenBSD, and certainly not Windows. We're not even going to change our root passwords. Why? Because this security breach is not that big a deal.
Yes, it is embarrassing for kernel.org, but the damage is not that great. Sure, we'd all like to prevent security breaches from ever happening in the first place, but I have always thought detection and recovery is more important than prevention. Kernel.org has that covered in spades. Keep backups. Keep many backups. Keep them in many different locations. A distributed source code revision control system such as git does that automatically. Whoever did this wasn't too smart if they were seriously trying to inject a backdoor into the Linux kernel. Now they've blown their cover. They can't have seriously expected the code modifications they tried to go unnoticed for long, unless they have no idea how large projects handle source code. So either they were dumb, or all they were trying to do was embarrass Linux.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Not need to panic. Yet. Most users don't download their kernels from kernel.org. This is a fact. Most users download via the package repositories of their favorite Linux distro, say Ubuntu or Arch. And the kernel maintainers of most distros worth their salt don't use http or ftp to download a fresh copy of the kernel every time Linux decides to update it. They use git.
You are spreading FUD. Sure, it's a serious issue. But not the way you think it is. If the exploit was done through a hole in the kernel, then, and only then, is this a "seriously" "freaking big" issue. If it was done through the usual social engineering channels, then, well, I guess we need a brain patch not a kernel patch. There's simply no fix for that.
If the attackers were worth their salt, after gaining access they would drop in their own custom replacements for patch, make and gcc.
Since patch, make, and gcc are all GNU tools and not part of the Linux kernel, the only harm would be to the single copy on the kernel.org machine. If that machine isn't part of the build process (i.e., if it was merely a file repository), then nothing would be compromised.
It would also be pretty easy to see because builds from other machines wouldn't match.
"why else would you hack kernel.org?"
1337 points.
"National Security is the chief cause of national insecurity." - Celine's First Law
H.P.A. has commit privs and his work laptop was trojanned. That's how. Am I the only one who reads and understands the original e-mails from the admin?
C|N>K
Yeah, like I need to be reminded what year it is on a daily basis.
Actually YMD is useful because it sorts.
The private signing key + passphrase are normally present on hera. So all tarball signatures could be compromised.
Am I the only one who reads and understands the original e-mails from the admin?
Are you? "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. "