Kernel.org Compromised

← Back to Stories (view on slashdot.org)

Posted by samzenpus on Wednesday August 31, 2011 @12:01PM from the everyone-is-doing-it dept.

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."

312 comments

Min score:

Reason:

Sort:

Whoops! by Anonymous Coward · 2011-08-31 12:02 · Score: 0

Scary for us using rolling-release distros.
1. Re:Whoops! by X0563511 · 2011-08-31 12:13 · Score: 3, Informative
  
  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...
2. Re:Whoops! by Anonymous Coward · 2011-08-31 12:30 · Score: 0, Offtopic
  
  Reeding are hard.
3. Re:Whoops! by Hatta · 2011-08-31 12:42 · Score: 1
  
  This is what signed packages are for.
  
  --
  Give me Classic Slashdot or give me death!
4. Re:Whoops! by Anonymous Coward · 2011-08-31 13:00 · Score: 1
  
  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.
5. Re:Whoops! by Anonymous Coward · 2011-08-31 13:02 · Score: 0
  
  Cool, now try comprehension:
  "While we currently believe that the source code repositories were unaffected, we are in the process of verifying this"
6. Re:Whoops! by X0563511 · 2011-08-31 13:16 · Score: 1
  
  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...
7. Re:Whoops! by realityimpaired · 2011-08-31 13:22 · Score: 2
  
  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.
8. Re:Whoops! by Stupendoussteve · 2011-08-31 13:31 · Score: 1
  
  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.
9. Re:Whoops! by Stupendoussteve · 2011-08-31 13:33 · Score: 1
  
  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.
10. Re:Whoops! by Dunbal · 2011-08-31 13:45 · Score: 2
  
  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.
11. Re:Whoops! by jo_ham · 2011-08-31 13:53 · Score: 2
  
  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?
12. Re:Whoops! by Stupendoussteve · 2011-08-31 14:02 · Score: 1
  
  Yeah, those do nothing for the archive files sitting on the kernel.org homepage.
13. Re:Whoops! by Runaway1956 · 2011-08-31 14:09 · Score: 2
  
  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
14. Re:Whoops! by Runaway1956 · 2011-08-31 14:11 · Score: 1
  
  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
15. Re:Whoops! by recoiledsnake · 2011-08-31 14:11 · Score: 1
  
  Aren't the SHA-1 hashes themselves hosted on kernel.org?
  
  --
  This space for rent.
16. Re:Whoops! by Anonymous Coward · 2011-08-31 14:31 · Score: 0
  
  It's open source jackass, it is available to you to go through it and look for malicious code. Jeez, all of you fucktard newbs want everything handed to you on a silver platter.
17. Re:Whoops! by X0563511 · 2011-08-31 14:38 · Score: 1
  
  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...
18. Re:Whoops! by fluffy99 · 2011-08-31 15:06 · Score: 1
  
  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.
19. Re:Whoops! by jo_ham · 2011-08-31 16:06 · Score: 1
  
  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.
20. Re:Whoops! by Anonymous Coward · 2011-08-31 16:11 · Score: 0
  
  What the fuck is wrong with you?
21. Re:Whoops! by jo_ham · 2011-08-31 16:12 · Score: 1
  
  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.
22. Re:Whoops! by kdemetter · 2011-08-31 17:34 · Score: 2
  
  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 ?
23. Re:Whoops! by Anonymous Coward · 2011-08-31 17:44 · Score: 0
  
  What the fuck is wrong with you?
  Although Microsoft did a great job preparing for the Windows 7 Marketing Experience (Have you tried it yet) with their 2008 Slashdot takeover, they haven't been coping well with the more informal aspects of Slashdot tradition.
  Their call center teams do try hard, and you have to admit they do a great job with their well-composed and targeted first posts, carefully planted red-herring misdirections and general creative use of the moderation system, but their hearts really aren't in these troll posts. It's a shame, because there was a time when a Slashdot troll could generate real disgust, anger or confusion, not the pallid "meh" response of these insipid efforts.
24. Re:Whoops! by johncandale · 2011-08-31 17:48 · Score: 1
  
  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'
25. Re:Whoops! by ozmanjusri · 2011-08-31 17:54 · Score: 1
  
  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."
26. Re:Whoops! by DrXym · 2011-08-31 19:41 · Score: 1
  
  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.
27. Re:Whoops! by DrXym · 2011-08-31 19:42 · Score: 1
  
  You can't guarantee it's 100% safe to eat even if you grow it yourself.
28. Re:Whoops! by DrXym · 2011-08-31 19:47 · Score: 1
  
  The FDA takes all reasonable measures to ensure food & drug safety but there is no way to prove anything is 100% safe. You could line up 2 million volunteers to sample the food and all show no ill effects. The 2 million and one person to sample it might drop dead of some hitherto undiscovered allergy.
  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.
29. Re:Whoops! by he-sk · 2011-08-31 21:32 · Score: 1
  
  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.
30. Re:Whoops! by GigaplexNZ · 2011-08-31 22:46 · Score: 1
  
  Arch at least stores the hashes in the PKGBUILD files in their own repositories. I think it's MD5 rather than SHA-1.
31. Re:Whoops! by Caesar+Tjalbo · 2011-08-31 23:08 · Score: 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."
32. Re:Whoops! by Anonymous Coward · 2011-09-01 00:13 · Score: 0
  
  Perhaps you should familiarize yourself with the concept of the Web of trust, Public keys' trustworthyness can be verified, even without possessing the key in advance
33. Re:Whoops! by lamber45 · 2011-09-01 01:11 · Score: 1
  
  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.
34. Re:Whoops! by jo_ham · 2011-09-01 01:57 · Score: 1
  
  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.
35. Re:Whoops! by You're+All+Wrong · 2011-09-01 02:37 · Score: 1
  
  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.
36. Re:Whoops! by Spykk · 2011-09-01 03:10 · Score: 1
  
  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.
37. Re:Whoops! by sourcerror · 2011-09-01 03:14 · Score: 1
  
  You certainly don't want to scare away the rich idiots.
38. Re:Whoops! by rubycodez · 2011-09-01 08:46 · Score: 1
  
  > 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
39. Re:Whoops! by thePuck77 · 2011-09-02 02:44 · Score: 1
  
  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
Wishful thinking by Mensa+Babe · 2011-08-31 12:03 · Score: 2, Insightful

"[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)
1. Re:Wishful thinking by Anonymous Coward · 2011-08-31 12:08 · Score: 5, Insightful
  
  And seriously, why else would you hack kernel.org?
2. Re:Wishful thinking by Amouth · 2011-08-31 12:14 · Score: 1
  
  but if the repos are still good - then it should be easy to trace any changes/modifications to the other distribution channels - and update/inform the people who use them
  
  --
  '...if only "Jumping to a Conclusion" was an event in the Olympics.'
3. Re:Wishful thinking by X0563511 · 2011-08-31 12:15 · Score: 2, Insightful
  
  Are you stupid?
  The files are in a git repository. That's what matters, not what you wrap around it to provide for requests. Anyone who happened to have a local git copy will notice VERY QUICKLY what changed when they try to commit... and I'd venture to say that nearly all of the kernel developers Who Matter use git for their development workflow.
  
  --
  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...
4. Re:Wishful thinking by recoiledsnake · 2011-08-31 12:15 · Score: 0, Flamebait
  
  Not to mention that if it was a Microsoft server compromised, everyone here would be screaming bloody hell here LOL M$
  Also, whatever happened to the canard that Linux is more secure than Windows Server with the right admins? Do admins get more hardcore than that administer key servers like Kernel.org's, RedHat's, Debian's ?
  Ubuntu servers hacked.
  http://it.slashdot.org/article.pl?sid=07/08/15/1341224
  Fedora/Redhat servers hacked.
  http://linux.slashdot.org/story/08/08/22/1341247/Red-Hat-Fedora-Servers-Compromised
  Debian servers hacked.
  http://www.computerworld.com/s/article/87516/Debian_Project_servers_hacked
  Gentoo
  http://news.cnet.com/Hacked-Gentoo-Linux-server-taken-offline/2100-7349_3-5113227.html
  Not to mention the whole Debian SSL fiasco that left people's SSL communications compromisable because a downstream distro package builder messed with upstream code.
  
  --
  This space for rent.
5. Re:Wishful thinking by Anonymous Coward · 2011-08-31 12:25 · Score: 0
  
  I think that parent is worried about linux USERS (not DEVELOPERS) downloading the kernel from the official links on the website possibly having a backdoor installed right now, not about the linux REPOSITORY being compromised.
6. Re:Wishful thinking by Anonymous Coward · 2011-08-31 12:25 · Score: 0
  
  Well... none of us would notice a corrupted tarball or diff or incremental diff, so yes, it is bad. None of the master copies (used by every distro worth its salt and real kernel developer) have been corrupted, but the stuff used by users and crap distros might have been trojaned.
  And there is a lot of other stuff in *.kernel.org that isn't a git repo, including full mirrors of a number of distros, which will now require a rsync -c to be safe. This would be so painful to the source servers (it is > 1TB of crap to checksum), it is probably best to just restore it all from an old backup then run a massively large rsync pulse.
7. Re:Wishful thinking by Hatta · 2011-08-31 12:33 · Score: 0
  
  I'm pretty miffed. I just installed Linux on a new laptop from kernel.org last weekend. I was just getting comfortable and now I'll have to reinstall.
  
  --
  Give me Classic Slashdot or give me death!
8. Re:Wishful thinking by drolli · 2011-08-31 12:36 · Score: 1
  
  Ahem. i did not leave my email there to notify me the last time i downloaded the tarball
9. Re:Wishful thinking by Manfre · 2011-08-31 12:50 · Score: 3, Insightful
  
  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.
10. Re:Wishful thinking by Anonymous Coward · 2011-08-31 12:54 · Score: 0
  
  Every single kernel tarball/patch is cryptographically signed with the Linux kernel's signing keys. So, unless the Linux kernel signing keys have been compromised, and from what I read it hasn't, then the tampering of the code can be instantly detected by simply verifying the tarball with the signature.
11. Re:Wishful thinking by Anonymous Coward · 2011-08-31 12:54 · Score: 0
  
  But it is is easy to tell if the hashes of the files changes. The next person who pulled from the central repo would notice very quickly. Hence "due to the nature of git".
12. Re:Wishful thinking by bzipitidoo · 2011-08-31 12:56 · Score: 4, Interesting
  
  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"
13. Re:Wishful thinking by drolli · 2011-08-31 13:02 · Score: 1
  
  Actually, i think you are wrong. As far as i understand the repository is not checked during a commit. Edit directly in the repository and your modification will only be uncovered by git-fsck AFAIU.
14. Re:Wishful thinking by Anonymous Coward · 2011-08-31 13:02 · Score: 0
  
  It's obvious to me too but the /. summary says that it's ok because it's git and everyone ignores that the users may have downloaded compromised kernels from the links on the website so the OP may have a point here.
15. Re:Wishful thinking by nabsltd · 2011-08-31 13:04 · Score: 5, Informative
  
  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.
16. Re:Wishful thinking by Anonymous Coward · 2011-08-31 13:09 · Score: 0
  
  Those are not the source code repositories. They are download files.
  Vendors use the repo. Both people potentially affected by building their kernel from vanilla tarballs have probably checked it.
17. Re:Wishful thinking by msauve · 2011-08-31 13:15 · Score: 4, Insightful
  
  "why else would you hack kernel.org?"
  
  1337 points.
  
  --
  "National Security is the chief cause of national insecurity." - Celine's First Law
18. Re:Wishful thinking by X0563511 · 2011-08-31 13:17 · Score: 1
  
  Oh.
  Well. You DO check the signatures right? Those are there for a reason...
  
  --
  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...
19. Re:Wishful thinking by Anonymous Coward · 2011-08-31 13:17 · Score: 1
  
  Everyone here is assuming that the only harm that the attackers might do was to change the Linux source in the Git repository. What about users who just download the tarballs? If the attackers have compromised the website they might have posted tarballs with rootkits for people to download. Controlling the domain they could even do this without uploading the compromised tarballs to the real servers. Why everyone is assuming that the users who download tarballs couldn't be the target of the attackers? Is it only either Git repo or nothing? I'm sure that the kernel.org website can be rebuilt, that the Git repo is ok. But what about *users* who might have downloaded backdoors during the short time when the servers they trusted were controlled by the attackers?
