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."
"[I]t is unlikely to have affected the source code repositories, due to the nature of git" [emphasis added] Yeah, because no one has ever downloaded the kernel any other way than by making a local fork of the git repository. No one has ever used the http, ftp and rsync links on the kernel.org website, or clicked the "Latest Stable Kernel" icon on that very website, right? Also remember that the mirrors don't mirror the git repositories but the http/ftp archives from kernel.org servers, the very same servers that has been compromised. The kernel.org home page encourages visitors to use those mirrors so it is not unreasonable to assume that some people do in fact use them. How many of them could have downloaded a compromised kernel? How many of them could be using it as we speak? Seriously people, this is big. I really mean totally freaking big. Thanks to the open source nature of the kernel it is trivial to add a rootkit and make a new tarball. If the attackers were worth their salt then they should do exactly that.
Karma: Positive (probably because of superiour intellect)
This is bad. Would the same thing happen to MS i dont think /.ers would skip the possibility to bash them.
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.
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.
> [ 71.610908] ModPointEnabledAccount[4485]: segfault at 7f51210dfaa8 ip 000000000040c544 sp 00007fffdadb5970 error 6 in .logicParser[400000+15000]
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
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
Better question is... what part don't you understand? They think that the source is unaffected, but have not verified that yet. There is a chance, however small, that the source has been affected by this compromise, which is scary news for anybody who's built/updated a new kernel from source since the breech happened.
I know some open source os/kernel take a fanatical devotion to ensuring their code contains no possibility of "privilege escalation", and some linux users and developers make fun of them.
I love linux, for a desktop and for back end servers. but for all else I use another OS
What's to stop an attacker from packaging a patched source and putting it in the place where most of the rolling release distributions are actually pulling it from?
git, and the SHA-1 keys.
Seven puppies were harmed during the making of this post.
Yeah, like I need to be reminded what year it is on a daily basis.
Actually YMD is useful because it sorts.
You have time to lookup the slackware documentation, but not read TFA?
"Trojan initially discovered due to the Xnest /dev/mem error message w/o Xnest installed."
Here's a can of food for you to eat.
I am in the process of verifying if it has been tampered with, but I'm not 100% certain. It's probably ok.
Why aren't you eating it?
But, most neanderthals can't even spell git, or SHA-1. There's no need to relieve their worries - just let them fret. That's the most exercise - mental or otherwise - that many of them will ever get.
This intrusion could be a good thing, all things considered. Maybe it will scare the morons away from using Unix-like kernels, and send them mewling back into the arms of Microsoft. It would be nice to see the "Year of the Linux Desktop", but face it. For that to happen, we'll have to welcome millions of idiots into the Linux world! *shudder*
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
http://slackware.osuosl.org/slackware-13.37/slackware/x/xorg-server-xnest-1.9.5-i486-1.txt
Xnest is an experimental nested server for X
why is anything related to X running on a server used for source control and such things?
especially because the X server executable is usually setuid root. seems to me that is asking for trouble.
and - why would anybody run experimental software on such an important server.
I guess you didn't bother to read the article.
"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."
Maybe he ought to use a laptop with OpenBSD, you think?
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
Here's a hint: the developers use git, which identifies all commits by their SHA1 value, so changing the contents of a commit will cause the SHA1 sum to mismatch which would cause git to howl and complain. So they then build a tarball and upload it to the server. They also upload signatures:
patch-3.0.4.bz2 29-Aug-2011 20:57 94K
patch-3.0.4.bz2.sign 29-Aug-2011 20:57 249
patch-3.0.4.gz 29-Aug-2011 20:57 107K
patch-3.0.4.gz.sign 29-Aug-2011 20:57 249
patch-3.0.4.sign 29-Aug-2011 20:57 249
So unless they manage to compromise the Kernel signing key any changes would be immediately noticeable (assuming people check the signatures, which they do).
It depends. To check the signature , you need the signature, and a public key to verify it.
All an attacker has to do is use his own private key to sign the file , and then replace the public key with his own.
Then it would be verifying just fine.
Offcourse, if you have the public key ( rather than getting it from the site ) , you will know something is wrong.
Slipping shoelaces ?
Imagine the following scenario:
You Download source code from a tarball at kernel.org. You develop against that. You commit to git. You change only 3 files and git tells you there are 20 files changed. This is when you realize that somehow, the tarball differs in 17 files from the git repository.
How many developers actually develop against a freshly downloaded tarball off ftp/http kernel.org mirror, in stead of a checkout/sync from the clean git branch? Because only the ones that do, and also have commit rights to git, would notice.
I was promised a flying car. Where is my flying car?
Intel pays him to work on operating systems that people actually use.
Second: On Windows it's really hard to disallow users to run any programs but the ones in C:\Windows and C:\Program Files while it's trivially easy in UNIX-like systems.
Ahem.
Start | Administrative tools | Local Security Policy | Software Restriction Policies | New Software Restriction Policy
Was that hard? Btw, an administrator can configure this in a group policy and apply it to select users, groups, computer sets etc. The above was a local policy.
Now you have a policy which by default allows only programs to execute from "program files" and "windows"
You can configure much more, like e.g. whether executables on a given path should be allowed to execute with admin privileges, certificate policies, hash based rules etc.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
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. "
Not at all, because it's false.
That log line is not of a kernel crash (we call them 'oops'es, or 'panic's), merely the kernel reporting on a userspace task (Xnest, with process ID 4485) crashing with a segfault (trying to access an invalid/protected address).
Your head of state is a corrupt weasel, I hope you're happy.
Answering self - theregister.co.uk has a link to the emails
http://pastebin.com/BKcmMd47
Your head of state is a corrupt weasel, I hope you're happy.
Doesn't fucking matter, because theory is not practice.
Windows assigns execute permission based on the last 3 letters by default. It's up to the administrator to change this behavior, which hardly ever happens.
In the world of real computers, execute bits are *completely independent* of the name.
Oh please.
The .exe association is merely a convenience, not a security mechanism which "assigns execute permission" as you put it. It is equivalent to how Linux will attempt to run *anything* when you type the name or double-click it. It is a launching mechanism, not a security mechanism.
Yes, Linux has the x bit. Guess what, Windows ACLs has the Traverse/Execute permission. Remove that permission or set up a deny rule and you will not be able to execute that file or files in that directory. Want to ensure that network shares cannot be used to host executables? Set the permissions on the share to deny execute to everyone and set it to inherit.
Windows has your beloved execute permission. And unlike in Linux you can set up deny rules or allow multiple principals (multiple groups and/or users). Most of us just want it to follow the read permission, because it would never be a security boundary anyway.
And then you completely ignore - no strike that - you try to completely dismiss a very cool security feature in Windows (and OS X): Origin based execution policies. You try to dismiss it because it doesn't look like your x bit. But the fact remains that it works for users: Files downloaded from the internet (through a browser or some other agent) are tainted with the "Internet zone". Files copied from network shares are tainted with "Local intranet zone". And you can set up execution policies to deny or allow execution of such files.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
from the output:
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."