Hacker News Reader

Comment by inetknght | Hacker News Reader

> 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.

View on HN

Being able to steal secrets -- passwords, bank account information, ephemeral encryption keys to other sites -- is absolutely very significant to single-user computers.

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.

The very definition of security through obscurity. As long as you’re obscure enough for no one to care, you’re safe.

I agree that most attackers aren't going to use this attack, but only because privesc through standard means is well documented and researched. It wouldn't make sense to weaponize this sort of attack while the existing attacks continue to work.

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.

There was never a real world exploit that did anything like that. They were all POCs that read data from themselves under ideal conditions.

That’s because mitigations were rolled out very quickly.

True, though I find it hard to believe there are still no real world exploits.

There might be! But I haven’t heard of anything publicly yet.

There is very little incentive for victims OR assailants to let anyone know if it has.

Say that were true - you knew all of the valued zero-days, attacks, etc - and determined nothing happened yet

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.

I feel that exfiltrating memory at a few hundred bytes/sec makes it extremely impractical. You'll be looking for a needle in a haystack. There are easier, faster attacks available. I won't lose sleep over it.

> I feel that exfiltrating memory at a few hundred bytes/sec makes it extremely impractical. You'll be looking for a needle in a haystack.

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.

If you can directly de-reference kernel memory, sure. If you have that capability, why do you need this exploit? I'm still skeptical.

Haha, speaking of Linus’s carefree attitude towards leaving dangerous things unattended because they are not imminently threatening”, this is an opportune moment to point out that AMD has a series of unpatched vulnerabilities (Take-A-Way and PREFETCH, both by Moritz Lipp of Spectre/Meltdown fame) that leak kernel page table mappings as well, unless you enable KPTI, which AMD continues to push as off-by-default due to performance impact.

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.

Suppose you know that data of interest is at address X. Now how do you propose actually reading that specific address from e.g. JS running in a browser? IMHO having that much knowledge of the system you're attacking means you're not likely to need the side-channel anyway.

It's just like traditional kernel exploitation. Say you have a classic relative kernel read due to an out of bounds read from a heap object. How do you read secrets that way? Well, you leak the ASLR slide, find a relevant global, and start pointer chasing until you reach the object you want. Doing this with speculative reads is just the same as with a regular kernel bug except that now it's slow. Like, legitimately, there are some off the shelf kernel exploitation kits that let you swap in an implementation for read functions and then they'll work straight away whether or not the read is coming from speculative means or a classic bug.

That assumes you have direct control over which addresses you can read, which is far from true in the scenario of most concern (JS running in the browser). It is at best like listening to the conversation of some people walking by, with a ton of background noise, and hoping you'll hear enough to make sense of it.

I won't either to be honest. These are certainly of the 'stars must align' category [today], I just find them interesting.

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

>I feel that exfiltrating memory at a few hundred bytes/sec makes it extremely impractical.

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.

Having access to a PCI bus is a bit different than what we're talking about here. Explain to me how are you going to "quickly" walk a page table or other known data structure if you don't have direct control over what you can read?

Their paper states "RETBLEED can leak arbitrary kernel data from an unprivileged process with all the mitigations up on various Intel and AMD systems." They control the branch target buffer so can point to whatever they want.

It's still not going to be quick!

Do you have experience in this? I do. What fraction of memory samples do you estimate you'd need to find structures of interest?

Not much! I've played around with the exploits / POC code posted on github.

High-value zero days like what you're describing would not get wasted on stealing bank information from random working schlubs like us.

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.

Oh, definitely - it wouldn't be used for trivial things like that, at least not for quite a while.

[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.

> High-value zero days like what you're describing would not get wasted on stealing bank information from random working schlubs like us.

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.

The people wanting to make it practical certainly won't use something as crude and slow as Spectre or Meltdown or this. They just own your entire system.

> Dismissing it without consideration for mitigations is malicious IMO.

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 :)

It seems disabling JIT on JS VM and only using slow interpreted mode is a good choice.