20. Re:Wishful thinking by donotlizard · 2011-08-31 13:24 · Score: 1
  
  How much are 1337 points worth in Bitcoin?
21. Re:Wishful thinking by Anonymous Coward · 2011-08-31 13:36 · Score: 0, Interesting
  
  If you use Linux, then either you use kernels provided by someone you trust to handle security updates for you, such as the standard kernels from your distribution, or you take full responsibility for knowing about things like this and making sure you don't end up using a kernel built from a compromised tarball. There is no third option.
  If you are downloading tarballs of raw Linux kernel source code and not proactively monitoring kernel-related security announcements, then quite frankly you are an utter imbecile who deserves whatever consequences you get.
22. Re:Wishful thinking by Stupendoussteve · 2011-08-31 13:46 · Score: 1
  
  They don't exactly go out of their way to draw attention to the fact that the signatures even exist, do they? The mention of signing is after the paragraphs of recent news, which most users are not likely looking at when they go to download the file. The .sign file is hidden in the file structure, no link on the main page.
  The fact that they provide a nice, bold link to the current version without even a smaller link to its corresponding signature is a pretty big oversight. Even basic projects generally provide a link to at least an md5sum.
23. Re:Wishful thinking by Anonymous Coward · 2011-08-31 14:04 · Score: 1
  
  FTA: "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."
24. Re:Wishful thinking by msauve · 2011-08-31 14:11 · Score: 1
  
  Enough to fill your bit bucket.
  
  --
  "National Security is the chief cause of national insecurity." - Celine's First Law
25. Re:Wishful thinking by Anonymous Coward · 2011-08-31 14:28 · Score: 0
  
  For the lulz? For Zombo.com?
26. Re:Wishful thinking by unencode200x · 2011-08-31 14:57 · Score: 1
  
  I read through their description of what happened and at least they're being open and honest about it.
  
  --
  
  Chance favors the prepared mind.
  Perfect is the enemy of good.
27. Re:Wishful thinking by skids · 2011-08-31 15:44 · Score: 1
  
  Ahem. i did not leave my email there to notify me the last time i downloaded the tarball
  ...why anonymous ftp and leaving your email address in the password field can be a good thing. Not that anyone does that anymore.
  The main point is, it won't take a line by line audit to look for malicious code, rather just working with the crypto to verify a chain of trust.
  
  --
  Someone had to do it.
28. Re:Wishful thinking by synthespian · 2011-08-31 15:57 · Score: 1
  
  Do admins get more hardcore than that administer key servers like Kernel.org's, RedHat's, Debian's ?
  Yeah, they do. Such as Open Wall Linux Project, spearheaded by one Solar Designer.
  
  --
  Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
29. Re:Wishful thinking by synthespian · 2011-08-31 16:06 · Score: 1
  
  You know what? Linux users will go right on using plain Linux. Not SE Linux, not OpenBSD, and certainly not Windows.
  Maybe the Ubuntu users. Myself, I like a kernel enhanced with capabilities. It saved my butt once from the bugs the mighty kernel developers introduce ever so often in the kernel, with their "release early, release often" philosophy (we see now where that leads with this incident).
  
  --
  Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
30. Re:Wishful thinking by Anonymous Coward · 2011-08-31 16:29 · Score: 0
  
  Would a sophisticated attacker be able to insert malicious code into the git repository, and then through some sort of checksum exploit make a set of malicious changesets with the same checksums as the original such that normal git usage would not detect the changes?
  Just wondering
31. Re:Wishful thinking by phantomfive · 2011-08-31 16:59 · Score: 2
  
  It would also be pretty easy to see because builds from other machines wouldn't match.
  Would it? I'm wondering because in all my life, downloading and compiling stuff, I've never compared a binary with one compiled on a different machine to see if it matched. Maybe someone would, which is why I am asking. Are there people who commonly do that? Why?
  
  --
  "First they came for the slanderers and i said nothing."
