Don’t forget these!
oh gawd, the cutesy branded names and PR that accompanies each vuln now as each security company tries to promote itself.
Depending on how well the attacker’s timing is it can be. If it can successfully dump the memory containing the HTTP request string you are trying to send to your bank with the value you entered then they can pretty easily identify the form values and pull them out themselves.
I predict this will more likely be used on servers though, as if you can infiltrate someone’s server (even under a heavily restricted area) you can then have free rain to hammer memory and try and find private keys, http headers, and other large blocks of fairly identifiable information.
It looks to me like some of the Spectre variants in their paper (potentially on all CPUs) could read a browser’s memory to grab cookies, security tokens, passwords, etc. if they’re sitting in RAM unencrypted. Unlike the kernel memory space vulnerabilities, this doesn’t seem OS-patchable. This also appears to be potentially possible from JS from inside of a browser’s execution sandbox. Does this seem incorrect to anyone else’s read?
Correct, from the Spectre paper:
Attacks using JavaScript. In addition to violating process
isolation boundaries using native code, Spectre attacks
can also be used to violate browser sandboxing, by
mounting them via portable JavaScript code. We wrote a
JavaScript program that successfully reads data from the
address space of the browser process running it.
Also Chrome is doing a v8 release on January 23rd that will affect performance of javascript for Spectre mitigation.
Edit: Also From Azure:
https://azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vulnerability/
“The majority of Azure customers should not see a noticeable performance impact with this update. We’ve worked to optimize the CPU and disk I/O path and are not seeing noticeable performance impact after the fix has been applied. A small set of customers may experience some networking performance impact. This can be addressed by turning on Azure Accelerated Networking (Windows, Linux), which is a free capability available to all Azure customers.”
The slowdown isn’t across the board, it is dependent on the amount of syscalls taking place
The irony about Spectre is that browser makers have been trying to optimize JavaScript performance ever since JavaScript was developed, and now they’re all trying to slow it down.
They’re not trying to slow it down - they’re making timing less precise on the userlevel. JIT is working fine as always, and the mitigation won’t make general Javascript code slower.
I wonder if there is a WebAssembly proof-of-concept somewhere. That could be really interesting.
Google says in their own security advisory that their mitigations may affect performance.
Sounds like a slow down to me.
may is the key point there. Code that doesn’t need precise timing and doesn’t use shared arrays (which means the vast majority of javascript code in websites and all) won’t be affected.
I read the Google advisory and it seems they’ll change the way their JIT works in V8 to reduce the chance of speculative execution, so yes, it might affect other kinds of code indeed, at least for some time. I expect them to find other ways to optimize execution though, so I don’t think the impact would be massive or very noticeable in most cases.
Maybe Qualcomm Snapdragon will pull ahead now.
Interesting, interesting. I read the white papers which cleared up a lot of things. The Meltdown class of attacks isn’t much of an issue for my company for various reasons except for a couple of isolated cases from a couple of vendors that all claim they are patched already. So non event, yay.
The Spectre class is more interesting, especially since they have a Javascript proof of concept, but it relies heavily on timing attacks. Which Chrome knows about and obfuscates but they found a work around with web workers to create a stable timer. So… ouch.
Reading through Meltdown just made me sympathize with the Intel optimization team. I mean I don’t think it’s possible to really secure userspace vs system/hypervisor. At least that’s the viewpoint I take, from a safety standpoint whenever possible.
This paper has some details on the possible “alternate timing” techniques. There are some really clever ones there.
In this paper, we demonstrate that reducing the resolution of timing information or even removing these interfaces is completely insufficient as an attack mitigation.
Yeah, Ouch pretty much covers it. Obfuscating timers isn’t really a solution according to them and I believe it. Anytime the word ‘Obfuscate’ is used in security you should translate that to ‘delightfully challenge but not stop’ the hackers.
Gaming perf (on linux, at least) is unaffected. Though since this affects syscalls, I would think load times would go up a bit.
https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests
Yeah. Most games load code and assets into user space and run from there.
Games that require a lot of streaming assets and already tax the CPU might see an impact.
Why the hell are they rolling this Windows patch out so slowly? Windows Update still claims I’m up to date, even though my last update was in mid-December.