Dirty COW explained: Get a moooo-ve on and patch Linux root hole 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.
@MotionCompensation
"A man who seems to have serious communication issues, to point where I'm willing to question his mental stability"
good job with the 'armchair psychoanalysis'. NOT.
Your attitude (my armchair psychoanalysis) reflects a person who is ENVIOUS of "the genius" and seeks to re-define genius as "a disorder" - like AD[H]D, some new flavor of autism, ass-burgers, whatever... something to be "cured" so that NOBODY is 'super' any more.
/me recognizes that in SOME cases, these 'disorders' may be real, but in MOST, I suspect it's simply "curing the genius" for his own good... and lazy teachers drugging johnny so his bored genius mind won't cause him to disrupt the class.
Amazing, the lengths some people will go to in order to diss Open-Source!
So Linus made a mistake (sort of). He admitted it, fixed it and moved on. MS have had known bugs running for years. I remember one where I found 6000+ questions about it on the web dating back 7 years. I forget the details but it affected data transfer, via SQL Server, between machines.
The root solution is simple. Don't use Linux, then complain about what you are using - there will ALWAYS be something to complain about. The difference is that, in open-source, the discussions are open and frank.
Thank you for Linux, Linus.
It's fair to expect the Register to keep quiet about something like this, after all it's only an reliably exploitable privilege escalation bug in Linux and Android.
Though I am appalled that there wasn't a mention of some sql server inter service bug you vaguely remember from years ago! You know, for balance.
"It's fair to expect the Register to keep quiet about something like this, after all it's only an reliably exploitable privilege escalation bug in Linux and Android.
Though I am appalled that there wasn't a mention of some sql server inter service bug you vaguely remember from years ago! You know, for balance."
FIFY. See icon>>
Here we go Linux vs Windows fanboys, lightsabres at the ready.
Truth is no software will be relatively secure until processors and hardware subsystems are re-designed from the ground up with security coming first in the mind of the architects. It's an afterthought to performance and convenience.
http://www.pcworld.com/article/3132969/security/flaw-in-intel-cpus-could-help-attackers-defeat-aslr-exploit-defense.html
"Truth is no software will be relatively secure until processors and hardware subsystems are re-designed from the ground up with security coming first in the mind of the architects. It's an afterthought to performance and convenience."
For good reason. What good is security if you don't get the bloody job done? A fortress is no good without a way in or out, for example.
> For good reason. What good is security if you don't get the bloody job done? A fortress is no good without a way in or out, for example.
8086 architecture (or ARM for that matter) was never initially built with security primarily if at all in mind, anything that has been added in the way of security is just a patch. It never was designed as a fortress, more of a garden shed as a place to dump your tools.
How can you get the job done when someone has robbed all your tools ?
"How can you get the job done when someone has robbed all your tools ?"
With your hands. At least the shed means you can stay out of the rain, which means you can STILL get the job done. Besides, in the digital world, you can't rip silicon out of its housing without taking the entire CPU away, so bad analogy.
Interesting you bring up the 8080 because that clearly demonstrates the mindset back then, and the mindset today (because no one's been able to create something secure-first that can still do the job): the job comes first, security second. If you're in a situation where security is so critical that the world can depend on it (like the US military), then a whole other mindset is needed which is generally incompatible with deadlines.
..in everything. With the complexity in modern systems, I really don't think it will be possible to stamp out every possible way to exploit any OS or device. Even physical security is subject to this--look at the ruckus caused some years back when someone figured out how to use "bump keys" to allow utter novices with no lock picking skills to easily bypass formerly secure locks.
Next week the exploit du jour will be in code from MS, or Apple, or perhaps again in Linux, or somewhere entirely different. The only thing that matters is that there WILL be another bug. You can blame complexity, the "CYA" mentality, stressed out developers rushing things to market under the whip of managers, but even with 100 years of nothing to do but gaze at code, there will still be another bug.
This is why IMO the constant warnings about the "Internet of Things" are spot on. If you want to be secure, only an air gap will truly prevent us ingenious, morally-questionable humans from finding another way around the next patch.
"This is why IMO the constant warnings about the "Internet of Things" are spot on. If you want to be secure, only an air gap will truly prevent us ingenious, morally-questionable humans from finding another way around the next patch."
Which is next to useless for something you HAVE to network. So how do you secure something that MUST be networked? And no, Joe Public WILL NOT accept, "You can't" for an answer. They want an answer, toot sweet.
Why should a regular user care?
Especially for something like a networked light bulb?
As long as it does what it is advertised for, that's all the final user cares about.
The real problem is the abuse of IoT for actions that are not user visible.
Like starting DDOS attacks.
We need to make manufacturers responsible for any actions of their devices that were not explicitly advertised to the users. Then the manufacturers will start paying attention!
It is really not fair to blame the final users.
"We need to make manufacturers responsible for any actions of their devices that were not explicitly advertised to the users. Then the manufacturers will start paying attention!"
But what happens when the manufacturers hide behind sovereignty? And lots of things are imported direct to the buyer these days? How will you stem that without seriously hurting the economy?
"It is really not fair to blame the final users."
However, for the stuff that's actually in operations and exposed to the net the users are likely to be the only ones who can actually take action, especially if the only possible action is to disconnect it.
"However, for the stuff that's actually in operations and exposed to the net the users are likely to be the only ones who can actually take action, especially if the only possible action is to disconnect it."
Which means it's NOT an option because the average user won't care. And if their ISP cuts them off, they'll say they're being denied service they paid for and the lawyers will get involved.
> *laughs*
> Yeah, clearly.
> And with Linus swearing about people writing crappy code, then this happens... Oh the irony.
didn't you get the memo from The Register Linus Fellation Brigade? you should NEVER develop systematically and you should NEVER automate regression testing. you never blame the defective system or defective processes. just blame whatever developer fights back the least from your bullying.
all you need is to get yourself a project manager who is a foul-mouthed Finnish butter-troll to swear incoherently at your developers whenever the heinous spaghetti code fails!
just do the opposite of everything discussed in this article (https://www.fastcompany.com/28121/they-write-right-stuff?show_rev_content) and then throw your shitty OS over the fence to cause trillions of dollars of damage in the real world.
it's the Linus way!
cue for... howls of outrage by the Windows community...
I guess it's only fair though. When your cherished systems incur bugs frequently and gets jeered at (by folks who often think their toys are perfect), you just want to lash out at your tormentors when you get a rare opportunity to do so.
There, there, let it out. Don't hold back. You'll feel all better now.
;-)
Peace on both camps. No one's perfect and Linux users could use the humility to be more vigilant and not think they are automagically immune.
This post has been deleted by its author
This post has been deleted by its author
"Unfortunately, builds of the vulnerable kernel at the heart of countless millions of routers, Internet-of-Things gadgets and other embedded devices remain vulnerable"
meh, I wouldn't worry too much about those in this case. They don't really do much meaningful privilege separation anyway, and you're usually not going to have remote access as an unprivileged user enabled. Local root privesc bugs are most important on systems with lots of stuff running unprivileged and remotely accessible...
Despite the article claiming Red Hat have a patch out, the article link is only to the CVE announcement on Red Hat's site. If you check the Bugzilla bug for it here:
https://bugzilla.redhat.com/show_bug.cgi?id=1384344
You'll see that there isn't actually a patch out yet as of Monday morning UK time. There is a (fiddly) mitigation procedure involving systemtap documented at the above URL, but no new kernel RPM to fix the issue yet. This means that CentOS and other RHEL clones are also unpatched at this moment in time as well.
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