32. Re:Wishful thinking by shutdown+-p+now · 2011-08-31 17:27 · Score: 1
  
  Check signatures against what? kernel.org? the one that was hacked?
  Or your package manager (.ebuild or whatever)? the one that might have been made while a "patched" tarball was already up, and contains the matching hash?
  (for the record, I think it's highly unlikely, but all distros should definitely audit their kernel packages to see what they built them from)
33. Re:Wishful thinking by shutdown+-p+now · 2011-08-31 17:29 · Score: 1
  
  Since patch, make, and gcc are all GNU tools and not part of the Linux kernel
  It's not exactly hard to make a kernel that would specifically check for loading of those processes, and patch them up on the fly to make them behave as it needs.
34. Re:Wishful thinking by Anonymous Coward · 2011-08-31 18:44 · Score: 0
  
  Thanks for the FUD, smart mensa person!
35. Re:Wishful thinking by Anonymous Coward · 2011-08-31 18:54 · Score: 0
  
  I've got a 3.0.1 tarball from the 6th, a 3.0.3 tarball from the 21st and a 3.0.4 tarball from today all taken from kernel.org that match up with what's in git right now (and verify ok with gpg, though that means nothing if the key has been owned), so unless the repository also got hit (in which case everybody is screwed and the damage will probably be next-to-impossible to contain), people probably don't need to panic if they've used the tarballs.
  
  ...unless of course the attackers went for the convoluted route of making the payload hide it's own downloaded source.
36. Re:Wishful thinking by Anonymous Coward · 2011-08-31 19:33 · Score: 1
  
  kernel.org has a pretty nice bandwidth.
  I'd hate to be at the other end of that ping -f
  For pretty much all reasons there are to hack any generic server kernel.org is a very nice target.
37. Re:Wishful thinking by smash · 2011-08-31 20:08 · Score: 1
  
  So, the next question is "how long ago were they compromised"?
  Did they discover this compromise by chance, or were they running an IDS and picked it up instantly/within a day or so?
  If they've been compromised for months, then there are potentially millions of users affected.
  Just because there have been no kernel-related security announcements, it doesn't mean that there have not been kernel releated security compromises.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
38. Re:Wishful thinking by smash · 2011-08-31 20:14 · Score: 1
  
  Maybe even replacements for the git tools, too.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
39. Re:Wishful thinking by Anonymous Coward · 2011-08-31 22:24 · Score: 0
  
  "[I]t is unlikely to have affected the source code repositories, due to the nature of git"
  They didn't claim anything besides the source code repositories was unaffected, that's why they are investigating and rebuilding the servers.
  The strength of git, and the reason I started using it, is that the repository is set up as content addressable storage, objects are identified by the SHA1 hashes on their contents. Every change on a file will add a new object with a new hash to the repository. Directories are represented by tree objects, which contain the hashes of all the files in the directory. Change a file and its hash will change, references to it in tree objects change, hashes of tree objects change all the way up to the root of the source tree. All changes are added to the repository. Tree objects are identified by their hashes too, of course.
  Commit objects contain the hash of the top level tree object representing the current state of the source tree, as well as the hash or hashes of the parent commit objects, so their identifying hashes depend on what they point to the same way as with tree objects. This means that the hash of a commit object depends on the current contents of the source tree and on its entire history. Change a single bit anywhere in that history, and an avalanche of hashes has to change. And you can put GPG signatures on commits using tag objects, which won't verify after such a change.
  Checking the integrity of a repository isn't difficult. Do the hashes match the content of objects? Are objects pointed to in other objects present in the repository? Do the GPG signatures check out? That's about it.
  Because it's a distributed system there are many copies of the repository around. Any conflcts become apparent immediately. If you try to merge a repository that has been tampered with (and has its hashes changed) with a good one you will get errors, because the branches (pointers to commits stored in the metadata) don't match. If you somehow force the merge anyway the two versions will show up as separate branches.
  This is an extremely elegant and robust scheme, built right into the foundation of git, it's not an afterthought. You get an audit trail that simply can't be messed with. Ok, SHA1 is not considered as strong as it used to, but to replace a source file with another source file with the same hash that actually compiles and does what you want it to do is impossible in practice. And even that can be found by simply comparing different copies of the repository.
40. Re:Wishful thinking by bfields · 2011-08-31 22:39 · Score: 1
  
  http, ftp and rsync links on the kernel.org website, or clicked the "Latest Stable Kernel" icon on that very website, right?
  Fair enough. Note, though, that most users get their kernels from their distro, who build them from source that hopefully they got out of git or otherwise verified.
  Also in theory it should be easy to verify the tarballs that were distributed. It'll be interesting to see whether that turns up anything.
  
  Thanks to the open source nature of the kernel it is trivial to add a rootkit and make a new tarball.
  Open source? I think you overestimate the difficulty of malicious modification of binaries.
41. Re:Wishful thinking by sl4shd0rk · 2011-08-31 22:53 · Score: 1
  
  for the lulz
  
  --
  Join the Slashcott! Feb 10 thru Feb 17!
42. Re:Wishful thinking by You're+All+Wrong · 2011-09-01 00:07 · Score: 2
  
  What complete bollocks.
  
  "Thanks to the open source nature of the kernel it is trivial to add a rootkit and make a new tarball."
  But you've not "added a rootkit". All you've done is make a new tarball with an added rootkit. The *actual* linux source, the git repository, which due to the nature of git is cryptographically signed and distributed/mirrored on thousands of machines round the world, remains completely untouched. And were it to be touched, every other mirror of it would immediately know about the change.
  
  This is tiny, not big. I say that as someone who _regularly_ downloads the kernel. (Three times today, for example, but that's exceptional.)
  
  You're scaremongering, that's all.
  
  --
  Your head of state is a corrupt weasel, I hope you're happy.
43. Re:Wishful thinking by Anonymous Coward · 2011-09-01 00:29 · Score: 0
  
  So either they were dumb, or all they were trying to do was embarrass Linux.
  So either way, Microsoft could be a possible suspect here?
44. Re:Wishful thinking by satuon · 2011-09-01 01:12 · Score: 1
  
  Most people would download the source code and compile it on their local machine which has its local make patch and gcc. Not the ones from the kernel.org server. Does kernel.org even offer precompiled images?
45. Re:Wishful thinking by You're+All+Wrong · 2011-09-01 01:46 · Score: 1
  
  Every single reference to a change to the kernel is in terms of a commit id. It's not a case of going out of the way to use signatures, the *whole way* is signatures. It's signatures all the way down to the empty directory before the first commit was performed.
  
  Hence Linus' jape about compression. He's compressed gigabytes of files, changes, and commentary down to 40 characters.
  
  --
  Your head of state is a corrupt weasel, I hope you're happy.
46. Re:Wishful thinking by Anonymous Coward · 2011-09-01 02:21 · Score: 0
  
  No, if you read the article,they did not immediately detect the intrusion.
47. Re:Wishful thinking by Em+Adespoton · 2011-09-01 04:20 · Score: 1
  
  Your SCM will alert you that they differ when you attempt to commit. Therefore, anyone actually updating the files on the compromised server will be alerted that something has changed, and even get a diff as to what that is. If they can't trace that change back to another legit comitter (or if the change isn't logged in the SCM), they'll know it's rogue data, and restore the last known good state.
48. Re:Wishful thinking by phantomfive · 2011-09-01 04:28 · Score: 1
  
  Who commits binaries?
  
  --
  "First they came for the slanderers and i said nothing."
49. Re:Wishful thinking by Anonymous Coward · 2011-09-01 07:50 · Score: 0
  
  No, it's because there are multiple copies of every changed state since this breach - and those are stored across the world each one can be verified. Compromising this server gains very little. It's not good... but it's not the disaster it would be with a centralised system.
50. Re:Wishful thinking by markkezner · 2011-09-01 08:17 · Score: 1
  
  For this to work, the malicious code added to the repository would have to both accomplish an attack and somehow add the correct "fudge" characters to the data in order to produce a SHA1 hash ("checksum") that matches the target SHA1. This is called a "collision" and the probability of being able to do so is ridiculously small. The attacker would probably have to repeatedly brute-force the production of these "fudge" characters and recompute the SHA1, which is computationally very expensive by design.
  Even if they accomplish this, the attacker would have to convince other git users to pull in their changes, and hope that nobody notices the oddball fudge characters floating around in the change set. So all in all I don't see it happening.
  
  --
  Dangerous, sexy, turing complete: Femme Bots
51. Re:Wishful thinking by uninformedLuddite · 2011-09-01 18:45 · Score: 1
  
  to make your penis larger
  
  --
  The new right fascists are bilingual. They speak English and Bullshit.
52. Re:Wishful thinking by Anonymous Coward · 2011-09-03 05:11 · Score: 0
  
  woken.webs.com
53. Re:Wishful thinking by Anonymous Coward · 2011-09-05 01:26 · Score: 0
  
  And seriously, why else would you hack kernel.org?
  Some would for the bragging rights. Others for yet another box in their botnet.
How did they hack it? by zymano · 2011-08-31 12:03 · Score: 1

security hole?
1. Re:How did they hack it? by gchaix · 2011-08-31 12:10 · Score: 4, Informative
  
  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.
2. Re:How did they hack it? by recoiledsnake · 2011-08-31 12:30 · Score: 3, Insightful
  
  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.
3. Re:How did they hack it? by gchaix · 2011-08-31 12:39 · Score: 1
  
  How did the so called user account compromise result in root access? Care to explain?
  I'm not privy to the details, but I expect disclosure will be forthcoming as soon as they've traced and patched whatever vulnerability was exploited.
4. Re:How did they hack it? by Anonymous Coward · 2011-08-31 12:40 · Score: 1
  
  That's easy with a 0day exploit. However, it wasn't that easy, as you see some of the intruders exploits crashed the
  kernel. e.g.:
  http://www.spinics.net/lists/kernel/msg1229170.html
  note the:
  > [ 71.610908] Xnest[4485]: segfault at 7f51210dfaa8 ip 000000000040c544 sp 00007fffdadb5970 error 6 in .p-2.5f[400000+15000]
  > .p-2.5f = phalanx 2.5f rootkit [currently, not being detected by chkrootkit and khunter]
5. Re:How did they hack it? by cultiv8 · 2011-08-31 12:40 · Score: 1
  
  Well if it was a guru hacker it was something like:
  % cat
  Hello World.
  ^D
  
  --
  sysadmins and parents of newborns get the same amount of sleep.
6. Re:How did they hack it? by Anonymous Coward · 2011-08-31 13:08 · Score: 0, Interesting
  
  Mod this up.
  The worst part is coming back up online before they've figured out how the intruder got in! How do they know that the perps won't just re-do the exploit? If this were, say, Sony, they'd be getting pilloried.
7. Re:How did they hack it? by inode_buddha · 2011-08-31 13:21 · Score: 5, Informative
  
  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
8. Re:How did they hack it? by rubycodez · 2011-08-31 13:27 · Score: 2
  
  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
9. Re:How did they hack it? by MadMaverick9 · 2011-08-31 13:33 · Score: 1
  
  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.
10. Re:How did they hack it? by tibit · 2011-08-31 13:49 · Score: 1
  
  Xnest was a bystander. It was probably a binary where the backdoor/exploit was living after the original intrusion.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
11. Re:How did they hack it? by Anonymous Coward · 2011-08-31 13:49 · Score: 2, Informative
  
  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."
12. Re:How did they hack it? by MadMaverick9 · 2011-08-31 13:55 · Score: 1
  
  Can you please explain how one can get an Xnest error message without Xnest being installed.
  that does not make sense to me.
13. Re:How did they hack it? by Anonymous Coward · 2011-08-31 14:41 · Score: 0
  
  They could, gee I dunno, avoid having Xnest on the system this time.
14. Re:How did they hack it? by monkyyy · 2011-08-31 14:56 · Score: 0
  
  meh 3 days is quick in the "oh i screwed up, i should tell someone but i dont want people to know" dept. much better then never, or when someone else finds out years later, like most places
  
  --
  warning pointless sig
15. Re:How did they hack it? by Anonymous Coward · 2011-08-31 15:03 · Score: 1
  
  mv trojan Xnest && ./Xnest
16. Re:How did they hack it? by monkyyy · 2011-08-31 15:03 · Score: 0
  
  someone installed it w/o wanting anyone to know it was installed, i.e. the hacker
  
  --
  warning pointless sig
17. Re:How did they hack it? by fluffy99 · 2011-08-31 15:40 · Score: 2
  
  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."
18. Re:How did they hack it? by Anonymous Coward · 2011-08-31 15:46 · Score: 0
  
  Am I the only one who reads
  Pretty much. Reading the article, even knowing how atrociously wrong the summaries are, excludes 95% of the crowd who are commenting on these stories.
  
  ...and understands the original e-mails from the admin?
  And there goes the vast majority of the rest.
  For all their bluster, the awkward truth is most Slashdot posters are technically inept and have little knowledge to back up their (usually laughably wrong) ranting.
19. Re:How did they hack it? by synthespian · 2011-08-31 16:09 · Score: 2
  
  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
20. Re:How did they hack it? by acooks · 2011-08-31 17:55 · Score: 1
  
  People are half-duplex beings. Sometimes we RTFA and sometimes we skip TFA and go straight to output mode and dump core all over the comments.
21. Re:How did they hack it? by Anonymous Coward · 2011-08-31 18:16 · Score: 2, Funny
  
  Intel pays him to work on operating systems that people actually use.
22. Re:How did they hack it? by zixxt · 2011-08-31 19:31 · Score: 1
  
  Maybe he ought to use a laptop with OpenBSD, you think?
  The OpenBSD is secure myth as got its fanbois out in droves on this thread it seems.
  
  --
  ---- GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
23. Re:How did they hack it? by ShakaUVM · 2011-08-31 21:20 · Score: 0
  
  >>as you see some of the intruders exploits crashed the kernel.
  Ouch.
  Well, that's ironic.
24. Re:How did they hack it? by Anonymous Coward · 2011-08-31 22:54 · Score: 1
  
  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?
  You think commit privs require root access?
25. Re:How did they hack it? by Raenex · 2011-09-01 00:05 · Score: 3, Informative
  
  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. "
26. Re:How did they hack it? by You're+All+Wrong · 2011-09-01 02:13 · Score: 2
  
  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.
27. Re:How did they hack it? by You're+All+Wrong · 2011-09-01 02:18 · Score: 1
  
  You are apparently the only one who reads the original emails, as the rest of us don't have links to those emails. Cite please.
  
  --
  Your head of state is a corrupt weasel, I hope you're happy.
28. Re:How did they hack it? by You're+All+Wrong · 2011-09-01 02:45 · Score: 2
  
  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.
29. Re:How did they hack it? by Anonymous Coward · 2011-09-01 04:14 · Score: 0
  
  a malicious process at some point of its life on that server called itself "Xnest", while in fact it was not the actual Xnest as commonly intended (an X server). Understand?
30. Re:How did they hack it? by Anonymous Coward · 2011-09-02 04:04 · Score: 0
  
  He actually works on Linux, not Windows.
Oops by drolli · 2011-08-31 12:05 · Score: 4, Insightful

This is bad. Would the same thing happen to MS i dont think /.ers would skip the possibility to bash them.
1. Re:Oops by Anonymous Coward · 2011-08-31 12:16 · Score: 0, Insightful
  
  I clicked on this story with the sole intention of posting a smarmy, "HEY GAIZ I THOT LUNIX WAS SEKYOOR?" comment.
  But more seriously, the fact of the matter is, most of the tripe spewed against Microsoft hasn't been true since the pre-XP era. This combines with idiots who don't comprehend what security actually is, and buy into the, "LINUX IS TOTALLY SECURE! LOLZ!" crap.
  The truth is, if you want a truly secure system, in terms of h4x0rz, you want a system that's not connected to the Internet.
  If you want a what-the-hell-are-you-doing-with-that-server-comrade secure system, you'll use OpenBSD.
  Linux? Linux isn't as secure as people love to claim. That's not to say it can't be secure - at least in terms of secure for mostly anyone's needs - it simply takes knowledge and, yanno, actual maintenance - but this is no different than Windows, despite the FUD.
2. Re:Oops by bmo · 2011-08-31 12:25 · Score: 1, Insightful
  
  >but this is no different than Windows, despite the FUD.
  >no different than windows.
  THIS IS WHAT WINDOWS FANBOIS REALLY BELIEVE.
  Get back to me when Windows separates execute permission from the filename extension.
  --
  BMO
3. Re:Oops by jrbrtsn · 2011-08-31 12:42 · Score: 5, Insightful
  
  If the same thing happened to Microsoft, Microsoft wouldn't let anybody know.
4. Re:Oops by Anonymous Coward · 2011-08-31 12:44 · Score: 0
  
  Get back to me when Windows separates execute permission from the filename extension.
  Execute permission only exists so people don't accidentally crash their shell by running non-programs; it has nothing to do with security. If you can create a file, you can chmod it.
5. Re:Oops by bmo · 2011-08-31 12:49 · Score: 0
  
  >Execute permission only exists so people don't accidentally crash their shell by running non-programs; it has nothing to do with security.
  Bullshit.
  Stripping execute permission when I fling a program across the network is important in stopping the automatic propagation of evil.
  Windows just sees the .exe and says "whoopee, we can execute it!"
  Inserting a simple chmod or even a right-click set-permissions by involving a human in the process puts an end to a lot of bullshit.
  --
  BMO
6. Re:Oops by MaxBooger · 2011-08-31 12:52 · Score: 4, Funny
  
  This is bad. Would the same thing happen to MS i dont think /.ers would skip the possibility to bash them.
  Nah. They wouldn't bash them. cmd them, maybe. But not bash them.
7. Re:Oops by Sarten-X · 2011-08-31 12:54 · Score: 2
  
  ...but you can't always chmod the same way you create. I can upload a nice "text file" to a web server, and it's going to sit as a text file forever, regardless of extension.
  
  --
  You do not have a moral or legal right to do absolutely anything you want.
8. Re:Oops by Anonymous Coward · 2011-08-31 13:00 · Score: 0
  
  No, actually what you are saying is wrong. Windows doesn't require EXE to run something. And it doesn't give permissions to all EXE. You have to have the execute permissions which is assigned to users based on the perms on the file.
9. Re:Oops by Anonymous Coward · 2011-08-31 13:06 · Score: 2, Funny
  
  Get back to me when Windows separates execute permission from the filename extension.
  I sent you that e-mail 15 years ago. You should check your spam filter.
10. Re:Oops by Anonymous Coward · 2011-08-31 13:10 · Score: 0
  
  Has existed since Windows XP SP2.
  Files can have a Zone Identifier applied to them via NTFS alternate data streams.
  The Zone Identifier can restrict execution, causing a popup to confirm if the user really wants to execute it.
  Wouldn't be that hard to extend that so that it outright blocks execution without asking the user.
11. Re:Oops by drolli · 2011-08-31 13:10 · Score: 1
  
  But anybody would let MS know.
12. Re:Oops by bmo · 2011-08-31 13:15 · Score: 0
  
  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.
  --
  BMO
13. Re:Oops by LordLimecat · 2011-08-31 13:19 · Score: 1
  
  Hey buddy, 1995 called, they wanted their antiquated filesystems back. NTFS has supported seperate "execute" permissions since its inception, I believe. In fact, call me when ext3 seperates its "write" permission from its "change permissions / take ownership" permission.
14. Re:Oops by LordLimecat · 2011-08-31 13:22 · Score: 1
  
  Windows just sees the .exe and says "whoopee, we can execute it!"
  BZZZT Wrong, try again.
  NTFS has a specific "execute" permission; additionally, it uses alternate data streams to block execution of any executable code downloaded from the internet. Finally, GPOs can easily block code execution based on file signature, location, or publisher.
  Care to try again?
15. Re:Oops by shibashaba · 2011-08-31 13:25 · Score: 0
  
  It has happened to Microsoft in the past, they just tried to keep it quiet. This was back in the NT days. To their credit though, nobody at Microsoft has access to their entire codebase. On the other hand, this is also what makes it next to impossible for them to track down bugs and fix security issues. It also explains why it takes them so long to develop software.
  
  --
  ---------- Open Source is capitalism applied to IP.
16. Re:Oops by inode_buddha · 2011-08-31 13:35 · Score: 1
  
  Um. "Change permissions" and "Take ownership" are two entirely separate things.
  Also, have you ever heard of ext2/3's extended attributes? I have. And its possible to create files (or whatever) that not even root can do anything about. See man[1] chattr
  
  --
  C|N>K
17. Re:Oops by bmo · 2011-08-31 13:45 · Score: 0
  
  Again, it doesn't bloody matter because that doesn't fucking happen in reality.
  Windows has the same old bad habits it always had. Just because someone threw some code in there so an administrator can change the default behavior through policies doesn't mean the default behavior has changed.
  --
  BMO
18. Re:Oops by realityimpaired · 2011-08-31 13:47 · Score: 5, Insightful
  
  But more seriously, the fact of the matter is, most of the tripe spewed against Microsoft hasn't been true since the pre-XP era. This combines with idiots who don't comprehend what security actually is, and buy into the, "LINUX IS TOTALLY SECURE! LOLZ!" crap.
  Ok... I'll bite.... I will concede that Windows is a lot more secure than some folks will have you believe, but there is still one glaringly huge security flaw in Windows that would be ridiculously easy for Microsoft to fix: the accounts created during install time are all administrative accounts.
  To its credit, Windows will allow you to change those accounts to non-administrative, and it will give you the option of creating non-administrative accounts when you later go in to the user cp, but by default, it still makes everybody an administrator unless explicitly told not to.
  Now... the fundamentals of securing a Windows system are exactly the same as the fundamentals of securing a Linux system: don't run any unnecessary daemons, particularly daemons that listen to outside connections, and be careful what you allow to run on your computer. When possible, run anything that executes arbitrary code (like, say, Flash or Silverlight) sandboxed, or not at all. And above all, apply all security updates as soon as they're available. (well, assuming your source of security patches didn't get compromised....)
  It's not hard to lock down a Windows system, and all of the above has been doable since NT3.1 in 1993. But as long as its default setting is for users to have administrative access, and it doesn't require any kind of secondary authentication to run programs with elevated permissions (and don't get me started on the debacle that is UAC), then Windows is *not* as secure as most Linux distros. The average user is simply not going to go out of their way to lock down a system once they have gone through the initial setup, and with that in mind, Windows is defective by design. It's in the name of usability, which is certainly understandable, but don't paint it with rose coloured glasses: you can achieve the same level of security under Windows, but you have to do more to reach it.
19. Re:Oops by Dunbal · 2011-08-31 13:51 · Score: 1
  
  Windows just sees the .exe and says "whoopee, we can execute it!"
  Nahh come on be fair! Windows can execute a lot of stuff that isn't .exe too.
  
  --
  Seven puppies were harmed during the making of this post.
20. Re:Oops by oakgrove · 2011-08-31 14:05 · Score: 0
  
  I usually foe people that troll Linux or Google. Why did I foe you? I can't remember.
  
  --
  The soylentnews experiment has been a dismal failure.
21. Re:Oops by Anonymous Coward · 2011-08-31 14:10 · Score: 0
  
  Yea, damn the morality of some people. Bashing commercial monopolies and not as much amateur programmers that give you something freer than free. You're absolutely right it's morally wrong.. to some people. We should probably bash those nerds until they get low self esteem and social dysfunction. Take that you you altruist pigs!!
22. Re:Oops by oakgrove · 2011-08-31 14:13 · Score: 1
  
  I have never seen a windows box in my entire life that would not execute a file with .exe on the end of it. There very Well may be a way to change this behavior but for all intents and purposes, it may as well not exist. Maybe the next time my friend's machine gets hosed by the Trojan du jour I'll ask him if he "had the execute permissions which is assigned to users based on the perms on the file" set right. I mean, surely that is the default, right?
  
  --
  The soylentnews experiment has been a dismal failure.
23. Re:Oops by monkyyy · 2011-08-31 14:43 · Score: 0
  
  agreed and tell me when linux HAS to have a anti-virus installed, or else after a week it will fall apart
  
  --
  warning pointless sig
24. Re:Oops by GameboyRMH · 2011-08-31 15:01 · Score: 2
  
  By default, precisely dick. If you Windows guys get to pretend that NTFS execute permissions are commonly used, we Linux guys get to pretend that people commonly set /home and /tmp noexec and use SELinux. Deal?
  
  --
  "When information is power, privacy is freedom" - Jah-Wren Ryel
25. Re:Oops by monkyyy · 2011-08-31 15:14 · Score: 0
  
  i think u should only count how safe it is on default, because once its default programs written for it assume default so if u want to use it, ur stuck
  
  --
  warning pointless sig
26. Re:Oops by fluffy99 · 2011-08-31 15:29 · Score: 1
  
  Has existed since Windows XP SP2.
  Files can have a Zone Identifier applied to them via NTFS alternate data streams.
  The Zone Identifier can restrict execution, causing a popup to confirm if the user really wants to execute it.
  Wouldn't be that hard to extend that so that it outright blocks execution without asking the user.
  The zone identifier is only added in some instances, and it only give a general idea of where the file came from . It is a poor security mechanism at best. It requires having an NTFS file system. It requires the program running it to read and honor that information. There are ways of getting around this.
27. Re:Oops by fluffy99 · 2011-08-31 15:36 · Score: 2
  
  Hey buddy, 1995 called, they wanted their antiquated filesystems back. NTFS has supported seperate "execute" permissions since its inception, I believe. In fact, call me when ext3 seperates its "write" permission from its "change permissions / take ownership" permission.
  True, the NTFS filesystem supports finer grained permissions and some features that are simply not used or exposed in windows. Generally read/execute are grouped together and trying to set them differently often breaks things. The usual case for windows is that if you can read the file, you can execute it.
  Linux has a great mounting option called noexec, which is very handy to apply to the home partition. Ext3 has some extensions to provide finer grained permissions and features (eg chattr), but it's not implemented consistently across all the flavors and rarely used in my experience. Most systems I see are still dorking around with the simplistic user-group-world permissions.
28. Re:Oops by unencode200x · 2011-08-31 15:44 · Score: 1
  
  IDK how a kernel.org discussion turns into Windows bashing (oh, wait, that's what I love about /.). Anyway: this is what UAC is for. Even if the user executes a malicious program it has a much harder time changing system files and settings and compromising the whole box rather than just that user's profile. I can tell you from the 1,000's of WIndows boxes that we admin that it does make an enormous difference. Is it perfect? No, but it's a hell of a lot better than XP.
  
  UAC, courtesy of Wikipedia:
  
  Windows 7 and Windows Server 2008 R2 . It aims to improve the security of Microsoft Windows by limiting application software to standard user privileges until an administrator authorizes an increase or elevation. In this way, only applications trusted by the user may receive administrative privileges, and malware should be kept from compromising the operating system
  
  --
  
  Chance favors the prepared mind.
  Perfect is the enemy of good.
29. Re:Oops by LordLimecat · 2011-08-31 15:49 · Score: 2
  
  Again, it doesn't bloody matter because that doesn't fucking happen in reality.
  BZZZZT Wrong again.
  By default downloaded content-- I believe all of it-- is marked with an ADS flag, and requires approval before launching.
  Additionally, I DO have a number of clients where I have restricted where executable content can come from, and I did it in about 5 minutes without having to dick around with chmods, or scripting chmods, or figuring out how to prevent them from changing the acl while still having write access to the file.
  See, in EXT3, unless im mistaken, you cannot give a user write access or ownership to a file and still prevent them from executing the content-- they can just chmod a+x the file. Thats not the case in windows.
  So you should really just simmer down and stop displaying your ignorance.
30. Re:Oops by DeeEff · 2011-08-31 15:54 · Score: 1
  
  Let me go get my bludgeon. It's not part of the operating system, and I'm sorry, but you mustn't go un-punished.
31. Re:Oops by LordLimecat · 2011-08-31 16:01 · Score: 1
  
  I am aware that they are seperate, but for all intents and purposes having one is having the other. If you can take ownership of a file, you can change its permissions however you want, and if you can change permissions, you can grant yourself "take ownership". There may be a corner case where there is some difference, but I have never encountered it.
  
  Also, have you ever heard of ext2/3's extended attributes
  I had not; I have heard of the extended ACLs (which appear to be a kludge). Howeve, according to wikipedia, extended attributes are not a filesystem feature, but metadata.
  Extended file attributes is a file system feature that enables users to associate computer files with metadata not interpreted by the filesystem, whereas regular attributes have a purpose strictly defined by the filesystem
  The manpages for setattr seem to reinforce this, that they are for metadata, not permissions.
  And honestly, Ive never heard anyone argue that NTFS doesnt have finer-grained filesystem ACLs; its pretty obvious to anyone who has used each which has more control and flexibility (such as inheritance, selective inheritance, and all the rest).
32. Re:Oops by LordLimecat · 2011-08-31 16:05 · Score: 1
  
  Generally read/execute are grouped together and trying to set them differently often breaks things. The usual case for windows is that if you can read the file, you can execute it
  Its true you have to dig a little bit to get to the execute permission (under advanced permissions), but I have used them before for the purposes of making network shares non-infectable (virus may hide there, but it sure as heck wont run).
  Ive not run into an issue where read-but-not-execute has broken something, other than executable content that obviously refused to run.
  
  Linux has a great mounting option called noexec, which is very handy to apply to the home partition.
  I am aware of it, though as I do not administer any linux workstations I have never had the opportunity to use it. It certainly is a nice feature, and Im not trying to denigrate Linux or its mounting options or any of the rest.
  Im simply firing back at someone who foolishly declared that NTFS's permissions were less "good" than ext3's, which is a load of rubbish if ive ever heard any.
33. Re:Oops by LordLimecat · 2011-08-31 16:07 · Score: 1
  
  Above post should have read
  
  extended attributes are not a filesystem security feature, but metadata.
  It made sense in my head when I typed it, but obviously it didnt translate so well to a post.
34. Re:Oops by shutdown+-p+now · 2011-08-31 17:35 · Score: 2
  
  They aren't truly administrative (so long as you have UAC enabled) - they're more like normal user accounts that can sudo to root by providing their own password (rather than root's password) - not unlike Ubuntu. The default UAC setting skips the password, but that's because the whole point of inputting it is to prevent a malicious process from programmatically elevating on user's behalf - and UAC has a different way of handling that.
35. Re:Oops by Anonymous Coward · 2011-08-31 17:42 · Score: 0
  
  They tried that once, when they shipped loads of windows disks with preinstalled CIH infections, then later tried to ignore complaints (until they became too quantitative).
36. Re:Oops by fluffy99 · 2011-08-31 17:47 · Score: 1
  
  Oh definitely NTFS permissions kick butt. The fine granularity, inheritance, etc are pretty nice. No added security vulnerabilities like setuid/setguid. :}
37. Re:Oops by Sarten-X · 2011-08-31 17:53 · Score: 1
  
  alternate data streams to block execution of any executable code downloaded from the internet
  Now, I haven't done any Windows-specific development for a long time, but as I understand it, the responsibility for setting that flag falls on the application. Web browsers will of course follow the rules, but what about an IM client, or a web server, or any other of myriad things that get data from a network connection, and at some point dump that data into a file? Or, $deity forbid, any program ported from a non-Microsoft OS?
  The ADS flag is effectively a blacklist, and Unix permissions are a whitelist.
  
  --
  You do not have a moral or legal right to do absolutely anything you want.
38. Re:Oops by Yvanhoe · 2011-08-31 19:44 · Score: 1
  
  Saying that git is resistant to this kind of problem is not a PR move, it is true. If the same was to happen to MS, we would laugh, of course, but acknowledge that the cryptographic and distributed nature of the repository they use makes it safe. However I doubt Microsoft uses something like git for managing its source code.
  
  The only thing that can be done with an access to the repository is to append changes at the end of the tree. The repository of before 28th of august can not be stealthily compromised : it would change the hashes of versions and anyone with an uncompromised copy of the git history (ie, anyone using git for downloading the kernel source) will be able to see it.
  
  --
  The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
39. Re:Oops by styrotech · 2011-08-31 21:16 · Score: 1
  
  See, in EXT3, unless im mistaken, you cannot give a user write access or ownership to a file and still prevent them from executing the content-- they can just chmod a+x the file.
  Partially correct - just having write access isn't enough, you need to own the file to change its permissions.
  Also you need to be root to change ownership of files.
40. Re:Oops by Dan+Dankleton · 2011-08-31 21:16 · Score: 1
  
  I hate to point this out to you, but 80% of the kernel is written by programmers acting in a professional capacity (source: http://lwn.net/Articles/450891/) The admins of kernel.org deserve exactly as much bashing as the admins of microsoft.com would do if it had happened to them.
41. Re:Oops by Anonymous Coward · 2011-08-31 22:06 · Score: 0
  
  From Windows NT 3.1 (1993) you need executition permission to execute an .exe file.
42. Re:Oops by Anonymous Coward · 2011-08-31 22:11 · Score: 0
  
  It all has to do with how popular the OS is. For example, if you use an Android (Linux) device without antivirus, you're an idiot.
43. Re:Oops by Anonymous Coward · 2011-08-31 22:33 · Score: 0
  
  So I have to run AD locally to be able to disallow users to run arbitrary files? Brilliant! Let's f** home users, like we care.
44. Re:Oops by realityimpaired · 2011-08-31 22:34 · Score: 1
  
  The problem with UAC is that it pops up warnings for (seemingly) no reason, from the perspective of the regular user. They don't realize they're elevating their privileges, nor what that actually means, and so most users just click through UAC... until they get annoyed enough by it that they go googling for a way to turn it off.
  The very fact that it doesn't require a password to elevate is what leads to people thinking it's no big deal. I don't particularly like the way Ubuntu does it either, but at least Ubuntu requires your password, and doesn't keep popping up the request every 5 seconds while you're installing something... it remembers that you've authorized it for 15 minutes, and doesn't ask again. Security that people can just click through without thinking isn't security at all. :)
45. Re:Oops by Tomato42 · 2011-08-31 22:38 · Score: 1
  
  Are you talking about the same system that was susceptible to remote code execution through DNS answers?
  
  Not only the NT architecture (and most of MS software) has fundamentally broken design ("oh nice binary blob I've got here, wonder what it does... I know! I'll just execute it and see what it does!") , Microsoft creates shoddy code, nothing (as over 20 years of this company showed) can change that.
46. Re:Oops by Tomato42 · 2011-08-31 22:40 · Score: 1
  
  Use for its softer touch in Internet trolling, for the care, he deserves.
47. Re:Oops by Anonymous Coward · 2011-09-01 00:43 · Score: 0
  
  This is bad. Would the same thing happen to MS i dont think /.ers would skip the possibility to bash them.
  Well - we did point out some potential problems with MS releasing the source to China and Russia. But the thing about obscurity equals security is, um, obviously, too obscure for you to understand. You were probably asleep when MS held their foolish 2003 server security challenge - so we won't mention that source loss (or the RSA key).
  Anyway, if the source repo has been modified it will now magically affect my local mirror and I'll be doomed. Guess I'll whip out and buy a copy of Windoof 8 - it's got Israel's seal of approval - I don't got the source, but they have, so it's all good (sigh).
  P.S. thanks for proving evolution is vertical.
48. Re:Oops by betterunixthanunix · 2011-09-01 00:44 · Score: 1
  
  Im simply firing back at someone who foolishly declared that NTFS's permissions were less "good" than ext3's, which is a load of rubbish if ive ever heard any.
  It is not that they are "less good," it is that Windows (at least when I last saw someone using it) still assumes that if a file has ".exe" on the end of its name, it is an executable file, unless you configure different behavior. As far as I can tell, this is about convenience and the fact that users are so used to this behavior that they would not be willing to settle for something different. This is in contrast to most Unix-like OSes, where the filename is not relevant in determining whether or not the file can be executed, only the permissions are used.
  
  --
  Palm trees and 8
49. Re:Oops by benjymouse · 2011-09-01 00:56 · Score: 2
  
  So I have to run AD locally to be able to disallow users to run arbitrary files? Brilliant! Let's f** home users, like we care.
  No, that is what Local Security Policy is for. When in a domain, domain GPO takes preference if there are conflicts. But as a home user you can simply use the LSP.
  
  --
  Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
50. Re:Oops by Anonymous Coward · 2011-09-01 01:02 · Score: 0
  
  Yeah but sudo (and the associated graphical versions) sucks in its own way. All someone would have to do is write a program that silently runs as the user and just sits there waiting for the user to sudo for some purpose. Then BOOM that process can come alive and sudo to do whatever it needs to as root.
  This is due to the timeout period that sudo privileges stay active. During that period almost anything run as the user can elevate to root.
51. Re:Oops by V!NCENT · 2011-09-01 01:11 · Score: 1
  
  UAC isn't realy a security thing and wasn't designed like that. You can compare it with Android: it shuts down unresponsive apps without asking (no seperate GUI thread if you will), so that developpers would pay attention to responsiveness.
  Microsoft made UAC just like that, but then for security, to annoy users, just so that developpers would use safe code paths to make sure that these irritation messages aren't popping up in their apps.
  That said, if you use an app developped by a propper developper, these messages won't bug you, ever. There are API routines to call that will poke NT modules to do root routines in a way that's deemed secure by Microsoft.
  
  --
  Here be signatures
52. Re:Oops by Anonymous Coward · 2011-09-01 02:20 · Score: 0
  
  Maybe it was just the accent, and he was trying to say "batch"?
53. Re:Oops by Anonymous Coward · 2011-09-01 02:58 · Score: 0
  
  Aye, but for kernel.org we must tar and feather.
54. Re:Oops by LordLimecat · 2011-09-01 04:12 · Score: 1
  
  That is a feature of the window manager, and is present in Gnome and KDE as well-- although in a number of circumstances they WILL check to see with a little more detail what kind of file text-files are (are they scripts?).
  Rename all of your mp3s to .Desktop, and then see whether Gnome does the right thing on a doubleclick.
  What youre talking about is whether or not a handler has been registered with the base OS. In the case of windows, it certainly is possible to muck with the .exe registered handler so that exes no longer run (which is lots of lulz), or so that all exe's are passed off to another program which launches them (a feature a number of viruses exploit).
  The same thing is the case in Gnome (dunno about KDE), handlers are registered for various extensions, so that the system knows to launch .mp3 with Amarok and .png with GIMP.
55. Re:Oops by LordLimecat · 2011-09-01 04:14 · Score: 1
  
  Ah, thanks for the correction. That does make sense.
56. Re:Oops by VanessaE · 2011-09-01 04:24 · Score: 1
  
  [...] and if you can change permissions, you can grant yourself "take ownership".
  Incorrect. You have to own the file to change its permissions, but if you don't already own the file, you can't give yourself ownership of it or modify it without first becoming root.
  If root or some other user besides yourself owns a file and has it set for world-executable, the user can only read its contents or execute it, but not change its permissions or modify its contents. This is the case with most program files in Unix-like systems, while most system admin tools are only executable by root, period. Some stuff requires you to be part of a specific group to read or execute.
  The ability to read a file is explicitly separated from the ability to execute the file's contents, as is the ability to write/modify a file, regardless of who owns the file or who is allowed to work with it. The ability to change to a particular directory can be similarly restricted.
  
  [...] extended attributes are not a filesystem feature, but metadata.
  All filesystem flags, including ownership and permissions, and even the filename itself, are metadata - it's up to other parts of the OS kernel to decide what to do with that metadata, regardless of the structure of the underlying filesystem. A virtual machine or emulator can execute files in a guest disk image as long as those files are marked appropriately, regardless of the state of the disk image's flags in the host filesystem (provided the emulator doesn't care about such things, of course).
57. Re:Oops by Em+Adespoton · 2011-09-01 04:26 · Score: 1
  
  If this happens to OSS with a SCM like Git, it's not a big deal at all; any modifications will be instantly known to anyone in the development community who is interested in discovering them.
  If this happens to MS, first, we likely would never hear about it. Second, because of the centralized and closed development model, the result would be that MS would have to freeze the servers potentially affected in the breach, revert to working from backups, AND do a complete code review and audit (with the same employee hours).
58. Re:Oops by shutdown+-p+now · 2011-09-01 04:45 · Score: 1
  
  There are API routines to call that will poke NT modules to do root routines in a way that's deemed secure by Microsoft.
  Can you give some examples?
59. Re:Oops by betterunixthanunix · 2011-09-01 05:30 · Score: 1
  
  Except that the permissions on the file do matter. Processes are created using fork/exec, and you will not be able to call exec* on files that do not have execute permissions. This is not about your window manager or shell, it is about the permissions on files.
  
  --
  Palm trees and 8
60. Re:Oops by LordLimecat · 2011-09-01 10:04 · Score: 1
  And the SAME IS TRUE IN WINDOWS. If a file does not have execute permissions in NTFS, it will NOT RUN.
  I really dont get whats so hard to grasp here.
  
  Linux (ext3), Windows (NTFS), and Mac (HFS+) all have a concept of "execute permission", and have for at least the last 10 years (NTFS goes back the 90s im pretty sure).
  NONE of those systems will run content that has execute permission disabled.
  All of those systems rely on handlers to figure out what to do with particular extemsions (.Desktop, .exe, .app, .sh, .bat, whatever).
  Most of them will make some attempt to figure out what type of file it is for some of the extensions (linux will try to figure out if a non-extension file is executable text, for example).
  All of them allow you to have files with NO extension, and all of them allow you to launch such no-extension files if you pass them as arguments to another program.
  GPs points are utterly incorrect, every modern OS for the last 7 or 8 years (possibly not Mac for a few years) has restricted content downloaded from the web to not "just run", and they all have mechanisms for declaring how files should run and whether they should run.
  My point about it being "about the window manager" is that if you make a text file executable, Linux STILL wont be able to run it; but if you make a file executable and tack a .desktop onto the end of it it WILL try to execute it, same as windows-- but that has nothing to do with the underlying kernel, as it is a desktop environment feature and is unrelated to filesystem permissions.
61. Re:Oops by LordLimecat · 2011-09-01 10:16 · Score: 1
  
  Incorrect. You have to own the file to change its permissions, but if you don't already own the file, you can't give yourself ownership of it or modify it without first becoming root.
  I was specifically referring to windows, which has a specific "change permissions" permission. If you posess that, you can give yourself whatever permissions you want. If you own the file, you can also change permissions however you want.
  
  All filesystem flags, including ownership and permissions, and even the filename itself, are metadata - it's up to other parts of the OS kernel to decide what to do with that metadata, regardless of the structure of the underlying filesystem.
  I MAY be wrong here, but I dont think that is correct. Im fairly certain the ext3 filesystem itself interprets the permissions. Certainly in other FSes like NTFS, the permissions are completely separate from metadata like alternate data streams.
  
  A virtual machine or emulator can execute files in a guest disk image as long as those files are marked appropriately, regardless of the state of the disk image's flags in the host filesystem (provided the emulator doesn't care about such things, of course).
  Im not 100% clear on what youre saying; is there a guest OS involved? And why would the guest OS care about a host filesystem that it can neither see nor access?
62. Re:Oops by LordLimecat · 2011-09-01 10:29 · Score: 1
  
  I suppose that is the most reasonable criticism offered so far, and that does sound right-- though Im not sure ive seen many apps that dont abide by that policy. To be clear tho, the argument originally made was that Windows did not have a notion of "no execution allowed", which is patently false and has been since Windows NT.
  It is true that by default most things have execute in windows, but there are both pros and cons to it. If someone really wants to download executable content-- like, say, a log-me-in session launcher-- does the OS really want to take the stance (as Ubuntu 9.10 did when it started blocking .desktop file execution) that it cant trust its user, and unless the user is smart enough to know chmod-fu, they simply cant run their program?
  I mean if the user truly is determined to screw their system up, the OS really isnt going to be able to prevent them if they have the rights to do so, and if they really want to run arbitrary content from the internet, thats kind of their business. I guess it kind of depends on what use-case you have. In a better computer world, we would have prompts for running content that the computer truly thought to be risky, and we would have people who knew how to interpret those prompts and were not trained to ignore them.
63. Re:Oops by LordLimecat · 2011-09-01 10:30 · Score: 1
  
  gpedit.msc is your friend. Lots of things can be set there, think of it as a "security/lockdown" registry. Its pretty brain-dead-simple, too.
64. Re:Oops by betterunixthanunix · 2011-09-01 11:09 · Score: 1
  
  GPs points are utterly incorrect, every modern OS for the last 7 or 8 years (possibly not Mac for a few years) has restricted content downloaded from the web to not "just run", and they all have mechanisms for declaring how files should run and whether they should run.
  That's exactly what I saw happen in Windows the last time I watched someone use it: they downloaded a file from a website, and just ran it without any issue.
  
  --
  Palm trees and 8
65. Re:Oops by Kremmy · 2011-09-01 12:36 · Score: 1
  
  Downloaded content is only flagged when you downloaded that content with a program that snuggles nicely into the Windows security framework. Any program that does downloading can just ignore that such facilities exist and not use them. Mainstream browsers, sure - but what about all those auto-updating programs and the filesharing network of the moment? That's really laughable as a layer of security.
66. Re:Oops by DeeEff · 2011-09-01 15:25 · Score: 1
  
  I prefer my bludgeons to not be soft, but thanks anyways ;)
67. Re:Oops by LordLimecat · 2011-09-01 16:55 · Score: 1
  
  Then they were using XP pre-SP3 (and possibly pre sp2). Otherwise it will pop up at LEAST 1-2 dialog boxes confirming that yes, you really do want to do this. If you use Internet explorer, more than that.
  Certainly it does NOT happen on any version /servicepack of windows released in the last 6 years.
68. Re:Oops by V!NCENT · 2011-09-01 20:27 · Score: 1
  
  Of course :)
  If an application doesn't label itself as UAC aware (like explained in the article (link) below) it is virtualised/sandboxed, and thus resources are not accesible and prompt admin rights constantly. Or in another case you can make an elivated thread (root/admin rights thread) and let your app thread inherit the rights, but this also requires the UAC to ask the user "Do you wanna do this?".
  In order to bypass this, you first need to define that you actualy are making a UAC aware app, just so that UAC knows "Hey, this developper knows what he's doing, I'll leave him alone". You do this by making a small XLM manifest.
  Then, when UAC knows that you're (at least trying to) make a correct privilaged app, your app isn't virtualised and prompting, unles you decide to make some serious fscked up changes to the system, let's say the Program Files folder. By doing so you are ignoring NT6.x's design principles. (NT6.0 == Vista, NT6.1 == 7) and the UAC will still punish you for this. In order to make a change to a config file for example (Doom 3), you should ask an API "Store this to wherever it needs to be stored", by invoking a Common AppData path call (CSIDL, now depricated by KNOWNFOLDERID so check MSDN!).
  And so on... Link: http://www.codeproject.com/KB/vista-security/MakingAppsUACAware.aspx
  
  --
  Here be signatures
69. Re:Oops by V!NCENT · 2011-09-01 20:28 · Score: 1
  
  XML, oops...
  
  --
  Here be signatures
70. Re:Oops by V!NCENT · 2011-09-01 22:05 · Score: 1
  
  So the point of all of this is that you should sign the executable with an XML file to have just user rights, figure API routines for stuff that you can't do with user rights alone (like registry changes and IO). You'll find out that in most cases you still can't perform these root things with API calls, but that there are API's that tell you to do the same thing differently that doesn't invoke admin rights. Ofcourse the API itself is probably root executed, but performs IO for you that puts stuff in healthy places, give you registry alternatives, etc.
  
  --
  Here be signatures
71. Re:Oops by shutdown+-p+now · 2011-09-02 05:02 · Score: 1
  
  In order to bypass this, you first need to define that you actualy are making a UAC aware app, just so that UAC knows "Hey, this developper knows what he's doing, I'll leave him alone".
  You're confusing UAC and implicit elevation and virtualization for legacy apps. When you're providing an XML manifest, you're telling the legacy mechanism that you know about UAC and will handle it yourself. This does not disable any security checks or UAC prompts.. It just means that the OS won't intercept your attempts to access "Program Files", registry, and a few other predefined places (which legacy apps commonly access), and redirect it to a user-specific area where normal users have write access (for their own area).
  UAC prompts, by the way, don't appear out of the OS, with sole exception of prompt when starting something with "setup" or "install" in the name (to better support legacy installers). If your app - whether declared as UAC-aware in the manifest or not - does something that it has no permission to do, e.g. write to a file it doesn't have write permission for, the call will fail with the appropriate error code with no UAC prompts in sight. The only exception to this is the virtualization mechanism described above. Other than that, application itself is responsible for explicitly asking UAC to launch something elevated (which will show the UAC dialog to the user) when it knows it's going to need it.
  
  Then, when UAC knows that you're (at least trying to) make a correct privilaged app, your app isn't virtualised and prompting, unles you decide to make some serious fscked up changes to the system, let's say the Program Files folder. By doing so you are ignoring NT6.x's design principles. (NT6.0 == Vista, NT6.1 == 7) and the UAC will still punish you for this.
  UAC (or rather the OS) will still not let you access folders that you don't have permissions to access as a non-admin. You give one example yourself - modifying "Program Files". This is blocked not because it's some kind of magical operation, but because normal users don't have write access there by default.
  
  In order to make a change to a config file for example (Doom 3), you should ask an API "Store this to wherever it needs to be stored", by invoking a Common AppData path call
  
  This is plain wrong. You don't need to ask the Shell for CommonAppData path to access it. Oh sure, it's what you should do in a well-written app, since system drive can vary from install to install etc, but there's nothing permission-related here. If you want, you can just access it directly as C:\ProgramData. The reason why you can modify some file under ProgramData is simply because it had write permissions for world. This is not the default for that folder, either - applications are required to explicitly set that bit in their installer on those subfolders and/or files they believe it is necessary. If Doom 3 does it, it's an explicit design decision (and likely a defect) in Doom 3.
  So, basically, you still haven't demonstrated any APIs that let an app circumvent OS security - i.e. modify any OS object, such as file or registry key that it doesn't have write permissions to.
72. Re:Oops by shutdown+-p+now · 2011-09-02 05:03 · Score: 1
  
  You'll find out that in most cases you still can't perform these root things with API calls, but that there are API's that tell you to do the same thing differently that doesn't invoke admin rights. Ofcourse the API itself is probably root executed, but performs IO for you that puts stuff in healthy places, give you registry alternatives, etc.
  Okay, I've missed that reply until after replying to your first.
  So then, I repeat the question: what are those APIs? Specifically: what are the APIs that "let you do the same thing differently" that would normally require admin rights, but does not with those APIs (note that virtualization, obviously, is not "the same thing", since it actually writes to a different area on disk and in the registry).
73. Re:Oops by V!NCENT · 2011-09-02 06:56 · Score: 1
  
  Well aside from code injecting cmd.exe (or faking to be the official cmd.exe) with a non-elevated process? :P (cmd.exe can run in admin mode while not requiring UAC prompt)
  No what I meant was that all API's essentially get handled by NT in kernel mode (syscalls) that do root stuff for you without requiring root acces. There are no API's that simply say "Oh you want to make malware not require UAC? Use this ->" (that I'm aware of).
  So there are API's enough for you to write a user privilaged app, but Microsoft probably didn't meant to require a third party registry cleaner, so touching this kind of niche stuff makes the user get poked by UAC no matter what you do (like Microsoft want you to be able to).
  (I make mistakes sometimes; I'm just a human being :P)
  
  --
  Here be signatures
74. Re:Oops by shutdown+-p+now · 2011-09-02 10:15 · Score: 1
  
  Well aside from code injecting cmd.exe (or faking to be the official cmd.exe) with a non-elevated process? :P (cmd.exe can run in admin mode while not requiring UAC prompt)
  No, cmd.exe cannot do that. This is trivially demonstrated by running it without explicitly elevating (via right-click "Run as administrator") and doing anything that requires elevation. If you believe this to be wrong, please provide a specific example of cmd.exe doing something that requires elevation without going through an elevation UAC prompt.
  
  No what I meant was that all API's essentially get handled by NT in kernel mode (syscalls) that do root stuff for you without requiring root acces.
  This would be an internal implementation detail of those APIs. Sure, almost any API call you do will eventually end up being one or more syscalls, and as those run in the kernel, they "have root" (or rather, "root" is meaningless for them). This is just as true in Linux or OS X. But, so long as higher levels do proper validation of user permissions, this is not an issue, since kernel-level APIs cannot be invoked directly from user space. If you have any specific example to the contrary, please provide it.
  
  So there are API's enough for you to write a user privilaged app, but Microsoft probably didn't meant to require a third party registry cleaner, so touching this kind of niche stuff makes the user get poked by UAC no matter what you do (like Microsoft want you to be able to).
  To reiterate: with the sole exception of auto-elevating "setup.exe" and the likes, there are no APIs (other than UAC API itself) that you can touch in your code and thereby cause the OS to automatically insert a UAC elevation prompt. If you want to pop up that dialog, you need to explicitly tell Windows to do so. If you try to do something that requires elevation to succeed without explicitly elevating via UAC, you will simply get an error code returned indicating "access denied" or something along these lines.
Linux isn't secure by Anonymous Coward · 2011-08-31 12:06 · Score: 0, Funny

Look, its been 20 years, linux has been a total failure, modding me down just means you agree.
1. Re:Linux isn't secure by Opportunist · 2011-08-31 12:14 · Score: 1, Troll
  
  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.
2. Re:Linux isn't secure by Anonymous Coward · 2011-08-31 12:21 · Score: 0
  
  Linux is awesome, modding me up just means you disagree.
3. Re:Linux isn't secure by Anonymous Coward · 2011-08-31 12:23 · Score: 0
  
  Your post is more of a troll than GPs. You must be sucking lots of brown cocks!
4. Re:Linux isn't secure by Anonymous Coward · 2011-08-31 12:26 · Score: 0
  
  Look, its been 20 years, linux has been a total failure, modding me down just means you agree.
  Anonymous Coward++
5. Re:Linux isn't secure by networkBoy · 2011-08-31 13:02 · Score: 2
  
  > [ 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
he's talking about tarballs by bill_mcgonigle · 2011-08-31 12:24 · Score: 4, Insightful

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)
1. Re:he's talking about tarballs by the_enigma_1983 · 2011-08-31 12:37 · Score: 1
  
  No, that doesn't get dynamically pulled from git every time you request it.
  But it'd also take an admin about 15-30 seconds to type out the command to regenerate the archives from the git repos. Actually, I think 30s is probably extreme, I suspect they would have scripted the process. Wouldn't be surprised if it's just something like "makearchives.sh " and the archive is recreated from the git repo.
2. Re:he's talking about tarballs by slimjim8094 · 2011-08-31 12:48 · Score: 0
  
  Scripted? Not necessary.
  
  git archive -o ../kernel-nightly-`date +%m-%d-%Y`.tar.gz master
  should do it.
  
  --
  I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
3. Re:he's talking about tarballs by Eskarel · 2011-08-31 12:52 · Score: 1
  
  The hash isn't automagic, it's produced and provided by the distributor of the code or binary. A hash won't protect you if the source of the hash has been hacked. Sure I can download a kernel tar from a mirror and then check kernel.org for the hash, but where do you go to validate that kernel.org is real. A clever hacker in 17 days, could very easily replace the kernel tar balls and their associated hashes and the only way anyone would know would be if someone happened to have a reference of what that key had been or an exact copy of the files used to generate it in the first place which was known good. Release versions would be very easy to hack.
  You're also not even guaranteed that there's no malicious code in the repository. Do you reckon that everyone's commits are reviewed with the same diligence that some random patch is. If you were clever enough and used the stolen passwords to impersonate the right person you could quite easily get something into the trunk. I mean if you've known and worked with a guy for years are you really going to check for a really well hidden back door?
4. Re:he's talking about tarballs by Anonymous Coward · 2011-08-31 13:06 · Score: 4, Insightful
  
  %Y-%m-%d please! Americans...
5. Re:he's talking about tarballs by shibashaba · 2011-08-31 13:15 · Score: 1
  
  Yeah, like I need to be reminded what year it is on a daily basis.
  
  --
  ---------- Open Source is capitalism applied to IP.
6. Re:he's talking about tarballs by shibashaba · 2011-08-31 13:18 · Score: 1
  
  A really well hidden back door would either consist of introducing a security breach, or exposing api's not normally found in that section of the code. Either way, it'll be found especially now that it is under scrutiny.
  There are so many copies of the kernel sitting on thousands of different unrelated servers around the world, not to mention peoples personal backups. Anything changed can and will be found easily.
  
  --
  ---------- Open Source is capitalism applied to IP.
7. Re:he's talking about tarballs by Anonymous Coward · 2011-08-31 13:20 · Score: 1
  
  And you put that in a script called "makearchives.sh" because you don't want to remember arcane commands for no reason.
8. Re:he's talking about tarballs by nneonneo · 2011-08-31 13:39 · Score: 3
  
  Need I point out that %Y-%m-%d sorts properly, whereas %m-%d-%Y does not? When's the last time you needed releases sorted by month but not year?
9. Re:he's talking about tarballs by Dunbal · 2011-08-31 13:47 · Score: 1
  
  Users generally use code, they don't write it. They matter because they are who the code is written for, however they don't matter when it comes to modifying the code. /feed
  
  --
  Seven puppies were harmed during the making of this post.
10. Re:he's talking about tarballs by Anonymous Coward · 2011-08-31 14:10 · Score: 0
  
  Just put it in your crontab to run nightly. You don't need to remember it, you can just `crontab -l` and see it
11. Re:he's talking about tarballs by Anonymous Coward · 2011-08-31 15:45 · Score: 0
  
  For fuck's sake, it's obvious that everyone is talking about the Git repos, and not necessarily published tarballs. Are you just trolling or what?
12. Re:he's talking about tarballs by shibashaba · 2011-08-31 16:22 · Score: 1
  
  Ok so that makes sense. I'm used to seeing releases sorted by version numbers though, I don't go for snapshots very often.
  
  --
  ---------- Open Source is capitalism applied to IP.
13. Re:he's talking about tarballs by shibashaba · 2011-08-31 16:31 · Score: 1
  
  Actually I think I might take back what I said. I like version numbers, and don't see why you would need to have several years worth of snapshots in the same directory. That sounds like a ridiculous waste of space that nobody will ever need to go through(assuming you manage to ever finish something). Past few months worth of snapshots can be worth keeping around.
  So there! Americans Rule again :)
  
  --
  ---------- Open Source is capitalism applied to IP.
14. Re:he's talking about tarballs by Eskarel · 2011-08-31 17:08 · Score: 1
  
  Now that they know, yes, it will probably be found. That doesn't mean that 1) tarballs weren't infected and 2) that changes weren't made to the code and approved because someone was impersonating a trusted developer. It will be resolved, but it could also easily have created a problem which may take months to fully work itself out.
15. Re:he's talking about tarballs by Anonymous Coward · 2011-08-31 21:41 · Score: 2, Insightful
  
  Apart from the argument that YMD sorts it is also unambiguous. The first 12 days of each month can also be interpreted as month numbers. There are DMY countries and MDY countries. Can you always be sure which convention is being used? There are no YDM countries, so YMD is unambiguous.
16. Re:he's talking about tarballs by Anonymous Coward · 2011-08-31 22:45 · Score: 0
  
  +1 internets.
17. Re:he's talking about tarballs by Anonymous Coward · 2011-09-01 00:25 · Score: 0
  
  Have you already forgotten that the server was *compromised*?! The crontab is *on the server that has been compromised* so it is *completely useless as a way to protect the server*. The same for md5sum, sha1sum, openssl binary, or even fuckin diff!! It all could be replaced by versions that would show expected output even for compromised input. Didn't you hear about rootkits? WTF is wrong with you people!
18. Re:he's talking about tarballs by Anonymous Coward · 2011-09-01 00:46 · Score: 0
  
  Aren't there MD5/SHA checksums that users should be checking against? If these were compromised and updated with the latest checksum for the modified tarball, then users are screwed, but if they weren't touched, the archives would have been flagged as corrupt by any sensible users.
19. Re:he's talking about tarballs by mortonda · 2011-09-01 00:54 · Score: 1
  
  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?
  No, but git contains the complete history in a local copy, so all that needs to be done is for Linus (or anyone else with a local copy ) to write a script that unpacks every tagged version and compares it with what's on the server. Because git is decentralized, everyone who works on the kernel has a complete copy of every version, so it's very easy to verify the other forms of distribution.
20. Re:he's talking about tarballs by Xtifr · 2011-09-01 09:09 · Score: 1
  
  In addition to all that, YMD is an international standard, which means it going to be accepted and recognized by any software designed for an international market.
21. Re:he's talking about tarballs by nneonneo · 2011-09-02 17:09 · Score: 1
  
  ...two months is all you need to cross from one year to the next, which, under the %m-%d-%Y scheme, would still fail to sort in the expected chronological order.
22. Re:he's talking about tarballs by DrBoumBoum · 2011-09-04 00:52 · Score: 1
  
  You can even get very interesting bugs through that, like in VBA automatic date conversion that try MDY first then DMY. So you get bugs in your code that only trigger during the first 12 days of each months. How fun! :-)
They should have remembered.. by halfaperson · 2011-08-31 12:29 · Score: 1

..to patch their kernels.

--
Jesus had a UNIX beard.
1. Re:They should have remembered.. by Anonymous Coward · 2011-08-31 12:52 · Score: 1
  
  It's ok, someone has done it for them now.
Someone by Anonymous Coward · 2011-08-31 12:40 · Score: 0

was interested in Linus' backups.
Huh? by atomicbutterfly · 2011-08-31 12:44 · Score: 1, Funny

But I've always been told by the fanboys that Linux is inherently secure, right? So that's not possible.

A trojan startup file was added to the system start up scripts
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. :)
1. Re:Huh? by shibashaba · 2011-08-31 13:22 · Score: 1
  
  I suggest you look up the definitions of these words before you start using them.
  
  --
  ---------- Open Source is capitalism applied to IP.
