Xen Patches 7-Year-Old Bug That Shattered Hypervisor Security (arstechnica.com) 61
williamyf writes: ArsTechinca, The Register, and other outlets are reporting that today the XEN project patched a vulnerability in the ParaVirtualized VMs that allowed a guest to access the control OS of the hypervisor. Qubes researchers wrote: "On the other hand, it is really shocking that such a bug has been lurking in the core of the hypervisor for so many years. In our opinion the Xen project should rethink their coding guidelines and try to come up with practices and perhaps additional mechanisms that would not let similar flaws to plague the hypervisor ever again".
Can you patch the vulnerability in this haiku? (Score:-1, Offtopic)
Plugged inside a man's anus.
He is a faggot.
Re:Can you patch the vulnerability in this haiku? (Score:-1)
Re:Can you patch the vulnerability in this haiku? (Score:-1)
Tears were streaming down his face.
He was in agony.
It was a heart-wrenching sight."
Haiku is for cows fags. (Score:-1)
Re:Haiku is for cows fags. (Score:0)
conspiracy thinking thread starts here. (Score:-1)
So what does this mean ? Is the NSA annoyed because they lost a back entrance into cloud systems or has the NSA allowed this bug to be patched because they now have another way to get in ?
Re:conspiracy thinking thread starts here. (Score:0)
NSA allowing the vulnerability to be patched because XEN no longer has relevant market share.
Re:conspiracy thinking thread starts here. (Score:2)
It never really ever had "relevant" market share. Hypervisors only have been in the market for roughly ten years, and its not like they have been running nuclear power plants. Its closest relative, the microkernel, has in QNX, and other proprietary products.
Re:conspiracy thinking thread starts here. (Score:0)
Hypervisors are critical to IT functioning. Virtualization is one of the few security tools we have that actually is useful for not just separation but mitigation (keep the VMs away from hardware, add limits, roll back to snapshots, examine memory of client VMs for malware, etc.) A hypervisor bug is very critical in today's infrastructure, because many production installs use it.
In my experience, Xen is great for making lab or dev VMs, but the world has moved onto KVM or commercial hypervisors such as ESXi or Hyper-V, neither of which have issues with pwning the hypervisor from a VM.
The good thing is that hypervisors have a limited attack surface. Bad news is that if there is a VM to hypervisor priv escalation, it is a show-stopper.
Re:conspiracy thinking thread starts here. (Score:2)
Re:conspiracy thinking thread starts here. (Score:1)
You do realize that like, half of the 'cloud' runs on Xen right? Amazon, some of Rackspace, etc etc.
On the other hand (Score:0)
What about the first hand?
General advice, sir yes sir! (Score:0)
"try to come up with practices and perhaps additional mechanisms that would not let similar flaws to plague the hypervisor ever again".
Oh shit, why didn't they think of that!
Re:General advice, sir yes sir! (Score:0)
"try to come up with practices and perhaps additional mechanisms that would not let similar flaws to plague the hypervisor ever again".
Oh shit, why didn't they think of that!
This changes everything!
Re:General advice, sir yes sir! (Score:2)
Every piece of software contains at least one bug.
Also, every piece of software code can be shortened.
Therefore, every program can be shortened down to an empty source file which doesn't work.
NaDA (Score:0)
Every piece of software contains at least one bug.
Also, every piece of software code can be shortened.
Therefore, every program can be shortened down to an empty source file which doesn't work.
It's true:
http://www.bernardbelanger.com/computing/NaDa/index.php
Re:General advice, sir yes sir! (Score:2)
Re:General advice, sir yes sir! (Score:2)
What is the difference between an edge case and a corner case in testing?
For a non native english speaker they seem the same to me.
Re:General advice, sir yes sir! (Score:0)
They are, it just depends on who (which department - engineering or marketing) is making the 'excuse'.
Re:General advice, sir yes sir! (Score:2)
An edge case is a problem or situation that occurs only at an extreme (maximum or minimum) operating parameter.
A corner case (or pathological case) is a problem or situation that occurs only outside of normal operating parameters
Re:General advice, sir yes sir! (Score:2)
A corner case would be at an intersection of two edge cases! Almost by definition.
Re:General advice, sir yes sir! (Score:2)
Re:General advice, sir yes sir! (Score:2)
A corner case would be at an intersection of two edge cases! Almost by definition.
Almost, consider a corner involving three surfaces.
This is perhaps the single best question I have seen in a decade.
Bonus point for the asker.
End point case, overflow/out of bounds case, edge case, corner case...
I can offer some obvious, to me, thoughts. ... so does testing for zero in floating point land.
*) End points are sometimes ill defined and the last legal value and first illegal value must be
correct... Off by one bugs fall into this
Often found inside a function.
*) Edge cases would be interface issues between two functions with a single arg()
*) Corner cases functions with multiple args().
This simplicity ignores a lot!
In my experience labeling a bug with a type is more error prone than ....
any type-unsafe language. Consider bogus asserts()
Re: General advice, sir yes sir! (Score:0)
Corner case means rarely expected to occur and edge case to me means the extreme inputs expected. If you're testing a shopping cart, 0 and 999 might be edge and 666 a corner.
Not really, but makes sense to me.
Re: General advice, sir yes sir! (Score:2)
Re:General advice, sir yes sir! (Score:0)
"Oh shit, why didn't they think of that!"
Good question. I can only assume that they are sloppy.
XEN PV mode is dead (Score:5, Interesting)
The truth is nobody uses para-virtualized VMs anymore. EC2 which was the last bastion for pv xen stopped using it a couple of years ago and moved entirely to hvm model. I'm not even sure that the latest Linux kernel support are compiled with Xen PV support. If you looked at the kernel code for PV XEN support you know what the mess that was so good riddance. You need to understand what PV mode means for hypervisors: a kernel must be specifically modified to talk to a hypervisor so instead of performing a privileged CPU instruction it would call a Hypervisor provided function. I'm sure there were tons of security issues with that approach and many still exists. Anyway PV model is not relevant anymore since Intel introduced hardware virtualization on the CPU. It was introduced to to improve perfromance of VMs but it's not relevant anymore
Re:XEN PV mode is dead (Score:2)
I'm not even sure that the latest Linux kernel support are compiled with Xen PV support.
You mean, you're not sure if it defaults to Y? Or whether common distributions are enabling it when they build the kernel? The answer to the latter, at least, is yes. AFAICT, though, most people still using PV are using KVM. The rest are using containers.
Re:XEN PV mode is dead (Score:3)
Re:XEN PV mode is dead (Score:3)
Re: XEN PV mode is dead (Score:1)
The parent post should be considered a NOOP. There's plenty of accurate information available about the different modes and hybrid modes that hypervisors use these days, but reading the above will just make you stupid.
Re:XEN PV mode is dead (Score:1)
That may be the case for cloud deployment. However, there are other very important areas that PVs are being used. For example: qubes, a security focused Linux distribution https://www.qubes-os.org/ [qubes-os.org].
In addition, there is actually a full spectrum between PV and HVM: http://wiki.xen.org/wiki/Xen_P... [xen.org]. Very few use straight HVM, generally it is HVM + PV Drivers. Linux on Xen ends up using PVHVM. The sweet spot for Open Sources OS under Xen is PVH.
Or just broke it (Score:2)
"Shattered" really?
What the hell is in charge of the Gawker-style headlines, because I think that same robot should be made responsible for editing: at least we know it's working.
Re:Or just broke it (Score:2)
What the hell is in charge of the Gawker-style headlines, because I think that same robot should be made responsible for editing: at least we know it's working.
You won't believe this one annoying trick for making your clickbait better bait. Advertising works, that's why people use it. Propaganda, likewise.
Re:Or just broke it (Score:2)
Do you understand the function of a hypervisor? Do you understand how tremendously BAD it is if the host OS can control the hypervisor?
So, imagine ... all these people selling cloud services, making millions and millions of dollars ... now, imagine that those things in the cloud can control the infrastructure for the cloud, when they should have no way in hell of doing that.
For a hypervisor, this is pretty much an epic fail.
With enough Eyes.. Blah Blah Blah (Score:3)
ESR Was wrong. Enough Eyes are not enough!
One needs Enough QUALIFIED AND MOTIVATED eyes, as well as proper test cases, a Quality Assurance group and Technical Guidelines.
Re:With enough Eyes.. Blah Blah Blah (Score:2)
No you're wrong because you have woefully misunderstood the quote.
He said with enough eyes all bugs are shallow.
Not "with enough eyes no bugs exist ever".
It means that given enough people, once a bug manifests then it's shallow, i.e. easy to fix, for someone.
Re:With enough Eyes.. Blah Blah Blah (Score:2)
FLOSS software: anybody can discover a bug, notify the maintainer, and have it fixed promptly. Even the maintainer won't do it, one also has the freedom to make the fix and recompile the source on one's own.
Re:With enough Eyes.. Blah Blah Blah (Score:0)
Give it a rest. If the eyes aren't looking at the fucking code, what do you expect? Why didn't you review it? Afterall, you're a self-proclaimed expert in all things. How about comparing it to closed source products and how often they lead to compromised systems. Why not start with the entire Adobe range, and Java, as well as your beloved windows systems, the plague of the entire fucking Internet.
Get back to your helpdesk scripts, prick.
Misunderstanding ESR. Shallow, not non-existent (Score:5, Insightful)
ESR didn't say "given enough eyeballs, no bugs exist."
He said they are -shallow-. "The fix will be obvious to someone". That is, you won't spend a month trying to to figure out exactly why foo sometimes conflicts with widget - with with several people looking at the source (not just the output of the binary), someone will more quickly see why foo conflicts with widget and how to fix it.
It looks like in this case it was about 48 hours or so to characterize the problem, agree on the proper fix, code it, test, patch the major public clouds, and release it publicly. Guessing that patching the public clouds took 24 hours, that's about 24 hours for understanding the problem, discussing it fixing it, and testing. Not bad. Here's a quote from CATB with the context of the "bugs are shallow" part:
---- ... if any serious bug proved intractable. Linus was behaving as though he believed something like this:
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.
My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it.
----
It's about bugs not being intractable - they aren't extremely hard to figure out, "the fix will be obvious to someone". That doesn't mean they never existed.
Re:Misunderstanding ESR. Shallow, not non-existent (Score:2)
First of, to some other chap that called me a shill (fortunately, down modded), my disbelief about the many eyes is not new, nor is it related to FOSS versus closed source. Please see my posting history on /.
Second, this bug was "Unshallow" seven (7) years... 'Nuff Said!
Let me explain using my favourite example: The Metafile fiasco of 2005.
Here we had Two (2) Codebases. One Closed Source (Windows) and one FOSS (Wine). BOTH codebases contained the error. It took 10 years for someone (the guys at Sunbelt Software) to realize the error. Neither Microsoft nor WINE detected the error, even if they had many eyes looking at the code. My hypothesis is that the Microsoft guys were unmotivated, and the WINE guys lacked QA and technical direction. Both codebases patched fast.
Please notice that the fact that WINE was FOSS did not help in the least the WINE team to detect the error (or any other group for that matter). And while some people say "The WINE team was just replicating the functionality", this is false, for, had the WINE Team themselves detected the security vulnerability as such, they would have made it public immediately, patched the code, and added a line in the config file of the form:
MetaFileVuln = 0 /* 0 keep the vuln replicate windows behaviour /* 1 implement WINE team Fix /* 2 replicate Microsoft fix If or when they release it
So, is not about many eyes. To catch and solved the bugs and security vulnerabilities you need more than many eyes...
You need QUALIFIED AND MOTIVATED eyes, QA, Test Cases, and some Process guidance...
And my friends, I read, and still have in my drive the Version 1 of ESR's paper. Read it fresh from the oven, not the many reinterpretations, remember, is a work in progress, is V3 nowadays...
ESR doesn't beleive that either (Score:2)
Have a read of the relevant sections of the oldest, most original CATB you can find. I think you'll see it says the same thing. You see, he was talking about the (then new) troubleshooting process that Linus had implemented.
The solution to the metafile bug didn't require deep meditation for ten years. If you don't know there is a bug, that doesn't mean it's buried deep, it just means you don't know there's a bug.
Of course to prevent bugs you need educated developers, good testing, etc. That's all true. And has little or nothing to do with what ESR discussed in that passage. Again, he didn't say "no bugs exist", he said "the solution will be obvious to someone" - it's about the process of solving bugs - preventing them is another topic altogether. If you read the four or five sentences BEFORE thehalf of the sentence that became famous, he's talking about a the difference between user who can only see the problematic output of a binary versus someone who can read the source and see which part is going wrong.
Re:Misunderstanding ESR. Shallow, not non-existent (Score:0)
Yes, but to this day there are millions of Open Source advocates who believe that merely being licensed under a FOSS model, automatically provides "enough eyeballs". And most of those who know better, still believe that the principle of source code availability is worth everything even though the average FOSS user will never work on a single piece of source code. And of those who know better than that, there is still a pervasive belief that source code availability is only actioned under a FOSS license.
All such positions are wrong. In fact they are so completely wrong that they are Not Even Wrong.
FOSS has value, but mainly because it produced software that is useful and may not have been produced otherwise. Too many FOSS believers have a near-religious belief that FOSS licenses cure all software evils and that is a profound error.
it means you're not dependent on a single vendor (Score:2)
To me, a huge value of FOSS is that the vendor doesn't have you by the balls. If you need something fixed or changed, you can hire any of millions of programmers to take care of that for you. It doesn't matter if the vendor has gone out of business, isn't interested, etc. - you're in control of your own systems.
This can be worth millions of dollars to a large business or government agency, because migrating to a different, competing system can cost that much if your current software doesn't fill your need. If you need some piece to handle Euros as well as dollars, a programmer with the open source can probably do that for a few hundred to a few thousand dollars, instead of tens of thousands or even millions to replace the system throughout your organization and re-do all of the integration work, employee training, etc.
That and of course for smaller organizations and families the dollar cost difference can be huge, allowing homes and small offices to have enterprise grade functionality. A router with "advanced" features like QOS can easily cost a thousand dollars or more. OpenWRT is $0.
So what? (Score:-1)
Virtualization is not that hot anyway. It brings more software to the table, which may have bugs like anything else. So, sure, sometimes you find a bug that lets you break into the host OS. If that worries you, don't virtualize then. It is not as if it is "necessary" anyway. If a machine can run some services in virtual machines, it can also run these services without a virtualization layer - and then with higher performance. About the only "need" I see is when people use virtualization to make up for the lack of security in their favourite OS . . .
Maturity of a 7 year old, too (Score:0)
How can you spot bugs, sitting way up on your high horse?
Hint - when the Xen guys wrote this, you were still wearing braces and speaking in a high voice. Cut them some slack, kiddo.
Bugs happen, even in hypervisors (Score:3)
Go do LWN's search page [slashdot.org], uncheck all the boxes except for "security vulnerabilities", and then search for "KVM". Or Qemu, or Linux or Xen.
You'll find that all hypervisors have privilege escalation bugs discovered. However, this is the first one discovered in the Xen PV interface in a long time.
Re:Bugs happen, even in hypervisors (Score:0)
However, this is the first one discovered in the Xen PV interface in a long time.
Well... to be fair, that's probably because almost nobody still uses used PV. ;)
BREAKING NEWS: Nobody has found a new bug in MS-DOS 3.x in the past 20 years, so it must be the safest OS ever. /s
Bug in English (Score:1)
Can we trust people to critique code who can't even manage English grammar? There's a basic principle here: All writing needs an editor. What looks good to the person who wrote it can have bad syntax.
Re:Bug in English (Score:3)
that would not let similar flaws to plague the hypervisor ever again
Can we trust people to critique code who can't even manage English grammar?
Yes. Very few program is written in English. C is more common.
And looking at the Qubes OS team https://www.qubes-os.org/team/ [qubes-os.org], I'd bet English isn't the primary language for most of them.
Re:Bug in English (Score:0)
Can we trust people to critique code who can't even manage English grammar?
Absolutely. Can we trust people who are closed minded and irrational to critique code? Not as much.
Classic Open Source (Score:2)
Re:Classic Open Source (Score:3)
Criticizers. (Score:2)
On the other hand, it would be a good idea to people stop harassing open source projects when serious and/or old bugs are discovered *and* fixed.
Nasty 7 years old bug discovered? Bad indeed.
Nasty 7 years old bug *FIXED*? Good, very very good.
Once you decide not to throw everything through the Windows, I mean, window every year ("fixing" old bugs with new bugs), you must expect that old flaws will one day be discovered. And fixed.
There're too many criticizers nowadays - but almost none of them got his hands dirty to know what they are criticizing.
I have no idea what Hypervisor is but... (Score:2)
Re:I have no idea what Hypervisor is but... (Score:0)
I have no idea what Hypervisor but all I keep envisioning is...
Geordi LaForge
SmartOS anyone???? (Score:0)
This is the type of scenario you will NEVER see in SmartOS: Performance and Security over anything else!! ZFS, DTrace, Zones, Crossbow do I need to say more?
Re:SmartOS anyone???? (Score:0)
Broke from the hypervisor? great your're now in a secured zone.
Privilege escalation vulnerability caused by .. (Score:2)
Can someone explain how the bug worked? (Score:2)
The actual bug is shown in the original article. The author says "It appears the seven-year-old Xen bug is caused by an entanglement of C macros, bit masking, and Intel x86's fiddly page table flags" but fails to explain exactly what's going on (probably he doesn't understand it himself). Can some explain what actually happens in this line and what failure modes caused the check to be bypassed?
The fact that such a simple-looking line could result in such seriously flawed code tells me that programming secure code in C is much much harder than I thought, especially when what looks like a clean function call is actually macro expansion, perhaps layers of macro expansion. Mot a fault of C per se, but a gotcha when using a lot of macros as if they were C functions.
Flush XEN (Score:2)