71–80 of 145 posts
Earlier quoted context omitted.
> It’s a total non issue for the majority of folks People said the _exact_ same thing about Spectre/Meltdown. Then the JS PoCs came out
Isn't the lesson here that scripting in the browser needs to die. Letting untrusted code run on your computer is always a bad idea, no matter how much you try to sandbox it.
Earlier quoted context omitted.
But the problem is not OpenSSL, it's that malicious code on the system can read the keys OpenSSL is using. If you don't run malicious code on the same system as OpenSSL, this attack goes away - there's no way to run a CPU timing attack from a different network.
From what I understand, the problem is that algorithms which should be constant time are actually taking a variable amount of time depending on the data. If I have some server software whose security depends on those constant-time algorithms actually being constant time, why shouldn't this be exploitable over the network?
> The GoFetch attack is based on a CPU feature called data memory-dependent prefetcher (DMP), which is present in the latest Apple processors. We reverse-engineered DMPs on Apple m-series CPUs and found that the DMP activates (and attempts to dereference) data loaded from memory that "looks like" a pointer. This explicitly violates a requirement of the constant-time programming paradigm, which forbids mixing data and memory access patterns.
> To exploit the DMP, we craft chosen inputs to cryptographic operations, in a way where pointer-like values only appear if we have correctly guessed some bits of the secret key. We verify these guesses by monitoring whether the DMP performs a dereference through cache-timing analysis. Once we make a correct guess, we proceed to guess the next batch of key bits. Using this approach, we show end-to-end key extraction attacks on popular constant-time implementations of classical (OpenSSL Diffie-Hellman Key Exchange, Go RSA decryption) and post-quantum cryptography (CRYSTALS-Kyber and CRYSTALS-Dilithium).
It sounds like the OpenSSL code is still constant time (it doesn't expect pointers in the intermediate values, to OpenSSL it is just data, not something it will ever dereference) but the attacker-controlled "monitoring" code's runtime changes based on whether the DMP ran or not.
If that's right, then the attacker still needs to run their monitoring code on the target, it isn't sufficient to just run OpenSSL etc itself.
Edit: it is more explicit in the paper, they assume that OpenSSL (the victim) is still constant time:
> In this paper we assume a typical microarchitectural attack scenario, where the victim and attacker have two different processes co-located on the same machine.
> For our cryptographic attacks, we assume the attacker runs unprivileged code and is able to interact with the victim via nominal software interfaces, triggering it to perform private key operations. Next, we assume that the victim is constant-time software that does not exhibit any (known) microarchitectural side-channel leakage. Finally, we assume that the attacker and the victim do not share memory, but that the attacker can monitor any microarchitectural side channels available to it, e.g., cache latency.
Earlier quoted context omitted.
As opposed to what else? Please elaborate.
Using multiple devices: Credit cards for payment, instead og apple pay. A camera for taking pictures, instead of a camera app, a notebook to write notes, instead of an app. From my perspective the original comment is not rocket science?
If you require someone to enter their credit card number every time they make a purchase they end up doing dumb, insecure things like storing it as a text file on their desktop.
And having external hardware just means more cables, batteries, updates to keep it secure etc.
Initiatives like PassKey, ApplePay, TouchID etc. have been a huge win for security and privacy.
> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?
My personal opinion is that we should solve it the opposite way - don't run untrusted code in the first place (with rare exceptions like dedicating an entire cpu core and a region of memory to a virtual machine, etc). Speculation is one of many side channel attacks, who knows what kind of crazy RF-based exploits are out there. AFAIK we still haven't fully solved rowhammer. I think for "normal" users the main risk is…
Earlier quoted context omitted.
This isn't speculative execution. EDIT: The downvotes make no sense. What this bug has in common with Spectre is that it has to do with cache timing. But in Spectre, the cache is affected by speculative execution; with "GoFetch", it's the pre-fetcher pre-fetching things which look like memory addresses. Pre-fetching is not speculative execution.
Unless the comment was edited, the person you are responded to did not use the phrase "speculative execution"
But if they did mean to include pre-fetching in "speculation" then I retract my comment
Earlier quoted context omitted.
> It’s a total non issue for the majority of folks People said the _exact_ same thing about Spectre/Meltdown. Then the JS PoCs came out
Isn't the lesson here that scripting in the browser needs to die. Letting untrusted code run on your computer is always a bad idea, no matter how much you try to sandbox it.
If people knew just how widespread and effective browser fingerprinting is they would be shocked. It's Cambridge Analytica on steroids.
Security through obscurity is really a bad idea, and Apple is no exception. In the long run, this will likely drive the adoption of RiscV as a better alternative.
If I add a custom crypto extension to a RISC-V core and implement it badly, is that the fault of RISC-V? No! It's my own. And RISC-V doesn't help anyone here because their license allows me to keep my extension completely closed source - no different than Apple is today with ARM.
Another day, another speculative execution vuln.. IMHO: all this speculation is a local maximum and it show we have fundamental issue with how we design 'computers'
It's security vs. speed. Can't have both. It's a bit like security vs. convenience.