2. Re:Huh? by LordLimecat · 2011-08-31 13:24 · Score: 1
  
  But I've always been told by the fanboys that Linux is inherently secure, right? So that's not possible.
  Hurr durr, patching the source code of software with malicious code means the software has always been inherently insecure....
3. Re:Huh? by Dunbal · 2011-08-31 13:54 · Score: 1
  
  Now just imagine what someone somewhere is doing to all the Macs and iOS stuff.
  
  --
  Seven puppies were harmed during the making of this post.
4. Re:Huh? by Anonymous Coward · 2011-08-31 14:32 · Score: 0
  
  Never say anything bad about linux with your real account, do you realize what you've done? How's your karma? Don't worry I'll help you through this, I've already been there before. I won't let go of your hand, the ambulance is already on the way, stay with me! Stay with ME!
5. Re:Huh? by jefurii · 2011-08-31 16:27 · Score: 1
  
  But I've always been told by the fanboys that Linux is inherently secure, right? So that's not possible.
  
  A trojan startup file was added to the system start up scripts
  But Linux has no viruses/trojans/malware, right?
  To clarify, the kernel.org announcement says that trojan startup file was added to the server's startup scripts.
6. Re:Huh? by Anonymous Coward · 2011-08-31 17:29 · Score: 0
  
  Ooh! A spine! Must tear out...
  Captcha: colons
  I prefer spines
