Beta
×

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!

5-Year-Old Linux Kernel Bug Fixed

Soulskill posted about 5 months ago | from the must-have-been-union dept.

Bug 127

rastos1 sends in a report about a significant bug fix for the Linux kernel (CVE-2014-0196). "'The memory-corruption vulnerability, which was introduced in version 2.6.31-rc3, released no later than 2009, allows unprivileged users to crash or execute malicious code on vulnerable systems, according to the notes accompanying proof-of-concept code available here. The flaw resides in the n_tty_write function controlling the Linux pseudo tty device. 'This is the first serious privilege escalation vulnerability since the perf_events issue (CVE-2013-2049) in April 2013 that is potentially reliably exploitable, is not architecture or configuration dependent, and affects a wide range of Linux kernels (since 2.6.31),' Dan Rosenberg, a senior security researcher at Azimuth Security, told Ars in an e-mail. 'A bug this serious only comes out once every couple years.' ... While the vulnerability can be exploited only by someone with an existing account, the requirement may not be hard to satisfy in hosting facilities that provide shared servers, Rosenberg said."

Sorry! There are no comments related to the filter you selected.

my p3ni5 gets enlarged (-1)

Anonymous Coward | about 5 months ago | (#46994073)

..when I hear this. Time to crash.

Fuck BETA (-1)

Anonymous Coward | about 5 months ago | (#46994081)

Fuck linux BETA am going with microsoft's VMS kernel... It's the mature thing to do....

This is the problem with Linux Security (3, Insightful)

metrix007 (200091) | about 5 months ago | (#46994093)

Linux and Greg K-H have both gone on record saying that security issues are just another type of bug, and don't deserve any type of special treatment.

This is crap. A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.

When you don't assign the significant to security issues that they deserve, they go unpatched for 5 years.

It's kind of a concern.

Re:This is the problem with Linux Security (3, Interesting)

metrix007 (200091) | about 5 months ago | (#46994121)

To expand on this, not only do they not assign security bugs the priority they deserve, they actively hide them.

http://arstechnica.com/securit... [arstechnica.com]

FWIW, I love Linux and used Slackware for almost a decade.

Re:This is the problem with Linux Security (3, Interesting)

Wonko the Sane (25252) | about 5 months ago | (#46994387)

If the kernel developers allowed bugs to be clearly marked as security vunerabilities, then it would be trivial to use the Git commit history to identify the individuals who are merging these exploits into the kernel.

Re:This is the problem with Linux Security (3, Insightful)

Microlith (54737) | about 5 months ago | (#46994529)

It's already trivial to do that. What would "clearly marking them as security vulnerabilities" gain?

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46996735)

If the kernel developers allowed bugs to be clearly marked as security vunerabilities, then it would be trivial to use the Git commit history to identify the individuals who are merging these exploits into the kernel.

It's very very hard to define a "security bug" in the kernel (though it has to be done). Almost any odd behaviour can be exploited by sending a set of instructions which works differently in the place of a bug. An application can be relying on almost anything a computer does any unexpected behaviour could cause a problem. What is a huge problem on a server (like this) might not be a security bug on an embedded system which has not. The opposite is also true. A failure to beep on demand from the TTY could turn stop a fire alarm working. The kernel is never a complete system. I doubt the majority of Linux users (on Android) are affected in any way.

So; let's be clear what we want so that Linus cannot pretend that there is no answer. We do not want all security bugs to be reported since we don't know which they are. What we want is policy that Linux kernel maintainers have to agree to (and voluntarily for everyone else). It should go something like this/

  • There should be a list in the latest kernel source of Linux vendor security contacts for vendors who agreed to act "responsibly" (to be defined by that group with Linus having a veto)
  • At the moment that someone realises that a bug in the kernel could be used by one group to harm a specific other group of people then they should contact the security contact of one (any will do - if they fail to act "responsibly" they are removed from the "responsible" group) of the vendors affected.
  • If there is a git checkin already committed then they should be told about it. If not, they should be given any information available about exploits, patches etc.
  • There should be a (minimal) delay available to allow those vendors to prepare for any public release; subject to the agreement of the person who identified the security vulnerability.
  • During the delay any patches should only be passed up in the maintainer tree in the direction of Linus and be held in private repos and should always be copied to the security contact. At the end of the delay
  • A maximum suggested limit of e.g. five days delay on patches with fixes being published.

That's it. Nothing complex. Nothing even requiring much work from the maintainers (since they hand everything extra on to the security contacts). Just a simple declaration that, if we know about it we will report it to the vendors. It would be nice if the communication was secure and encrypted. The vendors should list their security contact GPG keys in the kernel source.

Re:This is the problem with Linux Security (-1)

Anonymous Coward | about 5 months ago | (#46994467)

"FWIW, I love Linux and used Slackware for almost a decade."

FWIW I love zebra and polar bear flesh.

Re:This is the problem with Linux Security (-1)

Anonymous Coward | about 5 months ago | (#46995451)

Fuckwit.

Re:This is the problem with Linux Security (5, Interesting)

Anonymous Coward | about 5 months ago | (#46994145)

Well it can't be patched before it was discovered but you seem to be implying this issue was known about 5 years ago.

How long from when it was discovered did it take to be patched?

Re:This is the problem with Linux Security (1, Troll)

jcochran (309950) | about 5 months ago | (#46994597)

The GIT entry for the bug was entered Dec 3, 2013. So that means at a minimum, the bug was known of and not fixed for 5 months. That's a bit excessive for 'A bug this serious only comes out once every couple years' kind of bug. I'll agree that 5 months is a lot shorter than 5 years, but it's still far too long.

Re:This is the problem with Linux Security (3, Interesting)

Anonymous Coward | about 5 months ago | (#46994831)

Was it? Where? The git commit linked in the article is for 2014-05-03. Given the number of fixes and revisions this patch went through, one has to actually hunt it down in the MLs to know.

So, can you please point us to the source of your information?

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46994845)

Which git entry do you mean? All git links are dated May.

Re:This is the problem with Linux Security (0, Troll)

metrix007 (200091) | about 5 months ago | (#46995119)

Given that the people in charge don't tend to disclose security vulnerabilities and actively hide them, it's difficult to say how long it was known for.

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46995779)

You're actively trolling now. Why?

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46995755)

Can you provide a link to that, please.

Re:This is the problem with Linux Security (0, Troll)

kwbauer (1677400) | about 5 months ago | (#46995883)

According to all the hype about FOSS, it should have been discovered by all those thousands of pairs of eyes before it ever shipped so it should have been fixed at least five years ago, according to all that hype.

Re:This is the problem with Linux Security (4, Insightful)

Bryan Ischo (893) | about 5 months ago | (#46996245)

Taking off-topic potshots against FOSS in response to a misinformed post which incorrectly describes the date of the bug report in response to a post which inaccurately maligns the attitude of kernel developers towards security bugs?

For fuck's sake, we're three levels deep in FUD here. Someone throw me a rope so I can pull myself out of this quagmire of bullshit.

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46997233)

, we're three levels deep in FUD here. Someone throw me a rope so I can pull myself out of this quagmire of bullshit.

It would be easier for you to get out of the bullshit if you weren't busy adding to it yourself. Sink.

Re:This is the problem with Linux Security (2)

The123king (2395060) | about 5 months ago | (#46997169)

Bugs can be ancient. anyone remember that Windows VDM bug that affected every version of Windows based on NT? How is this bug different?

Bugs have to be found, you can't expect every bug to just be easy to find. That's how things like Heartbleed, and the VDM bug don't get discovered for years. I'm sure there's probably bugs almost as old as Linux itself in the kernel, and i'm almost certain there's bugs in Windows affecting everything from 3.1 up.

But yes, i'd be very suprised if this bug was reported 5 years ago. It's not unheard of in the Linux world, but it really shouldn't be happening, and thankfully happens rarely (and when it does, Slashdot has a field day)

Re:This is the problem with Linux Security (1, Insightful)

waddgodd (34934) | about 5 months ago | (#46994175)

Well, in a normal situation, I'd say yes, but Linux's response to all bugs is similar, patch it as soon as there's a good patch. Now if it were a certain company in Redmond that scales its response based on customer "value", yeah, security bugs had best get fast-tracked. I honestly prefer the "fix all bugs and don't embargo fixes" response that linux does to the "when we discover bugs (heartbleed), we'll let the Cool Kids in on it first and then release it weeks later to the average user" response that Google does

Re:This is the problem with Linux Security (2, Interesting)

metrix007 (200091) | about 5 months ago | (#46995149)

You should read up some more on the clash between security professionals and the Linux maintainers.

Some bugs are more critical than others, and hiding them not to get negative attention or (rightfully) be pressured to fix them is pretty bad.

Re:This is the problem with Linux Security (0)

waddgodd (34934) | about 5 months ago | (#46996115)

Don't see where your flamebait actually changes anything. It certainly provides nothing new, because you can say "they're rude" all day, the question is is the bug in question fixed, and when. Yes, the chances are very good that a bug submitter is going to get a "patch or GTFO" response. In the overall scheme of things, I'd say that's as good as can be expected, given many other groups respond with legal threats.

Re:This is the problem with Linux Security (1)

metrix007 (200091) | about 5 months ago | (#46996177)

Excuse me, but what flamebait? I did not insult you or your argument, instead I made a valid counter argument.

Oh, and my point wasn't that the maintainers are rude. My point is that the security industry keeps insisting the the Linux team practice responsible disclosure, and they keep arguing there is no need or benefit.

Re:This is the problem with Linux Security (-1)

Anonymous Coward | about 5 months ago | (#46996783)

Tosser.

Re:This is the problem with Linux Security (0)

fizzer06 (1500649) | about 5 months ago | (#46994231)

Linux and Greg K-H have both gone on record

Who is "Linux"?

Re:This is the problem with Linux Security (5, Funny)

Anonymous Coward | about 5 months ago | (#46994561)

You know, Linux Torvaldx ix the guy who firxt xtarted writing the Linux kernel. He'x pretty famoux. I'm xurprixed you've never heard of him.

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46995025)

Rofl!...made my day thx.

Re:This is the problem with Linux Security (0)

metrix007 (200091) | about 5 months ago | (#46995159)

If you're going to be so anal to question an obvious typo, I guess I could ask what the point of your post is, as it only contains quotes.

Re:This is the problem with Linux Security (1)

fizzer06 (1500649) | about 5 months ago | (#46996261)

My post contained the question.

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46996903)

No, cunt, it contained nested quotes. Fuck yourself to death with a red hot poker.

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46994257)

Linux and Greg K-H have both gone on record saying that security issues are just another type of bug, and don't deserve any type of special treatment.

This is crap. A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.

When you don't assign the significant to security issues that they deserve, they go unpatched for 5 years.

It's kind of a concern.

That is why they have something called "priority" in bug. Now if you say "Dos" which is high impact bug then yes it set to high priority. Thats it. This doesn't mean you have to fix this bug first than fixing a critical kernel crash that you get everytime you login. Now priority number is the decider which goes first. Well if they are messing with that, then you are right it is crap!

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46994269)

Depends on your situation right? Performance glitches and stability issues are a killer compared to security issues, when I cruise my linux-based spacecraft through a cloud of astroids near the speed of light..

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46994549)

Well I'm glad _someone_ has RTLinux working for them...

Re:This is the problem with Linux Security (1)

naasking (94116) | about 5 months ago | (#46994277)

A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.

I agree security vulnerabilities are worse than simple bugs. However DoS is not. Our entire network infrastructure is already vulnerable to DoS, so vulnerabilities of this sort are just par for the course really.

Re:This is the problem with Linux Security (0)

jcochran (309950) | about 5 months ago | (#46994611)

Might want to check the GIT report again. To quote: ... which allows local users to cause a denial of service (memory corruption and system crash) or gain privileges by triggering a race condition involving read and write operations with long strings. ...

Notice that the bug permitted an easy denial of service attack. And with more effort a privilege elevation.

Re:This is the problem with Linux Security (2, Informative)

Anonymous Coward | about 5 months ago | (#46994859)

There's no such thing as "GIT report" mentioned anywhere here, only GIT commits and they're too recent...

Did you mean CVE? CVEs reservation dates don't correspond with bug discovery date - for example, CVE numbered one less than this one is not even created yet [mitre.org] , but it lists the same "20131203" reservation date.

Re:This is the problem with Linux Security (1)

naasking (94116) | about 5 months ago | (#46995261)

I'm not referring to any specific DoS, just DoS as a general class aren't necessarily security vulnerabilities, ie. specific DoS vulnerabilities might also be security vulnerabilities, but being a DoS vulnerability does not automatically also make it a security vulnerability.

Re:This is the problem with Linux Security (1)

dreamchaser (49529) | about 5 months ago | (#46995683)

Any bug that allows a remote attacker to compromise a system, be it stealing data or denial of service, is a security vulnerability. All DoS vulnerabilities are security vulnerabilities by definition.

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46997269)

This particular vulnerability permits root privilege escalation or a local DoS attack, depending on the specific exploit code leveraged. Learn to fucking read before commenting on serious issues, you fucking idiot. Seriously, go get a good fucking night's rest and read the following words out loud as soon as you wake up: "I will not make public statements on things I don't fucking understand." Afterward, feel free to have a great fucking day, but until then, go fuck yourself. Cheers.

Re:This is the problem with Linux Security (3, Interesting)

wisnoskij (1206448) | about 5 months ago | (#46994537)

I completely disagree. The reason I use a OS is because its features work and it doe snot crash all the time, I could not care less if it were 1% more secure.

I gotta say (2, Funny)

Anonymous Coward | about 5 months ago | (#46995031)

a "doe snot crash" sounds pretty bad to me. Just sayin'. Do you have deer hanging around your computer?

Re:I gotta say (1)

tepples (727027) | about 5 months ago | (#46995355)

Do you have deer hanging around your computer?

Yeah, plenty of goldeer [wikia.com] and even a few eldeer [wikia.com] .

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46995083)

:*) "snot crash" +1 awesome typo

Re:This is the problem with Linux Security (1)

metrix007 (200091) | about 5 months ago | (#46995431)

Stability and security are not mutually exclusive.

Although if you care about stability, then you should also care about security since many malicious attacks can affect stability.

Re:This is the problem with Linux Security (1)

jones_supa (887896) | about 5 months ago | (#46996877)

Although if you care about stability, then you should also care about security since many malicious attacks can affect stability.

True, but most stability problems do not stem from malicious attacks.

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46994579)

Except *most* kernel bugs can be turned into security issues. Bugs in a kernel are much more far-reaching than bugs in userspace. You are also implying that it took fives year to patch, which is not true: it was introduced five years ago but only discovered at the end of last month (http://www.openwall.com/lists/oss-security/2014/05/05/6).

Re:This is the problem with Linux Security (0)

jcochran (309950) | about 5 months ago | (#46994697)

Look at the GIT entry. It was entered Dec 3, 2013. A few months earlier than "end of last month". Also the disclaimer on the GIT entry means that the bug could have been discovered even earlier, so the Dec 3 date is merely a "no later than" boundary on the discovery date.

Re:This is the problem with Linux Security (1)

Anonymous Coward | about 5 months ago | (#46994823)

And by "GIT entry" you mean "CVE entry", which clearly says "Disclaimer: The entry creation date may reflect when the CVE-ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE."

Look at the CVE entry. None of linked documents are earlier than last month.

Re:This is the problem with Linux Security (1)

Bite The Pillow (3087109) | about 5 months ago | (#46996123)

Your argument does not convince. Why reserve a CVE Id and sit on it for six months? Maybe there is a reason, I'm not familiar with how CVE internals work. Your argument is pointless without more support. Sounds like you don't understand the system you defend, which seems rather silly.

Re:This is the problem with Linux Security (1)

Barsteward (969998) | about 5 months ago | (#46996847)

i could accuse you of the same thing.. " I'm not familiar with how CVE internals work, my argument is pointless without more support." fixed it for you..

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46996991)

> I'm not familiar with how CVE internals work

Why are you even arguing here, then?

CVE IDs are assigned by a number of CVE numbering authorities. This includes Mitre itself plus big software companies like MS and Red Hat, plus few extras. Each authority requests pools of CVE IDs to assign from Mitre. Year in CVE ID is the year of original bug report, which blows up the "sat on it for 6 months" theory.

Here's that initial bug report [openwall.com] referenced in CVE. Note how it says: "Date: Mon, 5 May 2014 12:08:11 +0200 [snipped message to oss-security list] CVE-2014-0196 has been assigned to this issue. [snipped] Date: Tue, 29 Apr 2014 12:38:36 -0400 [snipped original bug report and patch] We, at suse, would appreciate embargo till Mon May 5th."

That is, discovered and reported with a patch at 140429, then published at 140505 with an ID from SUSE's pool reserved at 131203.

HTH, HAND.

PS: Hearbleed is also from 131203 IDs batch [mitre.org] , as well as at least 323 others this year [mitre.org] .

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46994851)

I'm looking at it, and it says 2014-05-03. That's 3rd May 2014, for the braindamaged.

So you must be looking at some other git tree. Which one?

Re:This is the problem with Linux Security (0, Troll)

kwbauer (1677400) | about 5 months ago | (#46995927)

but this is open source and open-source proponents have always claimed in the past that the advantage of open-source is that the bugs are discovered by the thousands of pairs of eyes before they ship. So the truth is that this bug was discovered five years ago but not fixed. Either that or there is no inherent security advantage to open-source. Which falsehood have you been telling all these years, boys?

Re:This is the problem with Linux Security (0)

jones_supa (887896) | about 5 months ago | (#46996899)

Ahoy, mod parent up. That's an important distinction. In addition to the claimed "eyes searching for bugs", there's already a sea of bugs that have been found and properly reported, but they get fixed slowly. Some of these are critical bugs. Now someone comes to say "you ignore the fact that proprietary software is no better". And it isn't! But the claim that bugs get fixed quickly in OSS is not true. It's a myth, just like the eyeballs thing.

Re:This is the problem with Linux Security (1)

ilotgov (637717) | about 5 months ago | (#46994819)

Who is Linux agian?

Re:This is the problem with Linux Security (0)

metrix007 (200091) | about 5 months ago | (#46995169)

If you can't tell who was meant from the context, you should probably head on over to some other, simpler website. Perhaps Mac Rumors.

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46996315)

agian? in a four word post complaining about a typo?

Re:This is the problem with Linux Security (1)

phantomfive (622387) | about 5 months ago | (#46995731)

A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.

You are right, but it doesn't apply in this case. This was a privilege-escalation exploit, which means you already need an account on the computer to do anything.

It's still a problem and I'm willing to bet there are more of these in the Linux kernel, just because they're so tough to clean out.

Re:This is the problem with Linux Security (1)

metrix007 (200091) | about 5 months ago | (#46996183)

The examples I used in my post were just that, examples. They were not meant to be specific to this story, as I think the issue is greater than just this story.

Re:This is the problem with Linux Security (1)

tlhIngan (30335) | about 5 months ago | (#46996427)

This was a privilege-escalation exploit, which means you already need an account on the computer to do anything.

Any account would do. Even say, "nobody".

All you need is the ability to run an arbitrary binary, which a buggy CGI script is more than adequate. Basically, if you have a bit of shellcode, that's sufficient. Once you have that going, then you can easily exploit your way to more priviledges.

That said, for the time being we now have a good way to root our Android phones.

Re:This is the problem with Linux Security (1)

phantomfive (622387) | about 5 months ago | (#46996585)

That said, for the time being we now have a good way to root our Android phones.

.......until you reboot. Unless you can get at the bootloader.

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46995957)

You are ridiculously wrong. This bug would not have been fixed any faster by having an explicit "security bug" classification. The devs did not let it sit around known-but-unfixed until someone created an exploit, the way some vendors do it. It is a very good thing that linux takes all bugs seriously, not just the few that some researcher decides are special.

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46996005)

Linux and Greg K-H have both gone on record saying that security issues are just another type of bug, and don't deserve any type of special treatment.

That's actually half correct. The OpenBSD guys consider bugs to be exploits that haven't been discovered yet.

Re:This is the problem with Linux Security (1)

MadTinfoilHatter (940931) | about 5 months ago | (#46996205)

A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.

May be. But this particular bug does not allow remote anything. It requires a local malicious user. PFTFCVELITS (Please Follow The Fine CVE Link In The Summary)

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46997609)

You're an idiot. Any remote vulnerability that permits arbitrary code execution in the context of an unprivileged account is highly likely to serve as a vector for root privilege escalation if the payload exploits this vulnerability. Please get a goddamned education in these matters before further polluting the discourse with idiotic minimization of the risk at hand. Thanks!

Re:This is the problem with Linux Security (0)

Anonymous Coward | about 5 months ago | (#46997037)

Linux and Greg K-H have both gone on record saying that security issues are just another type of bug, and don't deserve any type of special treatment.

This is crap. A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.

Go look at the alternative. At least one other OS treats security issues as features and keep them rather than fix them.
The same OS also keeps bugs because of backwards compatibility.

Security issues are bugs and should be handled as those.

Re:This is the problem with Linux Security (1)

Threni (635302) | about 5 months ago | (#46997375)

> This is crap. A bug that allows remote code execution or even a DoS is a much,
> much bigger issues than fixing the user experience or minor stability issues.

You're not a security professional. You should have to put that in your sig file. The linux kernel is used in many different situations, and clearly some security problems only pose a risk in some of those situations. IE. a lot of embedded systems will never be vulnerable to this particular issue.

A bug is a bug. All bugs should be triaged and then treated accordingly. You don't pretend a bug is more important because security is the flavour of the month.

Soooo..... (1)

Anonymous Coward | about 5 months ago | (#46994113)

'A bug this serious only comes out once every couple years.'

....in the time it took to fix this bug they got two more just as bad?

One step forward, two steps back.

OpenBSD time... (0)

Anonymous Coward | about 5 months ago | (#46994163)

The open source projects aren't doing to well lately with these severe bugs, seems like the only people taking security seriously anymore is OpenBSD, I guess it's time to switch!

Re:OpenBSD time... (-1)

Anonymous Coward | about 5 months ago | (#46994263)

I am a fan of Windows 7. I've configured the install that I'm rockin' to get patched monthly, automatically. It's nice to have such solid support.

Re:OpenBSD time... (1)

cheater512 (783349) | about 5 months ago | (#46994307)

Oh don't worry too much about it.

It is only notable because everyone is desensitized about commercial software bugs.
Compare it to Windows. How many patches do they make which are major or critical each year?

Re:OpenBSD time... (0)

Anonymous Coward | about 5 months ago | (#46994415)

Oh don't worry too much about it.

It is only notable because everyone is desensitized about commercial software bugs. Compare it to Windows. How many patches do they make which are major or critical each year?

Compared to Hartbleed and this, I don't know of any of similar critical level and impact. We are not looking good trying to misdirect the seriousness of these long undiscovered highly critical FOSS vulnerabilities.

Re:OpenBSD time... (1, Insightful)

vux984 (928602) | about 5 months ago | (#46994567)

Compared to Hartbleed and this, I don't know of any of similar critical level and impact.

Any remotely exploitable bug that allows for remote code execution / priviledge escalation without user interaction is just as bad or worse.

After all, heartbleed was "just" a remotely exploitable memory "leak"; but if you have remote code execution, you can scan the memory and send home anything interesting; to the same effect as heartbleed, plus anything else you might want to do once you are running on the system.

Windows XP early on (until SP1 or 2?) was remotely exploitable in this way as I recall. And there have been other exploits just as bad over the years.

Heartbleed was a big deal but its not singularly bad. There's been others before it.

Re:OpenBSD time... (0)

Anonymous Coward | about 5 months ago | (#46994705)

Compared to Hartbleed and this, I don't know of any of similar critical level and impact.

Two words: Internet Explorer.

Re:OpenBSD time... (0)

Anonymous Coward | about 5 months ago | (#46995225)

It is only notable because everyone is desensitized about commercial software bugs.

Compare it to Windows. How many patches do they make which are major or critical each year?

Who cares? Your attempt at misdirection has no relevance here. Windows isn't used nearly as much in the server market or the embedded market and certainly no security solution from Microsoft is used as widely as OpenSSL. The implications of these issues are far more far-reaching than any of those in Windows. Linux is more often trusted with safeguarding the data of millions, Windows is not so Linux comes under greater scrutiny when issues like this arise. Being as it isn't as highly used in the server market in general you hit one Windows machine and you get the data for 1 person, hit one Linux machine and you get the data for 1 million people.

Add to that a vulnerability in the Linux kernel can also lead to millions of unpatchable, vulnerable Android phones and tablets so yes it should come under greater scrutiny.

Dismissing this under the guise that "Windows has more bugs" is pure idiocy, what will you do when/if Microsoft does finally become irrelevant in the desktop market? When dealing with issues like this you need to face the issue not try and direct people's attention away from it in a desperate bid to save face.

Re:OpenBSD time... (0)

Anonymous Coward | about 5 months ago | (#46994451)

Sure, if:

* it had a larger community
* there was an official forum rather than just MLs.
* they freely offered official LiveCD/USB images
* overall system configuration could be done in GUI(s)

Re:OpenBSD time... (0)

Anonymous Coward | about 5 months ago | (#46994565)

* it wasn't dying

Re:OpenBSD time... (1)

metrix007 (200091) | about 5 months ago | (#46995195)

OpenBSD is and mostly always has been a joke.

"Secure by default" isn't the same as auditing a few core services and disabling the rest.

They do a great job of maintaining OpenSSH though.

5-year-old allegations (1)

turkeydance (1266624) | about 5 months ago | (#46994195)

are demotions or dismissal. let alone actual proof. in a four-year administration.

AND THIS ONE IS GOING OUT TO (-1)

Anonymous Coward | about 5 months ago | (#46994235)

Casey Kasem !!

Gone, but not forgotten.

the real problem with linux security (0)

Anonymous Coward | about 5 months ago | (#46994375)

The real problem with linux security is that the buggy kernels could be widely deployed, and unlikely to be patched. Maybe your router or washing machine or microwave has buggy linux hidden inside it. The chances of all those linux installations being patched is very low.

Once The Internet Of Things is running, there will have to be serious consideration given to security. Otherwise there will be a series of stories like "criminals broke into my home network through my buggy washing machine and stole lots of important and secret data!".

If you want "guaranteed employment", study computer security. There is gonna be a big demand for it soon.

Re:the real problem with linux security (0)

Anonymous Coward | about 5 months ago | (#46996221)

The real problem with washing machine security is that you might have been "Tivoed" and therefore unable to update/fix your washing machine, in spite of it supposedly running Free Software (i.e. maintainable software).

This problem is why we have GPL3. But where's the GPL3 OS?

Re:the real problem with linux security (0)

Anonymous Coward | about 5 months ago | (#46997173)

True. Btw, are there any tools available for finding out the current status of exploits in a certain kernel version? That would help script kiddies a lot, perhaps it would even benefit others by forcing vendors to actually update their firmwares.

This is the problem with Windows Security (1, Insightful)

Anonymous Coward | about 5 months ago | (#46994391)

count the # of remote exploits patches in each version of Windows and how many years between patches where the OS was vulnerable.

Re:This is the problem with Windows Security (0)

Anonymous Coward | about 5 months ago | (#46995057)

At this point in history, "Microsoft Security" is an official oxymoron. On par with military intelligence, jumbo shrimp and the rest, it's set in stone.

Re:This is the problem with Windows Security (0, Insightful)

Anonymous Coward | about 5 months ago | (#46995273)

count the # of remote exploits patches in each version of Windows and how many years between patches where the OS was vulnerable.

Yep, standard response of the Linux zealot: Problem with Linux? Point out a problem in Windows!
Great way to handle it bud!

Re:This is the problem with Windows Security (0, Insightful)

Anonymous Coward | about 5 months ago | (#46995359)

Ah yes, a bug for the Linux kernel shows up and a coward uses Windows as a benchmark. Nice job. it may not be good dog food, but at least it is better than Windows.

"Linux Kernel Bug Fixed by 5-year-old" (0)

Anonymous Coward | about 5 months ago | (#46995121)

Misread the title on this one, and was most disappointed once I read TFS.

I owe it all to Explain Like I'm Five (1)

tepples (727027) | about 5 months ago | (#46995391)

Would that be the result of a 5-year-old following Explain Like I'm Five [reddit.com] for a while and becoming smarter than the average public school teacher (see recent story about public school failure [slashdot.org] )?

Has anybody tried it? (0)

Anonymous Coward | about 5 months ago | (#46995229)

Has anybody of you, "nerds", tried it? Just out of curiosity. I've been running it on my machine (2.6.37) for 10 minutes already, while I'm typing this comment. So far it keeps printing those dots after "Attempting to overflow...".

FucK!! (-1)

Anonymous Coward | about 5 months ago | (#46995351)

To predict *BSD's aal; in order to go percent of the *BSD

Alan Cox (0)

Anonymous Coward | about 5 months ago | (#46995533)

Wasn't it around 5 years ago that Alan Cox left as the role of maintaner of the tty layer? I wonder whether the bug had a chance to get into the kernel while the new maintaners were still learning the ropes so to speak.

They need a better HOSTS file (-1)

Anonymous Coward | about 5 months ago | (#46995535)

APK Hosts File Engine 9.0++ 32/64-bit:

http://start64.com/index.php?o... [start64.com]

(Details of hosts' benefits enumerated in link)

Summary:

---

A. ) Hosts do more than AdBlock ("souled-out" 2 Google/Crippled by default) + Ghostery (Advertiser owned) - "Fox guards henhouse", or Request Policy -> http://yro.slashdot.org/commen... [slashdot.org]

B. ) Hosts add reliability vs. downed or redirected DNS + secure vs. known malicious domains too -> http://tech.slashdot.org/comme... [slashdot.org] w/ less added "moving parts" complexity + room 4 breakdown,

C. ) Hosts files yield more speed (blocks ads & hardcodes fav sites - faster than remote DNS), security (vs. malicious domains serving mal-content + block spam/phish), reliability (vs. downed or Kaminsky redirect vulnerable DNS, 99% = unpatched vs. it & worst @ ISP level + weak vs FastFlux + DynDNS botnets), & anonymity (vs. dns request logs + DNSBL's).

---

Hosts do more w/ less (1 file) @ a faster level (ring 0) vs redundant browser addons (slowing up slower ring 3 browsers) via filtering 4 the IP stack (coded in C, loads w/ OS, & 1st net resolver queried w\ 45++ yrs.of optimization).

* Addons are more complex + slowup browsers in message passing (use a few concurrently - you'll see) - Addons slowdown SLOWER usermode browsers layering on MORE: I work w/ what you have in kernelmode, via hosts ( A tightly integrated PART of the IP stack itself )

APK

P.S.=> * "A fool makes things bigger + more complex: It takes a touch of genius & a lot of courage to move in the opposite direction." - E.F. Schumacher/Einstein

** "Less is more" = GOOD engineering!

*** "The premise is, quite simple: Take something designed by nature & reprogram it to make it work FOR the body, rather than against it..." - Dr. Alice Krippen "I AM LEGEND"

...apk

       

5 year old tempest in tty pot (3, Interesting)

stock (129999) | about 5 months ago | (#46995637)

The problem was well discussed in 2009 here : A tempest in a tty pot https://lwn.net/Articles/34382... [lwn.net] The result was that after a heated debate, Alan Cox was blamed for allowing old code to stay because emacs would loose terminal output and Greg KH was simmoned to stepup as the TTY maintainer. The new TTY/PTY guys became James Simmons, the Frame-buffer guy and C. Scott Ananian, the former jack-of-all-trades for the One Laptop per Child Foundation. Curious enough it were not Linux server systems like RedHat Enterprise who have been vulnerable for almost 5 years, but the popular Linux desktop distro's like Ubuntu.

Re:5 year old tempest in tty pot (1)

Anonymous Coward | about 5 months ago | (#46995977)

Curious enough it were not Linux server systems like RedHat Enterprise who have been vulnerable for almost 5 years, but the popular Linux desktop distro's like Ubuntu.

Wrong. RHEL 5 isn't affected, it uses an old kernel. RHEL 6 is affected: https://bugzilla.redhat.com/sh... [redhat.com]

This issue does not affect the versions of the Linux kernel packages as shipped
with Red Hat Enterprise Linux 5.

This issue does affect the versions of the Linux kernel packages as shipped
with Red Hat Enterprise Linux 6 and Red Hat Enterprise MRG 2

Re:5 year old tempest in tty pot (0)

Bite The Pillow (3087109) | about 5 months ago | (#46996145)

The old guy screwed up, was replaced, and the new guys screwed up too. Does that mean replace or do not replace?

  Or just that you remember old news?

If the latter, stick to tagging dupes here.

POC doesn't work here. (5, Interesting)

ralphtheraccoon (582007) | about 5 months ago | (#46996789)

I read through the POC, it seemed safe enough to play with, so I've tried it out on a few different servers here (CentOS & Debian Stable). On the CentOS boxes it dies before it even gets started trying to overflow into a tty, and on my Debian machine it's been going for 5 minutes (using up to 90% CPU, but still leaving the machine quite usable), and still hasn't got anywhere.

This isn't quite the "instant ROOT ACCESS!" privilege escalation that scares keeps sysadmins up at night. (unless I'm missing something...)

OpenSSL too (0)

Anonymous Coward | about 5 months ago | (#46997007)

In other news [eweek.com] , there was also a 4-year-old flaw in OpenSSL. In the same way this bug was publicly reported (CVE-2010-5298 [nist.gov] ) for years, without no one taking the responsibility to fix it.

Here's a detailed report [tedunangst.com] of the bug by OpenBSD developer Ted Unangst. It was finally fixed in the recent quality assurance effort conducted by the OpenBSD guys.

Must mention microkernels (2)

Megol (3135005) | about 5 months ago | (#46997281)

As something like this would be impossible with the driver executing in an isolated process. Memory corruption would still be possible of course (unless the driver was written in a secure language) but it would be local.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?