Utterly inexcusable...
...of Linus to have sat on this for a decade while it festered and escalated.
I wonder how many more dirty great gaping backdoors he's got hidden up his bum.
Need a Torvalds' salute icon ----->
Patch your Linux-powered systems, phones and gadgets as soon as possible, if you can, to kill off a kernel-level flaw affecting nearly every distro of the open-source operating system. Dubbed Dirty COW, the privilege-escalation vulnerability potentially allows any installed application, or malicious code smuggled onto a box, …
It is, but at least we can fix this one.
The patch may even be able to be back-ported to 2.6.22 where this once came. Or you might be able to dig up the patch that breaks S/390…
This is to say nothing about the gaping holes in Windows XP and other Microsoft OSes that will never be patched.
The code in question was flagged publicly 11 years ago. Why didn't YOU patch it, AC?
I suppose the AC is going to demonstrate to us all a better method of dealing with a FOSS software project the size of the Linux kernel ... when, exactly? What's that? You don't even have a suggestion for an incremental improvement?
It's no wonder you posted AC, you have nothing to actually say.
@AC
-----> gaping backdoors
Care to comment on this ?
https://technet.microsoft.com/en-us/library/security/ms16-120.aspx
Note, under active exploit.
Every current version of Windows affected and probably XP as well. Must be that backdoor Billy boy allowed the NSA to put there in Win95.
Those quoting Windows problems miss the point, that's the equivalent of pointing at your neighbours crummy shed while your own stately home is going up in flames (yes, that's what they are in comparison IMHO, so sue me :) ).
I could understand the decision so many years ago, but I must admit I'm not too impressed by seeing how small the fix is - unless it's not really a fix.
And I don't care how unsafe Windows is. I no longer use it, and it's entirely irrelevant in context.
Isn't this being a bit over hyped?
Ignoring which OS we're talking about:
Most servers don't allow direct logins when facing the public internet. So, for example, if you're running an Apache server you don't let people outside your organisation login so any privilege escalation can't happen. Your risk comes from your own staff which should be a much lower risk than the world and his wife.
If it's your personal PC then the risk comes from a virus written to take advantage of this bug. Here it could be a problem if you're in the habit of installing stuff from dodgy sources.... but most people don't.
Next comes your mobile phone... fair enough, here you're stuffed but then this won't be the first security problem will it :-)
I'm not saying that bugs like this aren't a problem but reporting tends to consist of "oh no, we're all going to die" which isn't true and desensitises people.
"Isn't this being a bit over hyped?"
yes, and no.
planes rarely crash. when a plane crashes, it's BIG NEWS, and gummint agencies, airlines, plane manufacturers, etc. go to work to prevent such things from happening in the future.
Same here. Linux security problems are RARE. When it happens, it's a big thing. Let's just get if fixed.
On a related note, embedded systems that cannot easily run binary executables will most likely NOT have a true vulnerability. So unless your IoT device or router has a COMMAND SHELL that is directly exposed to the intarwebs, it's not very likely to be exploited. [and if it DOES, the system architect needs to be sufficiently whipped with a Cat-5-O-Nine-Tails]
>Your risk comes from your own staff which should be a much lower risk
NSA might disagree with you on that. Honestly good enterprise security is well aware its biggest risk is usually insiders. They might be much rarer than outsider attackers but the havoc they can wreck can be many times greater.
Have you seen how many of the forum programs work, such as wordpress? They often execute programs, when they do, they run as the webserver user (normally 'nobody' or 'http'), or whoever the PHP forks as. This needs an account, obviously. The shell could still be set as /bin/false, but a shell is not required. You could mmap a kernel module, if you so wish, as inject something there. You could replace su with your own. Heck, do what you want.
and you have no idea how much that underlines how little you understand about how complicated this is...
You could be right. After all, I spent 5 good years of my life researching a topic that I can now summarise in a single line, but that summary would simply not have been possible without not only the 5 years worth of work, but also the decades of experience on which it builds.
I'll have to see if I can find an explanation I understand. In any case, I already saw a fix fly by in the Debian updates. Buggered my uptime, but I can live with that - after you've clocked your first year that's no longer quite as exciting :).
So let me get this right. El Torvaldo tried to fix the issue a decade ago but had to roll it back because of an issue with the S/390 build. Something that is used by, what, <5% of the total Linux base? But (I speculate here, someone please correct me) the hole was not documented, except in his memory. Fast forward ten years and millions of units later and now he is able to fix the hole in two lines of code.
Technical debt, anyone?
From what I understand here is what happened.
Linus first noticed a bug that was a side effect of this underlying error and attempted to fix it. He rolled it back due to the S/390 build failing and just said screw it since the bug he was experiencing wasn't actually doing anything bad at the time. This was all before Copy On Write was implemented into the kernel so there wasn't any vulnerability yet. Fast forward 10 years and COW is now implemented in the kernel around this buggy code. Someone found the bug and used it in combination with COW to produce this exploit in the wild. Then it was noticed and patched. I don't think Linus would have just left a bug like that sit for 10 years unless it was pretty trivial and at the time couldn't cause anything malicious.
His sin was in not leaving comments in the code explaining "here's a relatively harmless bug I found but didn't fix because of XYZ".
Then maybe someone else would have decided to have a look at fixing it sometime in the past 11 years, or at least when the COW support was added someone would have thought "wait a minute, maybe that bug isn't so harmless anymore" and they would have fixed it before mainstreaming COW support.
> CoW wasn't implemented yesterday in the Linux kernel...
I should hope not, CoW was a pretty standard feature of Unix kernel's in the very early 90 before Linus even released his first version of Linux. It isn't a new idea and on an OS built around the idea of fork()ing it's pretty essential to performance.
What I don't understand is why /proc/self/mem is allowing writes into a read-only portion of the address space. If you mmap a something read-only then trying to write to it should cause an error. The pages should be marked RO in the TLB and an exception should be thrown resulting in a bus error or segmentation violation.
This nothing to do with technical debt, at least as far as I see. Where does the S/390 come in?
It has, however, a lot to do with a lack of formal methods (i.e. proving that code correct in the sense of fulfilling its specification) in an industry that prides itself on hacking complex systems "by mind alone" while features are being added like garlic to a greek roast lamb. This is bound to result in trouble, in this case entirely avoidable race conditions.
We are not going the refit the mentality nor the tools to the current code and developer base within the next 20 years, so there will be more of this on the menu. Brace for IoT!
The problem with formal proofs is that they can ONLY apply in a very narrow set of circumstances. seL4, for example, is ONLY formally proven when no DMA is allowed. But the real world intrudes, and secure code is next to useless if it doesn't let you get the bloody job done, and in the real world, performance matters.
IOW, the worlds where Linux is used are too mercurial for a set of formal parameters to be constructed. Thus, formally proving Linux under all its real-world use cases is likely infeasible.
The problem with formal proofs is that they can ONLY apply in a very narrow set of circumstances.
This is untrue and an opinion from the 90's. High-reliability software running in clearly defined circumstances (and let's face it, kernel-level code is not exactly "real world" worthy; no need of neural networks here) is today passing through the appropriate formal mangler, likle for example avionics software.
"This is untrue and an opinion from the 90's."
Having tried to formally prove some simple programs back in the 90's, I have to say, it's not entirely untrue. To formally and mathematically prove the correctness of software is a daunting, time-consuming task. And probably horribly expensive to do on a large scale.
"390's must be way way way less than 5% of the linux base in terms of user numbers or cpu counts... Way way way less."
That is not the point. When this bug was unfixed, it was because at that moment in time it was simply unacceptable to just break Linux on S/390. Commit f33ea7f404e5, more than a decade ago, posed a simple question: Do we live with a vulnerability that at this point in time is a minor and obscure one, or do we break Linux on a type of host that is usually deployed in response to high-reliability and high-availability requirements? The answer to which would be "Duh", AFAIC.
That said, this could have been better documented at the time and perhaps fixed before it became a high-profile issue. That said, we now all know what happened, why and how it happened, and what was done to adequately fixed it. Which is the proper way to deal with this.
"But (I speculate here, someone please correct me) the hole was not documented, except in his memory."
You are wrong. It's been publicly documented since August 1st 2005. See: https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
Technical debt? Of course, technically. Not that that is necessarily a bad thing.
Where you do you see that it is documented since 2005? When I click on the issues tab, everything is dated in the past couple days.
You clearly didn't look hard enough. Commit messages points the way to this very commit, which is not from the "past couple days".
There has to be a malicious program running on your computer designed to exploit this. It's a privilege escalation.
It's somewhat less likely there is a malicious program already, on a workstation etc behind a firewall with no outward facing services and "Noscript" or similar on the Browser.
Perhaps it has something to do with the security of millions of devices worldwide depending on the actions of one man. A man who seems to have serious communication issues, to point where I'm willing to question his mental stability. It's not a healthy situation and the root cause is not a technical one, I don't buy the long technical explanation in this article.
...to point where I'm willing to question his mental stability.
It's a good job you're not in a position of authority then. There are many of us who question Linus' communication skills, but surely few would make the enormous leap to "questioning his mental stability". He is in control of something that grew way beyond it's original scope to become a product with global significance and with that in mind I think he copes relatively well. To finger this bug as evidence of a health issue is mental.
IOW, the thing about closed source is that someone has to be held responsible for it such that if something goes wrong you can sic the lawyers on them. When things go wrong with Windows, at least people can sue Microsoft. Who do you sue when something on Linux goes wrong, especially if the author in question is not subject to your jurisdiction?
IOW, the thing about closed source is that someone has to be held responsible for it such that if something goes wrong you can sic the lawyers on them. When things go wrong with Windows, at least people can sue Microsoft. Who do you sue when something on Linux goes wrong, especially if the author in question is not subject to your jurisdiction?
Whether closed source or open source is irrelevant. The important thing is the license, because you agree to the terms offered in it, including any warranties for fitness, etc. That license is the contract that governs the responsibility of the producer and consumer.
"When things go wrong with Windows, at least people can sue Microsoft."
Eh, let's think - when was the last time we heard of someone (or some company) doing that on any large scale?
Given Windows' well-earned historical reputation as security swiss-cheese, then by your logic, Microsoft should be the most-sued company in the history of the universe, and their defense lawyer bills alone would have eaten up every penny of profit they've ever made (or will make for the next 200 years). So no, your point is not valid in the least. Nobody sues Microsoft to the level that you are casually implying.