7. Re:Huh? by Anonymous Coward · 2011-08-31 18:39 · Score: 0
  
  "We believe they may have gained this access via a compromised user credential".
8. Re:Huh? by Anonymous Coward · 2011-08-31 18:51 · Score: 0
  
  Light jabbing you say? More like absurd comedy. If somebody claims you that any platform is immune to trojan horses, you instantly know he's lying. A trojan horse is not a technical attack vector but social. It is completely useless unless the user runs it or gives it explicit permission to run. There's no protection against user error in a free environment.
  And there are no viruses as you say.
  I think this kernel.org incident is slightly embarrassing but hardly anything more.
9. Re:Huh? by qxcv · 2011-08-31 20:35 · Score: 1
  
  Which would *theoretically* make this no worse for Linux than the Sony incident (the system was compromised, but the OS itself wasn't to blame directly).
  
  Still, kernel.org maintainers should know better ;)
  
  --
  "The most dangerous enemy of a better solution is an existing codebase that is just good enough." -- Eric S. Raymond
10. Re:Huh? by Anonymous Coward · 2011-09-01 01:47 · Score: 0
  
  Nah. That's never what fanbois said. Fanbois said that Un*x is inherently much, much more secure than Windows. Which is why 2/3rd of the Interweb runs on Un*x and which is why that 2/3rd is more secure than Windows.
  However, being much much more secure than Windows sadly doesn't mean much. You can be much much more secure than Windows and still be full of 0-day holes, which is the real sad part :(
  Also teh funnies (because you like being teh funnies of course, just like me) is that should such a break have occured (maybe it already did) at MS, then they'd have no way whatsoever to verify the integrity of their sources, because their VCS suck fat balls :(
  Actually, it's already been pointed out that there *may* be several NSA/illuminati/whatever-you-smoke backdoors in Windows. Not that Windows backdoors are really that mandatory seen the number of 0-days plaguing the system ; )
  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. :)
