New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Xen security advisory is now published: https://xenbits.xen.org/xsa/advisory-254.html
There are two separate classes of vulns. One is significantly more serious and only affects Intel
Redhat errata got published, https://access.redhat.com/errata/RHSA-2018:0011, CVE-2017-5754 affects Intel only, CVE-2017-5715 and CVE-2017-5753 affect both vendors, all 3 are classified as Important in CVSS scoring. The 2 that affect both vendors have attack vector 'Adjacent Network', the one that affects Intel only has impact 'Local'. Not being a kernel security expert, and reading from the CVSS metrics, the 'Adjacent network' ones that affect both vendors appear more worrying and have a higher score of 8.2, contrary to Intel specific one that has a score of 7.9.
In any case, it's a serious screwup, which hopefully will get solved properly/completely rather sooner than later.
Some papers down here, https://spectreattack.com/
>
Google was showing how convoluted it was, but what's interesting about this is that a specific Debian distro was used, and this allowed the KVM's virtual instance to both make things easier, and harder for a kernel attack. Basically, you're polluting the cache to make it either do what you want- or to block it from doing what the nefarious party intends, as you are either seeding, or breaking the cacheline.
I'm just glad they aren't calling it Intelbleed
A bit of low-end love:
So intel was basically correct, they did not screw up much more than others, and I was also partially correct, virtualization significantly complicates the attack, but I was not right that is a needle in the haystack thing to exploit it directly on the host OS.
You can basically dump memory and it probably works in containers and PV virtualization for the whole node.
I think KVM and Xen-HVM can come up with a patch or some serious redesign later to mitigate this, I would also say it should have been there anyway.
This is exactly my takeaway from it all too.
They just launch website to keep the info together :
https://spectreattack.com or meltdownattack.com
same web
and still no official statement from amd(?)
Interesting. Would be good if KernelCare can get this patched without a reboot.
Alexander
I'd be interested to see just how they'd do this since it's going to need to change the entire path of code execution. Pretty sure it's going to require a reboot- but I'd be pleasantly surprised otherwise.
[Insert joke here about how a 2.6.x based kernel should not be affected due of it's age.]
Specifically an older distro.
With a little more information coming out it seems that my explanation was quite OK and I feel confident to add a little more.
The bad news: This whole issue is even worse because what we're looking at (and what all the fuzz is about) is but 3 variations (2 of which aren't that different) of what could be called "a funny mine field kit" - and a very complex one at that.
While they all have in common that they offer ways to cross privilege boundaries they are using combinations of diverse vectors. Some, to name an example, rely on the fact that a cache write out takes about 100 cycles (read: plenty time to do evil things), others rely on and (ab)use the processors internal prediction buffer.
One frightening issue is that many (actually most) paths haven't even been looked at and tested. Some of the involved researchers mention, for instance, return prediction, which has the potential to be a very dangerous animal.
"Funnily" it seems that KVM is quite an ideal rape candidate, however, one must have the context in mind. Looking from a somewhat higher perspective ovz is by far the most easily rapeable virtualization, and all but one xen mode isn't any more secure than kvm. A propos "secure": None is secure, it's just that one xen mode looks better at the current state which, again, is by no means knowing about all attack vectors.
As for "AMD is safe": Yes and no. There are two parts to this. Part 1 is that AMD implemented one (1 of many) detail differently (and, looking from a security point, better) than intel. Part 2, and the more interesting one, is twofold, a) all those attacks are very processor specific (as in "tiny differences between different xeons"), but b) the little mentioned fact that intel is all but condemned to keep all their processors very similar for compatibility reasons. AMD's advantage is that they had a little more free room when designing their zen architecture plus, importantly, that they could built their processor for today and based on what's known today while some of the intel quirks reach back to the 80386!
In practical terms - which probably are very important for many here - you should expect an ugly multiple wave of updating your nodes, both the OS and the hypervisor, which to make it funnier, quite probably will not come up with updates at the same time. So expect something like 1) update the node distro and 2) update KVM or whatever you use and both of those multiple times over a period of a couple of months. The good news is that the first round is about "vaccination" and the following ones mostly about optimization (decreasing performance penalty).
And: Expect a) lots and lots of blabla from intel, and b) new processor series that are "even more secure". After all, large corps wouldn't be large corps if they wouldn't turn even "you have cancer!" verdicts into profit...
Yes and no. Virtualization is one of the main targets. I predict that the "secure xen mode" will be fucked, too. Simple reason: This mine field is largely "invisible" to hypervisors, as it's way above their time granularity (and happens within the guts of the processor).
Hint: One of the problems (of a whole can of worms) is that code in the loosing branch can quite easily escape the exception mechanism.
We'd also be well advised to understand that the whole thing is not about this or that virtualization - it's about privilege levels and it's of little concern whether ring 0 is a kernel or a hypervisor.
Plus we'd be well advised to keep in mind that the research shows that it's not only about data sniffing but also about what in effect is code manipulations.
Oooor, if Linus Torvalds is right and not merely throwing a random fit as he sometimes does, Intel might be trying to disclaim responsibility (something their very PR-y PR statement does suggest) and, by taking advantage of the fact that some of these issues also affect AMD and ARM, making it purely the OS's responsibility to handle this, notwithstanding the performance hits incurred: https://lkml.org/lkml/2018/1/3/797
..which Google has specifically targeted with hypervisors. I wonder what is so clean/usable with this older Debian instance.
I wouldn't doubt this. Then Intel can throw whoever else under the train while not only trying to save face- but trying to avoid the lawsuits related to issues with their very own special path to ring 0.
Then the reverse is also true, the code run in the guest does not go lower than the hypervisor, unless a passthrough is in effect.
So, if a cpu is virtualized and only a select few calls are passed on with minimal checks, then it is highly unlikely this will work at all, regardless how old is the os, or even specially crafted versions. This can be fixed in the hypervisor without incurring the top penalty that a wipe at switch can in an extreme case.
When virtualized, Google has found that you can still alter the code that will be automagically run with the current prediction setup for approximately 100 cycles. This can be hand-crafted in a way to assist, or cause further flummoxing of [hacking at] the hypervisor.
Intel has great engineers, great Linux devs and, according to meltdown paper this bug was disclosed to Intel 6 months ago.
Intel also had enough time to be prepared for the shit storm coming.
I bet 10 dogecoin in Linus.
What's that, like one millionth of a bitcoin, except actually transactable?
Agreed. I haven't looked much into x86 virtualization opcodes but it seems clear x86 virtualization in general is basically CPU based separation. As far as speculating about impacts goes i'd just assume it's not possible for virtualization to stop the bug from happening. Can it be used to read host memory? I would'nt be suprised. I mean why not? if you can seemingly read arbitrary data from the cache why wouldn't you be able to at least expose random bytes and if you happen to find a way to control/predict what's there, well bingo. Concerning timing problems on busy nodes i wouldn't say those make the exploit generally ineffective. Probably way harder to sucessfuly pull off but that's not really how security works.
The problem is that the cpu is usually not virtualized. Note the "exceptions" hint I mentioned. That's one of the ways a hypervisor can know about break-out attempts and block them.
Also keep in mind what I wrote about hardware x86 emulation; looking at that one will easily understand that no provider will run virtualized cpus (and very few customers would buy those).
What cpu virtualization actually means (in real life) is more or less direct control mechanisms plus, importantly, whether a hypervisor really is just that or whether it is just a kernel module.
@WSS I read linus rant and found it funny and stupid.
For a start intel has quite a few engineers who have more brain cells in their ass than linus has in his head. But the interesting point is one that I just mentioned above and that linus seems to completely miss: intel is condemned to carry lots and lots of old shit from cpu generation to cpu generation.
People should understand what processor design at intel actually is: it's a process of squeezing out a bit more performance by twiddling with small details. Plus, there are of course plenty big parties like xen, kvm, large corps, microsoft, etc. adding to a never ending wish/todo list.
The problem is that an x86 cpu is an insanely complex structure with many sub-blocks like, for instance, cache management that are insanely complex themselves - and all of that based on a basic design from many decades ago. Plus, the world today is very different from yester-decades; we have whole classes of attacks of which no-fucking-body even nightmare dreamed some decades ago - and hence intel did never design accordingly. In other words, an intel processor can't possibly be anything but a more or less stable hodgepodge conglomerate.
That one - incl. intel - can build much better processors has been demonstrated amply. But intels game is a different one, it's basically called "how to build a 386 in the 21st century - and well noted, a 386 supporting 64 bits, virtualization, 3 cache levels, etc.". I really don't like intel (and was pleased to buy a ryzen) but we should be a little fair here.
No one runs a hypervisor that works like that though. The performance cost would be one or two orders of magnitude higher than the cost of using this kernel page table isolation. Hypervisors run VM code natively, either using kernel features like namespaces and cgroups or hardware virtualization features like extended page tables to isolate guests (and, in the latter case, to nest the guest kernel).
Edit: BTW these hardware virtualization features are merely an extension of hardware features that allow processes to be isolated from one another. For this, CPUs include a CPU mode flag in their state, which can either be set to "kernel mode" or "user mode"; certain instructions are not allowed (by the hardware) in user mode. To perform privileged actions like disk I/O, the traditional idea is that a userland application would execute a special instruction that triggers an exception, which causes the hardware to jump to a predetermined position in the kernel code that handles the exception. The kernel code then performs an action based on the parameters of the special instruction that the application attempted to execute. Once the action is done, the kernel can jump back to the application, making sure to set the CPU mode to user mode before jumping. This is a "system call"! Of course modern CPUs are more complex than this simple view.
Edit2: if you didn't understand that but are interested in learning more, people have written stuff that is more clear, I think http://www.tldp.org/LDP/khg/HyperNews/get/syscall/syscall86.html is a good document. Also https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-004-computation-structures-spring-2009/lecture-notes/MIT6_004s09_lec18.pdf (note that here the slides actually refer to a process as a "virtual machine"; this is because what we think of as a VM is basically a process, but with additional features to allow nesting of a kernel among other things)
Ugh. If that means what i think it means this could turn very very nasty.
Sorry to convey bad news but: It does. And worse.
Oh, btw, before I forget it again: This vulnerability is known since more than half a year.
But it has reached hype and very serious concerns level only now. Why? I guess the answer is very ugly and frightening.
Thanks for folks here sharing their knowledge, particularly @bsdguy. Good thread.
Whatever the solution, it's immense to think how big the scope of this problem is.
As a strand of this thread has considered, hopefully the outcome doesn't fuck up too many provider's bottom lines with the seemingly inevitable perf hit.
https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
...
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
...
So Google apparently got pissed at Intel's statement that these issues are not a big deal and just broke the embargo releasing info on these exploits.
Meltdown: affects every Intel CPU since 1995 (save for certain Itaniums and first Atoms). Possible to fix with software patches but with a performance penalty.
Spectre: according to official info - this is virtually impossible to fix in full:
...
https://meltdownattack.com/
....****
Docker, OpenVZ are all at risk.
Ha, that is the exact way of putting it, no wonder ARM makes them much more efficient, because they dont have to design the car to be compatible with a steam engine too.
Can use kvm64 and the fact intel makes the CPUs backward compatible, you can select a CPU of older design and it will still run pretty much at the same speed as the host version. Only the extra instructions will be emulated and most of those are not used anyway.
TL;DR-in KVM select a CPU without out of order features and you are safe without applying any patch, at least in theory.
I can also assume KVM can implement a filter so the necessary instructions to trigger this bug will not pass or be emulated and filtered only, effectively filtering out this and possible future attacks at a much smaller performance cost, still keeping the out of order benefits of the older cpus without applying the updates.
Intel promised they will fix this issue n the future if i read that announcement correctly, and it seems they have already microcode updates and others will be made available in time. I bet this CAN be fixed in microcode, at least using some undocumented features and calls, or simply bugs or unintended behaviour as us, the older people, were used to at some point in our earlier lives. When you are under severe constraints and pressure, you really become creative. They can, at least, disable out of order features or altogether, so I do not think this can only be fixed in software, but the software can cooperate to make the performance loses more benign.
I very much doubt this will be required, though, microcode updates will be made available, the original reports sound much like:
" there is this virus which fucks you and leaves you pregnant, there is no way the antivirus can catch it, so better send this to 100 more tech sites you know of."
That announcement shows the whole industry gets together to treat the out-of-order issue in a standardized way, albeit I am sure it wont last. This is how they are doing PR primarily.
And a few people were speculating way back in 2016, maybe older than that, that this kind of nasty vulnerability existed in branch prediction / speculative execution.
I don't think out of order execution something you can select at the virtualization level. It's how the host cpu handles the virtualized instructions and you can't control that. What you control is really just the set of opcodes the virtualized cpu is allowed to run. So unless you emulate the virtualized CPU there is nothing to gain here and if you ever had the misfortune of having to run anything serious on an emulated CPU you'd know why this isn't really an option.