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)
security hole?
This is bad. Would the same thing happen to MS i dont think /.ers would skip the possibility to bash them.
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...
Mmm... on the troll scale I'd give it a 2/10. Not really original, neither the statement nor the attempt to avoid being modded down and hence removed from visibility, shows very little understanding of the process and too little effort to be taken serious.
It's a notch above "you sucks cock", mostly for increased length (certainly not content), but it's still a far cry from the quality trolls I've seen.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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)
..to patch their kernels.
Jesus had a UNIX beard.
This is what signed packages are for.
Give me Classic Slashdot or give me death!
But I've always been told by the fanboys that Linux is inherently secure, right? So that's not possible.
But Linux has no viruses/trojans/malware, right?
BTW - if you can't take this as the light jabbing it's supposed to be without wanting to rip my spine out, turn the computer off and take a break. :)
Haven't you learned anything from the recent SSL CA incidents? Signing is only marginally above being absolutely useless. Worse, it gives a false sense of security. It doesn't matter whether it's SSL certs being signed or kernel source code tarballs. Signing is not as secure as you people think it is.
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
Who's going to compromise the Linux kernel servers, and leave the linux kernel alone?
Yea? What part of that don't you understand?
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...
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.
Also, when I go to kernel.org I generally see a lot of .tar.bz2 files for download. 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? So what if the source tree is clean, if the packaged version is not then there was a problem.
If the package signing key gets out in the wild, that is a problem. Aside from that, you cannot really have an issue where someone creates a fake package and gets it past a check, because they simply cannot generate the correct signature. SSL has a flaw that a browser will see "*.google.com" and trust it, even if it was not issued by the actual CA that Google uses. That issue does not exist with signed packages.
I really, really, REALLY hate to say it.... but face it, unless the world decides to police this kind of stuff differently, the bad guys won. Time to take your ball and go home. Between the spam, the malware, the virus's... forget it. We already lost. I've had card accounts hacked 3 times this year and I (like to think I) know what I'm doing. All have been totally random as for me, I just happened to be a customer of a hacked databse each time.. now FRIKNG Disney thinks I owe them something and those asshats won't go away. Even after a court order.
"Computers are a lot like Air Conditioners" "They both work great until you start opening Windows"
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.
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?
I wrote this post in flash but you can't see it.
Seven puppies were harmed during the making of this post.
Yeah, those do nothing for the archive files sitting on the kernel.org homepage.
The kernel.org sources live on OS X Lion boxes - authentication is handled through LDAP.
#DeleteChrome
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
May I point out that you can't be 100% certain that ANY food is "safe" to eat? Unless, of course, you actually grow and process all of your own food.
"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
Aren't the SHA-1 hashes themselves hosted on kernel.org?
This space for rent.
I would. Because that's exactly what the FDA et al does. Newsflash: people arn't perfect, and "pretty damn sure" might as well be "sure"
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...
You manage to post a link to http://kernel.org/ (where the details of the breach have been described in the news section), and then another one to some third party site (thehackernews.com), where all they do is repost the exact same information?
if the kernel source code has been compromised, then every linux computer updated since the attack could be infected (maybe even set top boxes, corporate database servers, etc).
BUT...
because linux is open source, the kernel developers should be able to just compare the suspected compromised source code with a backup from before the attack (or just go back a year and copy in known fixes) and then every computer with a compromised kernel could just run their update program (which is probably how the infected kernel was installed in the first place) and update the kernel with a fresh clean copy. many computers (especially headless web servers) probably autoupdate critical security updates from their distro repos anyway (mine does).
i've had a squiz at the kernel source code in the past and i would think that something injected to prevent the update programs of every major distro from replacing the infected kernel with a clean one wouldn't be very easy to hide. if it simply puts an extra line of text in the bootup sequence that says "linux now has super cow powers" then that will merely make for more interesting slashdot news.
As a user of linux I'm not worried. I have more faith in the linux kernel developers in getting to the bottom of malware issues than any proprietary software development company (you know who i mean).
i'm not familiar with it, but i'm sure git is a good system that gives linus and his minions the ability to efficiently and effectively track down whatever changes may have slipped into the kernel.org versions.
and since the world relies on linux for more than just surfing the net and playing freecell, if serious damage results then it might give governments/corporations some incentive to give a little more support to keeping linux secure in the future.
after all, what other operating system could act as a drop-in replacement for the linux kernel for what it does? really?
If the package signing key gets out in the wild, that is a problem. Aside from that, you cannot really have an issue where someone creates a fake package and gets it past a check, because they simply cannot generate the correct signature. SSL has a flaw that a browser will see "*.google.com" and trust it, even if it was not issued by the actual CA that Google uses. That issue does not exist with signed packages.
Who knows, maybe the intruder has the private signing key and the intrusion was simply to place altered packages? It's also not impossible, although extremely mathematically unfeasible to generate a package that has the same SHA-1.
Certainly, you can see how China would love to insert backdoor into the kernel.
In both Windows Vista and Windows 7*, downloaded files are flagged noexecute and there's a confirmation dialog before any downloaded file can be executed (unless the file has been cryptographically signed by a source the user trusts).
And to be totally clear, these are DEFAULT settings, used by 99% of people.
bmo obviously doesn't have any experience with recent versions of Windows.
(PS since his initial claim was disproven he will probably try to shift goalposts now. Watch and see if now he complains, "Dialog boxes don't work!")
*This might also be present in Windows XP.
Yes, diff against any of the thosand mirrors is going to be reallly really difficult to run and there is going to be rootkits in my linuxes.
s/police/hackers/ And i quote:
JeffK: "Oh noes, teh police! HIDE TEH LUNIX!!!11"
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
It IS present in XP, and has been probably since SP2. As you said, bmo doesnt have a clue.
Indeed, but in that analogy, the person who canned the food originally is where you would ordinarily place your trust and risk assessment (and whether that person/company has a good track record/has official recognition etc), and is they are saying "someone broke in to our factory last night and we're reasonably certain that the food is not poisoned, but we are still checking".
That's the point being addressed here - with the GP seeming to question reading comprehension (he believes the kernel source is totally safe, based on the summary). I'm (and the GGP) don't believe it says that.
You're trying to dig your way out of a hole because you jumped the gun trying to "pwn" someone in the comments and have gone back and read the summary more carefully and now realise it does not say what you first thought.
Even with the FDA, if a situation occurs in a food factory (say, some guys break in and next morning you find empty bottles of poison on the floor), the owners are going to say "it doesn't look like any of the packaged containers have been tampered with, but we are in the process of checking them". This is the situation we are in now.
When giving out a press release, you can be "pretty damn sure" that their words are chosen carefully - if they were certain, they would say so. They will know soon enough, after their investigation.
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 ?
You missed the part that goes 'unlikely to have affected the source code repositories' where """unlikely"""" is newsspeak for anywhere between 'we hope' to 'we have no idea' to 'We are activity working on containing damage before full disclosure'
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?
The office next to the factory has been broken into. While the factory is much more secure, I am none the less in the process of verifying if it has been tampered with, but It's never possible to be 100% certain. It's probably ok.
"I've got more toys than Teruhisa Kitahara."
They get a one time compile of whatever kernel version works on it and then sit in the field with unpatched security leaks until they die, or are replaced with an upgrade. A lot of them still run 2.6.16 or something around that.
I was promised a flying car. Where is my flying car?
Karma: Positive (probably because of superiour intellect)
but not because of superior spelling...
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
1. Rootkit is not a virus.
2. Just because it's called "Phalanx" it does not mean, it can be detected as such by verifying signatures or other such pseudo-security measures. Antiviruses are trivial to bypass, real security isn't.
Contrary to the popular belief, there indeed is no God.
That's because you are fucking stupid.
Contrary to the popular belief, there indeed is no God.
git and the fact that there are distributed copies makes it hard if not impossible to interfere with the source without somebody noticing. But it does nothing for the various tarballs, patches etc sitting there. I assume they could be regenerated, that there are md5sum files and enough copies floating around on mirrors that if there is any tampering it could be detected and restored.
You can't guarantee it's 100% safe to eat even if you grow it yourself.
The anti-vaccination movement often scream that vaccines be proven 100% safe for that reason. It's an unreasonable demand and one which can never be met, at least as far as food and drugs go.
For kernel.org, I think it would be a different matter. They have a discrete number of files, a large number of mirrors, many of which are historical. It should be feasible to compare files and checksums against each other and look for discrepancies. Same for git clones.
What does does this tag mean? Where's your ring snow? What the hell is "ring snow"? Sounds kind of nasty...
My other account has a 3-digit UID.
Unless, of course, you actually grow and process all of your own food.
Unless you modify the soil to insert backdoor genes into the seeds if it detects a certain plant...
Wait, wrong analogy.
Free Manning, jail Obama.
Arch at least stores the hashes in the PKGBUILD files in their own repositories. I think it's MD5 rather than SHA-1.
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.
Let's hope the admins verify Git too then. Attacker had root access after all.
"I'm not much interested in interoperability. I want substitutability. I want to be able to throw your software out."
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*
Should have used OpenBSD for the server!
On the other hand, to make the analogy more detailed: "Someone broke into the factory (or farm, or dairy) within the past month. We've shut down the factory while we check for contamination. We believe the production process itself is tamper-proof, but we're verifying everything just to be sure." Food with an expiration date before (one month ago + normal shelf lifetime) is still safe to use in any case; so anyone currently running a supported commercial distro (think RHEL) or the stable version of a community distro (think Debian) shouldn't need to worry right now.
Oh I'm totally on board with that - if you didn't check out code at any point after the break in you're fine. I'm not trying to spin this out of proportion or anything, just putting across how I think it is right now. At the moment my feeling is "source potentially contaminated after x date, will wait for community checks against the codebase" before saying definitively one way or the other, but it's probably all ok, or will be.
Kernel panic!
Nope. Or 'yes but not only there'. Which is why they're secure, as if anyone changes anything there, it will immediately clash with the rest of the world. They're stored in *every single copy* of the git repository in the world.
I personally have 8 copies of them, for example. (linux-arm, linux-omap, linux-2.6, plus 2 private trees for $DAYJOB each on my old work laptop, linux-2.6 plus one private tree on my current work laptop, and linux-2.6 on my home workstation.)
Your head of state is a corrupt weasel, I hope you're happy.
I download binary packages for my rolling release distro, Arch, from kernel.org. Even if the kernel source has not been compromised a binary package certainly could be.
You certainly don't want to scare away the rich idiots.
Stupid Linus forgot to install Avast.
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*
> sloccount linux-3.0.4
Totals grouped by language (dominant language first):
ansic: 9586286 (96.79%)
asm: 241673 (2.44%)
xml: 41486 (0.42%)
perl: 17494 (0.18%)
sh: 4661 (0.05%)
cpp: 3486 (0.04%)
yacc: 2987 (0.03%)
python: 2770 (0.03%)
lex: 1719 (0.02%)
awk: 708 (0.01%)
pascal: 231 (0.00%)
lisp: 218 (0.00%)
sed: 30 (0.00%)
Total Physical Source Lines of Code (SLOC) = 9,903,749
Fine, you take the Ansi C and I'll do the rest
from the output:
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."
If someone is going to argue that GPOs are HARDER than their Linux equivalent , theres not really any arguing with them.
But then very few of the people in this thread appear to actually have administered Windows enough to make worthwhile criticisms of its administration.
As to parent's comment about "hoops to make a file executable", its pretty darn trivial in whatever os you use, whether chmod a+x file (which is found in a 3 second google), or rightclick--properties--permissions--allow file to be executed (it is in fact HARDER to grant the executable permission from command line in windows, fwiw).
downloaded files are flagged noexecute and there's a confirmation dialog before any downloaded file can be executed
Let's note that this only applies to methods of downloading which are playing nicely within the bolted-on security framework within Windows. If the user is downloading something in a method other than using a mainstream browser or windows file sharing, this doesn't kick in. Reminds me of all the crapware on KaZaA and similar services.
(unless the file has been cryptographically signed by a source the user trusts)
Given the rash of certificate security issues recently, it's pretty clear that signatures are not security. There are also lots of Windows drivers that aren't signed, so users who plug in hardware that isn't covered under an OS-built-in driver are quite familiar with the process of ignoring signature issues.
*This might also be present in Windows XP.
I do believe that SP2 or SP3 enabled this in XP, but it's been quite some time so I'm not sure.
Agreed.
This is about standards, people.
"We live as though the world were as it should be, to show it what it can be." - Joss Whedon via Angel
Besides the articles that were linked to, I'd also check out somebody's question of "Trustworthiness of kernel.org post attack" at http://security.stackexchange.com/q/6768/836 (the site is a cousin to stackoverflow.com).
SIG: HUP