11. Re:Huh? by Anonymous Coward · 2011-09-01 02:02 · Score: 0
  
  But Linux has no viruses/trojans/malware, right?
  Viruses? No real ones.
  Trojans? Any kid can make those, convincing anyone to install them is a different case, though. If you can convince Canonical to put it into Ubuntu apt-get, big problems.
  Malware? Let me name two: Adobe Reader and Flash.
  Worms? Were basically inventet on Unix.
12. Re:Huh? by Em+Adespoton · 2011-09-01 04:44 · Score: 1
  
  Depends on what you mean by "secure" -- this sort of thing depends on insecurity through obscurity -- and when dealing with the OSS kernel SCM, there is no obscurity.
  Therefore, Linux is inherently secure against this sort of thing, as it doesn't matter at all if someone breaks into the server. There is a disruption, but the only person affected would be someone who had never used the server before.
  Now if someone broke into a developer's account, or spent years building up street cred and gained commit privs and then committed something that looked legit and passed code review, but contained malicious code, Linux isn't secure against THAT -- but neither is any other OS. For example, there was a Delphi compiler virus that went undetected for over a year, and eventually ended up on a LOT of Delphi IDEs (and in all the software built by them) before it was eventually caught.
13. Re:Huh? by HiThere · 2011-09-01 08:46 · Score: 1
  
  Since it was "his work laptop" I don't even know that it was running Linux.
  That said, no system is proof against trojans. And no system that runs flash in its browser is proof against viruses. You can't really call a flash virus a Linux virus, anymore than you could call a java virus one.
  That said, Linux hasn't been proof against that kind of infection since tar files were able to unpack things already set to be executable. Highly resistant, yes, but not immune. What it SHOULD be immune to is privilege escalation attacks. Even there it occasionally fails. (And on most systems saying "You can only compromise your own account" is the same as saying you can compromise the machine...though not quite, since you only need backups of the stuff that is mounted with write privileges. But in such cases it's generally better to be safe and re-install everything.)
  Have you noticed how many reports are out about attacks against Androids? That's essentially Linux. But almost all of the attacks only affect user-space. But that's about all anyone cares about, too. And generally you *can't* write native mode applications for those phones, so the attacks all have to come in through a mediated attack surface. Generally either flash or Java.
  Sorry I can't take this quite as lightly as you do, but too many believe what you (spoofily) pretend to believe. So I feel it deserves a serious answer, even though *you* don't need one.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
