Presumably under very ideal conditions? I've been indifferent to all these sidechannel attacks since the original Spectre/Meltdown and continue to maintain my opinion that this is really not of any significance to a single-user PC.
The original attacks worked in javascript that could be delivered by a browser to your single-user PC. Being able to steal secrets -- passwords, bank account information, ephemeral encryption keys to other sites -- is absolutely very significant to single-user computers.
Dismissing it without consideration for mitigations is malicious IMO.
Well, kind of...
>> We find that disabling the JIT does not always have negative impacts. Our tests that measured improvements in power showed 15% improvement on average and our regressions showed around 11% increase in power consumption. Memory is also a mixed story with negatively impacted tests showing a 2.3% regression, but a larger gain on the tests that showed improvements. Page Load times show the most severe decrease with tests that show regressions averaging around 17%. Startup times, however, have only a positive impact and no regressions.
Most people are going to care about page load times more than anything else by far, and that's the one that quite clearly took a hit without JIT. It's great that no JIT makes Edge open faster, but how many times a day do you have to quit and restart your browser?
And Edge has so-called "Super Duper Secure Mode": https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
1: https://support.microsoft.com/en-us/microsoft-edge/enhance-y...
no they didnt, otherwise there would be a demo page you could use right now to check if you are susceptible
[!] error: could not infer memory layout [] retrying. (2 retries left) [!] error: could not infer memory layout [] retrying. (1 retries left) [!] error: could not infer memory layout [!] no retries left
Btw some parts (maybe whole thing??) uses WebAssembly and not just js.
The site pretty clearly says it works on Chrome 88, on Linux. Chrome 91 reduced the resolution of performance.now significantly, which likely broke this website (https://developer.chrome.com/blog/cross-origin-isolated-hr-t...). You're also trying this out on Windows, which is also not supported by the demo page in its default configuration.
But also: this was a demo page put together by a random security researcher on their own, based on a vulnerability from a year ago. It's not a reflection of what a motivated attacker could do with a sufficiently powerful exploitation primitive (say, this Retbleed attack).
w.r.t. js vs web asm: I could be wrong but I think V8 is the engine involved with webassembly as well so I'm not sure the wa vs js distinction matters here, but even so my main point is that there were significant software mitigations put into place in the browser. I'd expect reproducing this attack today would be difficult.
Nonetheless, a lot of hardware still remains unpatched and vulnerable. Do you install games? Do you install mods to your games? Do you fully trust every game author and mod author? Pro tip: you shouldn't; games can do it even easier. Don't do your business or finances on your gaming PC.
Chrome has limited "performance.now" to have a relatively low resolution: https://chromium-review.googlesource.com/c/chromium/src/+/85...
Also, "2018 install of win10", you might have already been patched during install. The chrome patch was Jan 2018.
Microsoft also rolled out their first specture/meltdown mitigations at the OS level in January 2018.
A cursory search did not find what further mitigations have been implemented since 2021.
The original claim you made was "[the original attacks] didn't [work in javascript], otherwise there would be a demo page".
We have shown you such a page. You are not susceptible to that original attack anymore. Congrats. Isn't that all you were asking for? How have we not proven exactly that exists?
We haven't shown you that you are still presently susceptible to anything of course, but that's not what you were claiming.
And it's of course impossible to prove that you are not susceptible to any bug whatsoever, though I don't think many people would be surprised if there were still sources of accurate timing left in the browser
delete WebAssembly
The plan for the future is... what? Pray that nobody ever makes it practical?
I'm not saying anyone should lose sleep, that's silly - but disregarding a vector because there haven't been demonstrations in the wild is also silly.
The first, and then likely a collection, will be discovered and traded on black markets. Eventually it'll leak, and then we'll know about it.
Do you seriously trust it to be like looking for a needle in a haystack? That haystack becomes much much smaller if you know where to look. An excellent adversary would know a lot about kernel memory and what data to get.
Grab a few bytes for a pointer... grab a few more bytes for another pointer offset from the first... just a few pointers and now you're at the secret storage arena. A few hundred bytes/sec is just a few hundred bytes/sec away from gaining sensitive information.
So on an AMD system you indeed know exactly where to look to get into kernel memory. The processor will just tell you where to look.
The speed comes down to time, again - either more efficient methods could be developed (perhaps in combination with other seemingly not-of-interest vulns) or simply by hardware getting even faster.
It also assumes an attacker never gets lucky, or perhaps knows something neither of us do.
I'm not sure I'd use the death/dying of Moore's Law as a mitigation strategy :P
Not at all - you don't sequentially dump all of kernel space - you probabilistically sample it and make guesses of where to look next based on the fingerprints you already have seen. It takes not long at all to find useful stuff.
Find a block that matches a known library? Ok, that entire section is known. Find a page table? Golden - you quickly walk it and you now know how everything else is laid out. Find any of zillions of known structures? Now you can walk those nicely.
I've written code to do kernel reconstruction over the PCI bus from an external security monitor - it's not hard or slow to reconstruct all of memory efficiently and without having to sample much simply by using tricks like these.
It's just like playing Battleship, except you can do it much more accurately with perfect knowledge of probabilities.
I think it is a reasonable approach to personal information security to focus on ensuring that you are robust to families of exploits which have concrete proof of concept in practice, and not wasting calories worrying about stuff that is (for the time being) mostly theoretical.
This advice obviously does not apply if you are protecting valuable corporate IP, or a repository of personal information, or god forbid national security secrets.
[Edit: hopefully having better mitigations in hardware by then]
My comment didn't follow the thread particularly well, I wasn't so much worried about the everyday person - just that this could be weaponized [against someone/thing]
My worry about this really goes as far as... keep the mitigations enabled. That's it.
A lot of people disable them today because they're aren't dangerous today - if nothing else, offering a countering opinion to change that trend.
I used to believe this was true. Then someone who had access to post tweets as very famous public figures used it to steal bitcoin.
I can tell you that someone's password is "password". There's still the question of which account uses that. Encryption keys are even less easy to use from that perspective, since they are basically random bytes otherwise. What if I told you the AES write key used to secure the TLS connection for this post is D2 B1 CD 58 26 AF 0B 56 29 AE D6 D3 5D 2D 58 96 93 5D 6D 58 26 BA 5A 5A E4 3D D5 7D 55 5C F9 EF ? Would you be able to do anything with that? You even said the keyword yourself: "ephemeral".
If I was someone who is being specifically targeted I might care, but I'm willing to bet that the vast majority of users are not, and those who are will know who they are (and something like this is probably the least of their worries.)
...which brings me back to the faulty premise of the original PoCs for these timing side-channels: they require gathering so much information about the environment beforehand, and such careful setup, that someone with that level of knowledge most likely doesn't need to use a side-channel anyway.
But otherwise you're putting way too much stock into your examples annoying attackers out of their work. I assure you, exploit developers will sit there and stare at hex dumps and put enough of those primitives together to build the exploit chain they need.
It's purely because security's such a shitshow in other ways that we don't see more attacks leveraging this sort of thing. If someone (like Jann) does enough research, puts it out there, and this becomes something that more hackers are comfortable with, they'll absolutely use this.
But this is par for the course in certain circles who put performance above security for literally decades, because performance is easy to measure (and therefore optimize!), and security isn't. It's the exact same reason we've been gaslit with FUD about needing to write all system software in unsafe languages.
Now the chickens are coming home to roost. All those corners we cut to save some memory, some time, or some money are back to haunt us--at every level of the stack.
Enjoy the meltdown :)
Some single users care if web pages, OS containers, and virtual machines can access data that is (supposed to be) forbidden to them.
But for APT groups that might need a wedge on particular machines it might be worthwhile, remember the length NSO group went with Pegasus.
Maybe? You could also assume that the attack will get faster in the future.
Sidechannel attacks like this are situationally impactful. Most desktop users don't have to care about security much at all on Linux. Further, they probably don't have to care about any privescs. But some people have threat models that change that.
But some people have threat models that change that.
Those people (a minority for sure) know who they are, but we shouldn't be crippling the performance of everyone else just for them.
I highly doubt that. Most developers, by far, could not tell you the threat model for these attacks.
> but we shouldn't be crippling the performance of everyone else just for them.
You can turn the mitigations off.
There's absolutely no excuse for the security boundaries that OSes have promised for decades, the foundation upon most everything we take for granted, should break down at a "mere" few hundred bytes a second.
I'm not saying there is. I'm saying running untrusted javascript on strange websites is not worth 15% of my CPU performance.