Also in this case memory consumption will be lower because JIT'ed code takes space. I think that it is a good idea.

Has anyone produced meaningful benchmarks on real world websites? If I go to arstechnica, or NYTimes, or gmail — what will the difference be between JIT and non-JIT for page load and common operations?

Edge did some benchmarks with their "Super Duper Secure Mode" and found that disabling JIT improves performance more often than not: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

> and found that disabling JIT improves performance more often than not

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?

is it possible to disable JIT on chrome or Firefox?

I found this blog post for chrome/FF: https://lemmy.eus/post/7660

And Edge has so-called "Super Duper Secure Mode": https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

Edge's newer "Enhanced Security"[1] toggles are essentially that, disabling JIT and WebAssembly (alongside other features) on sites you don't frequent. "Strict" disables them on all sites.

1: https://support.microsoft.com/en-us/microsoft-edge/enhance-y...

On the V8 teram we had a POC of forcing mispredicted instruction sequences in the interpreter that leaked data. Reorder buffers are 200-600 instructions these days, and indirect branch predictors needed to speculate through bytecode sequences are good enough that an interpreter is not safe.

That's why you disable JavaScript: we scrutinize downloaded exe files carefully and have virusscanners running all the time while allowing untrusted JavaScript to reach your CPU. As long as there is no effectieve way to tell trusted and untrusted JavaScript apart, having it enabled is silly.

>The original attacks worked in javascript that could be delivered by a browser to your single-user PC

no they didnt, otherwise there would be a demo page you could use right now to check if you are susceptible

Yes they did. Here is one such demo: https://leaky.page/

I have never patched even once 2018 install of win10 running chrome on intel Haswell, this demo fails to do anything.

Out of curiosity is it also using a circa-2018 chrome install? There have been mitigations pushed to Chrome and V8.

June build Chrome/102.xxx. I just tried 96.xx and

[!] 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.

Wasm is trivially accessible from JavaScript, so it's not unreasonable to conflate the two, even if its technically incorrect. Wasm also can't do anything that JS couldn't already do; it's simply more convenient in many cases (and maybe somewhat faster at runtime) to write code in C/C++/Rust/whatever and compile it to Wasm than to write the code in JS. You could (and still can) compile these languages to asm.js instead, in which case the code would actually be JS, albeit a particularly weird dialect.

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).

So are we in agreement that there doesnt exist a _working_ javascript demo/exploit for any of the Spectre attacks?

I can't speak to what that error is but Chrome 96 appears to be from Nov '21 at the earliest which would include a large number of these mitigations.

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.

Browsers have since added their own mitigations. Chrome has certainly come up with their own set of mitigations [0].

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.

[0]: https://developer.chrome.com/blog/meltdown-spectre/

some games have anti-cheat softeare that runs in admin mode 24/7

Like, super mega admin mode -- many run in the kernel nowadays!

Games don’t run in a sandbox, they can already access all user data as is.

Mods might be sandboxed though - for instance by only allowing mods via a built in script interpreter.

That specific PoC page relied on performance.now() https://github.com/google/security-research-pocs/blob/d10780...

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.

In March 2021 Google released proof of concept for something patched since 4 years?

The associated March 2021 blog post mentioned implementing multiple PoCs abusing different timers; the one chosen was verified "on Chrome 88 on an Intel Skylake CPU", which was released January 2021.

A cursory search did not find what further mitigations have been implemented since 2021.

So in the end it turns out there doesnt exist "a demo page you could use right now to check if you are susceptible" after all because browsers removed attack surface (precise timers).

> So in the end it turns out there doesnt exist "a demo page you could use right now to check if you are susceptible" after all because browsers removed attack surface

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

The linked page is not js, its js deferring actual attack to wasm. It doesnt work on 2018 system despite the demo being released in 2021.

Your browser will run WebAssembly about as happily as it will run JavaScript. What's the distinction here?

    delete WebAssembly

uBlock can inject this to every webpage you visit. The distinction is you can disable WebAssembly and >99.99% of the web will run like nothing happened.

Reply on news.ycombinator.com