14. Re:Huh? by yuhong · 2011-09-01 17:42 · Score: 1
  
  Indeed, the most common attacks against Unix machines nowadays I think is targeted attacks, which often uses either social engineering or privilege escalation attacks to gain root.
You don't git it by Anonymous Coward · 2011-08-31 13:00 · Score: 3, Informative

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.
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.
1. Re:You don't git it by Spykk · 2011-09-01 03:20 · Score: 1
  
  Unless of course your using a kernel.org mirror to download your distribution's packages ala http://mirrors.kernel.org/archlinux/core/os/x86_64/
2. Re:You don't git it by msaavedra · 2011-09-01 05:34 · Score: 1
  
  Most distributions (ie the archlinux one you linked to) digitally sign their packages with private keys, so the people who compromised kernel.org wouldn't be able to tamper with them without causing verification failures by the package management system.
  One huge problem could be downloadable ISOs for live images or installer DVDs. Since you are booting up your system with them, there would be no reliable automatic signature verification.
  I downloaded a Centos-6 ISO from the kernel.org mirror just the other day, and broke out in a cold sweat when I saw this story. However, Centos and just about everyone else publishes checksums of their ISOs. I compared my download against the checksum, and, to my relief, it matched.
  It would be wise if everyone compared checksums immediately after downloading something like this. Alternately, you can use a protocol like BitTorrent for the download, which compares checksums automatically.
  
  --
  "Any fool can make a rule, and any fool will mind it."
  --Henry David Thoreau
