Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Kernel.org Compromised

samzenpus posted more than 2 years ago | from the everyone-is-doing-it dept.

Security 312

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

cancel ×

312 comments

Whoops! (0)

Anonymous Coward | more than 2 years ago | (#37270504)

Scary for us using rolling-release distros.

Re:Whoops! (3, Informative)

X0563511 (793323) | more than 2 years ago | (#37270588)

Not really. Try reading the summary all the way through.

Re:Whoops! (0, Offtopic)

Anonymous Coward | more than 2 years ago | (#37270716)

Reeding are hard.

Re:Whoops! (-1, Offtopic)

Anonymous Coward | more than 2 years ago | (#37271166)

It is indeed distressing to hear, on an almost monthly basis of an occurrence of high school violence, usually involving a young male who has been shunned by his peers, using a firearm to take revenge on (possibly imagined ) tormentors or faculty. My proposed trial solution to this horrible problem is both extremely simple, cheap, and controversial.

This country has an incredible reserve of untapped talent in the form of retired strippers and porn stars. What better way to put them to use than to use them as "stress relief counselors" in local high schools across the country ? As we all know the only truly effective, non-lethal way to reduce the violence level in young healthy males is to provide them with on demand unlimited opportunities for TD , i.e., "testosterone dumping".

Picture the following scenario: one morning an astute teacher observes a couple of Neanderthal football players picking on a freshman, call him Arthur. The abuse is violent enough that Arthur is visibly shaken. The teacher reaches for a small belt clip radio and keys in *4 . In a few seconds 4 absolutely humongous security guards arrive and drag off the two football players using a double baton choke hold. They are brought back to the "Violence Aversion Therapy Center", or VAT-C as we call it. There, in a special sound proofed room, they are repeatedly kicked in the groin and face, then handcuffed to a wall and urinated on. If the two football players are repeat offenders, HIV positive fags are brought in from the city jail to butt fuck them.

Back in the hallway the teacher writes out a two period hall pass that lets Arthur visit the "Stress Relief Center" or SRC as we call it. Arthur timidly knocks on the SRC door and a pleasant female voice calls out, "Come on in " .

There he finds Nina Hartley kneeling on a sofa with her fantastic tanned butt poised in an irresistible pose. Nina looks over her shoulder and seductively asks Arthur, "Does your girlfriend let you fuck her in the ass ? "

As Arthur stammers "N-n-no Mrs. Hartley" , his cock jumps in anticipation. Nina shakes her ass as Arthur unzips. After a dynamite butt fuck, Arthur relaxes on the sofa and Nina purrs in his ear, "Relax Arthur, I really enjoyed your cock in my ass. Sit tight while I suck your cock."

After a killer blowjob Arthur saunters back out into the hallway, floating on cloud nine. The afternoon classes go by in a pleasant blur. Hell, he doesn't even listen to the "Nine Inch Nails" CD he downloaded to his MP3 player yesterday, as he stares out the window of the bus on the way home. It will be several weeks before the glow of his TD experience fades.

Meanwhile, the football coach is working to restore the "fighting spirit" of the two perps after their gruesome VAT-C experience. At an off campus keg party for the whole team a busload of wheel chair bound mentally retarded youngsters is brought in. The two Neanderthals are given aluminum baseball bats and cheered on by their team mates as they bludgeon the helpless tots.

Over the course of time a symbiotic relationship evolves between the SRC staff and the football program. For reasons of job security each group needs the other. The important thing is that students under stress from bullying no longer feel the need to vent their rage, and through repeated VAT-C and keg party exposure, the football morons learn to redirect their violent behavior to more socially useful purposes.

Think about it, its a win-win situation.

Re:Whoops! (0)

Anonymous Coward | more than 2 years ago | (#37270964)

Cool, now try comprehension:

"While we currently believe that the source code repositories were unaffected, we are in the process of verifying this"

Re:Whoops! (1)

X0563511 (793323) | more than 2 years ago | (#37271046)

Yea? What part of that don't you understand?

Re:Whoops! (2)

realityimpaired (1668397) | more than 2 years ago | (#37271108)

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.

Re:Whoops! (1)

Stupendoussteve (891822) | more than 2 years ago | (#37271160)

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.

Re:Whoops! (2)

Dunbal (464142) | more than 2 years ago | (#37271250)

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.

Re:Whoops! (1)

Hatta (162192) | more than 2 years ago | (#37270808)

This is what signed packages are for.

Re:Whoops! (1)

Anonymous Coward | more than 2 years ago | (#37270940)

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.

Re:Whoops! (1)

Stupendoussteve (891822) | more than 2 years ago | (#37271180)

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.

Wishful thinking (2, Insightful)

Mensa Babe (675349) | more than 2 years ago | (#37270508)

"[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 [kernel.org] 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.

Re:Wishful thinking (5, Insightful)

Anonymous Coward | more than 2 years ago | (#37270566)

And seriously, why else would you hack kernel.org?

Re:Wishful thinking (0)

Anonymous Coward | more than 2 years ago | (#37270962)

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.

Re:Wishful thinking (4, Insightful)

msauve (701917) | more than 2 years ago | (#37271036)

"why else would you hack kernel.org?"

1337 points.

Re:Wishful thinking (1)

donotlizard (1260586) | more than 2 years ago | (#37271120)

How much are 1337 points worth in Bitcoin?

Re:Wishful thinking (1)

Amouth (879122) | more than 2 years ago | (#37270598)

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

Re:Wishful thinking (1)

drolli (522659) | more than 2 years ago | (#37270766)

Ahem. i did not leave my email there to notify me the last time i downloaded the tarball

Re:Wishful thinking (0, Interesting)

Anonymous Coward | more than 2 years ago | (#37271196)

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.

Re:Wishful thinking (2, Insightful)

X0563511 (793323) | more than 2 years ago | (#37270610)

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.

he's talking about tarballs (4, Insightful)

bill_mcgonigle (4333) | more than 2 years ago | (#37270660)

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 [kernel.org] gets pulled dynamically from git?

the kernel developers Who Matter

Are you saying users don't?

Re:he's talking about tarballs (1)

the_enigma_1983 (742079) | more than 2 years ago | (#37270776)

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.

Re:he's talking about tarballs (0)

slimjim8094 (941042) | more than 2 years ago | (#37270846)

Scripted? Not necessary.

git archive -o ../kernel-nightly-`date +%m-%d-%Y`.tar.gz master

should do it.

Re:he's talking about tarballs (4, Insightful)

Anonymous Coward | more than 2 years ago | (#37270992)

%Y-%m-%d please! Americans...

Re:he's talking about tarballs (1)

shibashaba (683026) | more than 2 years ago | (#37271042)

Yeah, like I need to be reminded what year it is on a daily basis.

Re:he's talking about tarballs (3)

nneonneo (911150) | more than 2 years ago | (#37271230)

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?

YMD sorts (5, Insightful)

perpenso (1613749) | more than 2 years ago | (#37271274)

Yeah, like I need to be reminded what year it is on a daily basis.

Actually YMD is useful because it sorts.

Re:he's talking about tarballs (1)

Anonymous Coward | more than 2 years ago | (#37271096)

And you put that in a script called "makearchives.sh" because you don't want to remember arcane commands for no reason.

Re:he's talking about tarballs (1)

SCVirus (774240) | more than 2 years ago | (#37270814)

No. But if the hash didn't match, an astute user would have noticed. And if the git version and the tarball didn't match, a developer would notice. So the hacker could have inserted a backdoor into git, but they would be noticed by a dev. They could have inserted a backdoor into the tarball and not modified the hash, but they would be noticed by a user. They could have inserted a backdoor into the tarball AND modified the hash, but a dev would have noticed. If you really want to get a backdoor into the kernel source code, do what the NSA does, contribute it.

Re:he's talking about tarballs (1)

Eskarel (565631) | more than 2 years ago | (#37270886)

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?

Re:he's talking about tarballs (1)

shibashaba (683026) | more than 2 years ago | (#37271076)

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.

Re:he's talking about tarballs (1)

Dunbal (464142) | more than 2 years ago | (#37271268)

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

Re:Wishful thinking (0)

Anonymous Coward | more than 2 years ago | (#37270664)

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.

Re:Wishful thinking (1)

X0563511 (793323) | more than 2 years ago | (#37271060)

Oh.

Well. You DO check the signatures right? Those are there for a reason...

Re:Wishful thinking (1)

Stupendoussteve (891822) | more than 2 years ago | (#37271258)

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.

Re:Wishful thinking (0)

Anonymous Coward | more than 2 years ago | (#37270676)

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.

Re:Wishful thinking (1)

drolli (522659) | more than 2 years ago | (#37270956)

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.

Re:Wishful thinking (0, Flamebait)

recoiledsnake (879048) | more than 2 years ago | (#37270614)

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 [slashdot.org]

Fedora/Redhat servers hacked.

http://linux.slashdot.org/story/08/08/22/1341247/Red-Hat-Fedora-Servers-Compromised [slashdot.org]

Debian servers hacked.

http://www.computerworld.com/s/article/87516/Debian_Project_servers_hacked [computerworld.com]

Gentoo

http://news.cnet.com/Hacked-Gentoo-Linux-server-taken-offline/2100-7349_3-5113227.html [cnet.com]

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.

Re:Wishful thinking (0)

Hatta (162192) | more than 2 years ago | (#37270746)

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.

Re:Wishful thinking (3, Insightful)

Manfre (631065) | more than 2 years ago | (#37270866)

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.

Re:Wishful thinking (0)

Anonymous Coward | more than 2 years ago | (#37270906)

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

Re:Wishful thinking (5, Informative)

nabsltd (1313397) | more than 2 years ago | (#37270972)

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.

Re:Wishful thinking (0)

Anonymous Coward | more than 2 years ago | (#37270902)

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.

Re:Wishful thinking (4, Interesting)

bzipitidoo (647217) | more than 2 years ago | (#37270918)

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.

Re:Wishful thinking (1)

Anonymous Coward | more than 2 years ago | (#37271068)

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?

You don't git it (3, Informative)

Anonymous Coward | more than 2 years ago | (#37270944)

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.

Re:Wishful thinking (0)

Anonymous Coward | more than 2 years ago | (#37271010)

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.

How did they hack it? (1)

zymano (581466) | more than 2 years ago | (#37270510)

security hole?

Re:How did they hack it? (4, Informative)

gchaix (1716666) | more than 2 years ago | (#37270576)

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.

Re:How did they hack it? (-1)

Anonymous Coward | more than 2 years ago | (#37270608)

IMMEDIATE DISCLOSURE? Are you F***ING kidding me!

They discovered it 3 days ago! Do you know how many people downloaded it shortly before they discovered it? Or mirrored it somewhere? Or put it in a distro? And they waited 3 F***ING DAYS to tell people?

NO F***ING WAY AM I GIVING THEM KUDOS FOR THAT CRAP

Re:How did they hack it? (0, Interesting)

Anonymous Coward | more than 2 years ago | (#37271002)

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.

Re:How did they hack it? (3, Insightful)

recoiledsnake (879048) | more than 2 years ago | (#37270720)

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?

Re:How did they hack it? (1)

gchaix (1716666) | more than 2 years ago | (#37270792)

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.

Re:How did they hack it? (1)

Anonymous Coward | more than 2 years ago | (#37270796)

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 [spinics.net]

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]

Re:How did they hack it? (5, Informative)

inode_buddha (576844) | more than 2 years ago | (#37271098)

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?

Re:How did they hack it? (2)

rubycodez (864176) | more than 2 years ago | (#37271150)

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

Re:How did they hack it? (1)

MadMaverick9 (1470565) | more than 2 years ago | (#37271176)

http://slackware.osuosl.org/slackware-13.37/slackware/x/xorg-server-xnest-1.9.5-i486-1.txt [osuosl.org]

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.

Re:How did they hack it? (1)

tibit (1762298) | more than 2 years ago | (#37271286)

Xnest was a bystander. It was probably a binary where the backdoor/exploit was living after the original intrusion.

Re:How did they hack it? (2, Informative)

Anonymous Coward | more than 2 years ago | (#37271288)

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

Re:How did they hack it? (1)

cultiv8 (1660093) | more than 2 years ago | (#37270804)

Well if it was a guru hacker it was something like:
% cat
Hello World.
^D

Oops (4, Insightful)

drolli (522659) | more than 2 years ago | (#37270534)

This is bad. Would the same thing happen to MS i dont think /.ers would skip the possibility to bash them.

Re:Oops (0, Insightful)

Anonymous Coward | more than 2 years ago | (#37270618)

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.

Re:Oops (1, Insightful)

bmo (77928) | more than 2 years ago | (#37270674)

>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

Re:Oops (0)

Anonymous Coward | more than 2 years ago | (#37270824)

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.

Re:Oops (0)

bmo (77928) | more than 2 years ago | (#37270856)

>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

Re:Oops (1)

LordLimecat (1103839) | more than 2 years ago | (#37271104)

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?

Re:Oops (0)

bmo (77928) | more than 2 years ago | (#37271256)

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

Re:Oops (1)

Dunbal (464142) | more than 2 years ago | (#37271302)

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.

Re:Oops (2)

Sarten-X (1102295) | more than 2 years ago | (#37270910)

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

Re:Oops (0)

Anonymous Coward | more than 2 years ago | (#37270938)

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.

Re:Oops (2, Funny)

Anonymous Coward | more than 2 years ago | (#37270986)

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.

Re:Oops (0)

Anonymous Coward | more than 2 years ago | (#37271020)

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.

Re:Oops (0)

bmo (77928) | more than 2 years ago | (#37271044)

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

Re:Oops (1)

LordLimecat (1103839) | more than 2 years ago | (#37271084)

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.

Re:Oops (1)

inode_buddha (576844) | more than 2 years ago | (#37271184)

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

Re:Oops (-1)

Anonymous Coward | more than 2 years ago | (#37271136)

What do you think the "Execute file" permission does in NTFS ACLs? You're worse than Windows fanboys. You're just a big idiotic fuckerlord.

Re:Oops (5, Insightful)

realityimpaired (1668397) | more than 2 years ago | (#37271264)

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.

Re:Oops (5, Insightful)

jrbrtsn (103896) | more than 2 years ago | (#37270812)

If the same thing happened to Microsoft, Microsoft wouldn't let anybody know.

Re:Oops (1)

drolli (522659) | more than 2 years ago | (#37271022)

But anybody would let MS know.

Re:Oops (4, Funny)

MaxBooger (1877454) | more than 2 years ago | (#37270880)

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.

Re:Oops (0)

shibashaba (683026) | more than 2 years ago | (#37271140)

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.

Linux isn't secure (0, Funny)

Anonymous Coward | more than 2 years ago | (#37270542)

Look, its been 20 years, linux has been a total failure, modding me down just means you agree.

Re:Linux isn't secure (1, Troll)

Opportunist (166417) | more than 2 years ago | (#37270594)

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.

Re:Linux isn't secure (0)

Anonymous Coward | more than 2 years ago | (#37270652)

Your post is more of a troll than GPs. You must be sucking lots of brown cocks!

Re:Linux isn't secure (0)

Anonymous Coward | more than 2 years ago | (#37270640)

Linux is awesome, modding me up just means you disagree.

Re:Linux isn't secure (2)

networkBoy (774728) | more than 2 years ago | (#37270954)

> [ 71.610908] ModPointEnabledAccount[4485]: segfault at 7f51210dfaa8 ip 000000000040c544 sp 00007fffdadb5970 error 6 in .logicParser[400000+15000]

Re:Linux isn't secure (0)

Anonymous Coward | more than 2 years ago | (#37270678)

Look, its been 20 years, linux has been a total failure, modding me down just means you agree.

Anonymous Coward++

They should have remembered.. (1)

halfaperson (1885704) | more than 2 years ago | (#37270712)

..to patch their kernels.

Re:They should have remembered.. (1)

Anonymous Coward | more than 2 years ago | (#37270888)

It's ok, someone has done it for them now.

Someone (0)

Anonymous Coward | more than 2 years ago | (#37270802)

was interested in Linus' backups.

Huh? (1, Funny)

atomicbutterfly (1979388) | more than 2 years ago | (#37270826)

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. :)

Re:Huh? (-1)

Anonymous Coward | more than 2 years ago | (#37270860)

fuck you faggot i'll set your house on fire. piece of nigger trash

Re:Huh? (1)

shibashaba (683026) | more than 2 years ago | (#37271112)

I suggest you look up the definitions of these words before you start using them.

Re:Huh? (1)

LordLimecat (1103839) | more than 2 years ago | (#37271122)

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

This could happen to anybody (-1)

Anonymous Coward | more than 2 years ago | (#37270848)

Maybe now the slobbering hordes of Linux fanbois will STFU about Apple.

oh hell (0)

Anonymous Coward | more than 2 years ago | (#37270980)

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... (1)

indros (211103) | more than 2 years ago | (#37271028)

Who's going to compromise the Linux kernel servers, and leave the linux kernel alone?

CmrTaco (-1)

Anonymous Coward | more than 2 years ago | (#37271074)

Ok Taco. You made it. Now, come back home.

face it (1)

gearloos (816828) | more than 2 years ago | (#37271228)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...