oh hell by Anonymous Coward · 2011-08-31 13:05 · Score: 0

I'm running an Arch installation on my laptop that uses ftp.kernel.org as the Pacman mirror. I'd really like to know exactly what was compromised. I hope they figure it out soon.
Tell me... by indros · 2011-08-31 13:13 · Score: 1

Who's going to compromise the Linux kernel servers, and leave the linux kernel alone?
1. Re:Tell me... by Chuck+Chunder · 2011-08-31 13:58 · Score: 1
  
  I suppose that depends on whether compromising the Kernel source on kernel.org without detection is seen as possible. If it isn't (and kernel.org seem quite confident that git would protect against it) then the 448 users of Kernel.org may be a better target.
  
  Considering they presumably include people from the major distros using the kernel.org compromise as a starting point to gain access into other organisations might be more valuable than a risky direct attempt on the kernel itself.
  
  --
  Boffoonery - downloadable Comedy Benefit for Bletchley Park
2. Re:Tell me... by inode_buddha · 2011-08-31 14:31 · Score: 1
  
  It was actually the other way around, believe it or not. The compromised client machine is owned by an Intel employee, who is a big-name contributor to the kernel and bootloaers. His machine was trojanned which in turn led to the compromise at kernel.org.
  My larger point being that there are many very large companies involved in the kernel, and its not just distros.
  
  --
  C|N>K
3. Re:Tell me... by Anonymous Coward · 2011-08-31 14:47 · Score: 0
  
  Who's going to compromise the Linux kernel servers, and leave the linux kernel alone?
  Microsoft?
4. Re: Tell me... by Anonymous Coward · 2011-08-31 16:23 · Score: 0
  
  your mom
face it by gearloos · 2011-08-31 13:39 · Score: 1

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"
1. Re:face it by GameboyRMH · 2011-08-31 15:14 · Score: 1
  
  The bad guys have definitely won when it comes to credit cards, those rely entirely on security by obscurity. Other stuff, not so much.
  And if credit card losses were the bank's/data-spilling organization's responsibility things would be VERY different...
  
  --
  "When information is power, privacy is freedom" - Jah-Wren Ryel
2. Re:face it by Anonymous Coward · 2011-09-01 04:46 · Score: 0
  
  If Disney is violating the court order, complain to the court and get PAID.
YMD sorts by perpenso · 2011-08-31 13:48 · Score: 5, Insightful

Yeah, like I need to be reminded what year it is on a daily basis.
Actually YMD is useful because it sorts.
Re:This could happen to anybody by Dunbal · 2011-08-31 13:57 · Score: 1

I wrote this post in flash but you can't see it.

--
Seven puppies were harmed during the making of this post.
Laggard Ubuntu releases need not worry! by Anonymous Coward · 2011-08-31 14:03 · Score: 0

Your system's kernel won't be rooted for at least six months.
How it happened by 93+Escort+Wagon · 2011-08-31 14:03 · Score: 1, Troll

The kernel.org sources live on OS X Lion boxes - authentication is handled through LDAP.

--
#DeleteChrome
They should have been running OpenBSD. by Anonymous Coward · 2011-08-31 14:04 · Score: 0

If you're running a serious server, like the kernel.org servers, your only real option is to use OpenBSD. It may not be perfectly secure, but it's about as close as you're going to realistically get.
Unnecessary second link? by psYchotic87 · 2011-08-31 14:46 · Score: 1

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?
the nature of open source by crutchy · 2011-08-31 15:00 · Score: 1, Insightful

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?
1. Re:the nature of open source by spauldo · 2011-08-31 16:11 · Score: 1
  
  None of the major distros use vanilla kernel.org kernels, so most Linux users won't be affected either way. Their update programs get kernel updates from their distro's servers, not from kernel.org. The distros are usually a few versions behind, so most won't be affected by this at all.
  You can bet there's people at Debian, Ubuntu, Red Hat, etc. who are taking this very seriously. They aren't going to take any chances.
  The only users out there who are potentially in danger are the ones that use kernel.org source directly, the ones who run bleeding edge distros (like Debian Sid), or the ones that use a distro that automatically downloads and compiles kernel.org code. These guys should already know the risk they're taking.
  Anyway, as far as your second question - what OS could act as a drop-in replacement for the Linux kernel - check out kFreeBSD. Sure, it's not exactly the same - FreeBSD has always had different priorities than Linux, and it's reflected in what the kernels support - but it's close enough for the important stuff.
  
  --
  Those who can't do, teach. Those who can't teach either, do tech support.
Just so nobody is confused, this post ^^^ is wrong by Anonymous Coward · 2011-08-31 15:15 · Score: 1

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.
Obviously by Anonymous Coward · 2011-08-31 15:25 · Score: 0

it was Kevin Mitnick...
TCPDUMP by Anonymous Coward · 2011-08-31 15:26 · Score: 0

There's nothing like a FreeBSD router with TCPDUMP.
diff by savuporo · 2011-08-31 15:34 · Score: 1

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!
Re:Just so nobody is confused, this post ^^^ is wr by LordLimecat · 2011-08-31 15:51 · Score: 1

It IS present in XP, and has been probably since SP2. As you said, bmo doesnt have a clue.
Highly unlikely the code was compromised by seifried · 2011-08-31 16:45 · Score: 2

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).
1. Re:Highly unlikely the code was compromised by Anonymous Coward · 2011-08-31 19:41 · Score: 0
  
  So unless they manage to compromise the Kernel signing key any changes would be immediately noticeable (assuming people check the signatures, which they do).
  And who says they didn't compromise it too?
  Both tarballs/patches/etc and *.sign files are 'vulnerable'.
  I think the right thing to make sure the tarball/patch/whatever is ok, is to 'diff' it against a 'git diff' from an upstream repo(Linus' for mainline, Greg's for -stable/-longterm etc), since it's highly unlikely that the *git repos* were compromised.
2. Re:Highly unlikely the code was compromised by Octoploid · 2011-08-31 22:27 · Score: 3, Interesting
  
  The private signing key + passphrase are normally present on hera. So all tarball signatures could be compromised.
3. Re:Highly unlikely the code was compromised by Anonymous Coward · 2011-09-01 06:46 · Score: 0
  
  Is it possible to modify a tarball and still keep the SHA1 checksums unaltered? Sometimes it is best to have a public (SHA1) checksum, but privately maintain a separate checksum (SHA-2 with different hash lengths, GHASH-32, ...). Hopefully somebody is paying attention.
antivirus by Anonymous Coward · 2011-08-31 17:01 · Score: 0

"rootkit known as Phalanx, variant of which has attacked sensitive Linux systems before."
As from now, its better to think twice before declaring that Linux installations doesn't need anti-virus/malware/trojan because thre's only a few dozen known, of the like.
1. Re:antivirus by Alex+Belits · 2011-08-31 19:24 · Score: 1
  
  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.
It's about the commit by dutchwhizzman · 2011-08-31 17:53 · Score: 2

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?
1. Re:It's about the commit by You're+All+Wrong · 2011-09-01 00:24 · Score: 1
  
  Almost none have the commit rights to the important git tree.
  Even if they commit it to their own tree, it still needs to be pulled into one of the maintainers' trees, and approved by them too.
  
  So in order for there to be any propagation of any changes we need all these things:
  - you develop from the tarball
  - you don't notice the changes that aren't yours
  - you have a repository that others pull from
  - those others trust you and don't examine your changes
  - those others are trusred tree maintainers
  
  So basically it's a non-event. Even those who use quilt always have all the patches fully visable at all times, so you can't hide a change as only changes are visible.
  
  --
  Your head of state is a corrupt weasel, I hope you're happy.
won't work for set top boxes by dutchwhizzman · 2011-08-31 18:00 · Score: 1

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 by AliasMarlowe · 2011-08-31 18:22 · Score: 1

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. Re:Karma by Anonymous Coward · 2011-09-01 03:14 · Score: 0
  
  because you "Americans" invented the English spelling you arsehole?
2. Re:Karma by AliasMarlowe · 2011-09-01 08:25 · Score: 1
  
  because you "Americans" invented the English spelling you arsehole?
  Who are you calling "American", you arsehole?
  Hint: I'm not American, British, Canadian, Australian, etc., but am quite fluent in both British and American English. The word "superior" is spelled the same in all dialects of English that I'm aware of.
  
  --
  Those who can make you believe absurdities can make you commit atrocities. - Voltaire
key sentence by Anonymous Coward · 2011-08-31 19:36 · Score: 0

"Files belonging to ssh (openssh, openssh-server and openssh-clients) were modified and running live. "
This reminded me of http://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-To-Have-Backdoored-OpenBSDs-IPSEC-Stack
1. Re:key sentence by Alex+Belits · 2011-08-31 19:41 · Score: 1
  
  That's because you are fucking stupid.
  
  --
  Contrary to the popular belief, there indeed is no God.
All kernelhackers need to change their pass, now! by Anonymous Coward · 2011-08-31 19:55 · Score: 0

passwd [enter]
Changing password for user kernelhack0r.
(current) UNIX password: 2.6.39.4 [enter]
New password: 3.0 [enter]
"wheresyourringsnow" ? by Per+Wigren · 2011-08-31 19:58 · Score: 1

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.
backdoor in kernel? by Anonymous Coward · 2011-08-31 21:10 · Score: 0

how do i know, does my linux desktop have backdoor?
should i limit outgoing connection on my linux desktop?
Re:Just so nobody is confused, this post ^^^ is wr by Tomato42 · 2011-08-31 22:27 · Score: 0

It's quite different to "have to go through hoops to make the file executable" and "have to click one big button". First is an action requiring conscious thought the other is automatic for 99% of people. That's why the latter doesn't work.

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.
Re:Just so nobody is confused, this post ^^^ is wr by benjymouse · 2011-09-01 00:03 · Score: 2

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*
OpenBSD by daoshi · 2011-09-01 00:20 · Score: 1

Should have used OpenBSD for the server!
Dont panic by traldar · 2011-09-01 02:09 · Score: 1

Kernel panic!
RMS did it... by Anonymous Coward · 2011-09-01 02:40 · Score: 0

... trying to resurrect the hurd project...
Have I just not been paying attention? by Anonymous Coward · 2011-09-01 03:19 · Score: 0

Or has there been an increase in data breaches over these past couple of years? I haven't heard too much in the past, partially because I wasn't lookin for those news stories, but I haven't heard too many on the realm of data breaches even in the news until recently.
What, me worry? by Anonymous Coward · 2011-09-01 04:39 · Score: 0

What possible problem could result from backdoors in kernel code?
Stupid Linus ... by sourcerror · 2011-09-01 05:01 · Score: 1

Stupid Linus forgot to install Avast.
Please educate yourself on Windows by benjymouse · 2011-09-01 08:32 · Score: 2

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*
forgot proper thing for sloccount data publishing by rubycodez · 2011-09-01 08:52 · Score: 2

from the output:

Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."
Re:Just so nobody is confused, this post ^^^ is wr by LordLimecat · 2011-09-01 10:23 · Score: 1

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).
Re:Just so nobody is confused, this post ^^^ is wr by Kremmy · 2011-09-01 10:32 · Score: 1

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.
http://woken.webs.com/ by Anonymous Coward · 2011-09-02 02:08 · Score: 0

http://woken.webs.com/
Another explanation of why it's safe by autocracy · 2011-09-03 07:57 · Score: 1

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