6 ms·

Or people could just understand the scope of the issue better, and realize that just because something has a vulnerability doesn't mean there is a direct line t

Or people could just understand the scope of the issue better, and realize that just because something has a vulnerability doesn't mean there is a direct line to an attack. In the case of speculative execution, you need an insane amount of prep to use that exploit to actually do something. The only real way this could ever be used is if you have direct access to the computer where you can run low level code. Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets. And in the case of systems that are valuable enough to exploit with a risk of a dedicated private or state funded group doing the necessary research and targeting, there should be a system that doesn't allow unauthorized arbitrary code to run in the first place. I personally disable all the mitigations because performance boost is actually noticeable.

vlovich123 1y ago
> Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets That's precisely what Spectre and Meltdown were though. It's unclear whether this attack would work in modern browsers but they did reenable SharedArrayBuffer & it's unclear if the existing mitigations for Spectre/Meltdown stimy this attack. > I personally disable all the mitigations because performance boost is actually noticeable. Congratulations, you are probably susceptible to JS code reading crypto keys on your machine.
- nine_k 1y ago
  Disabling some mitigations makes sense for an internal box that does not run arbitrary code from the internet, like a build server, or a load balancer, or maybe even a stateless API-serving box, as long as it's not a VM on a physical machine shared with other tenants.
  - anyfoo 1y ago
    You run "arbitrary code from the internet" as soon as you use a web browser with JS enabled.
    - dwattttt 1y ago
      Or with JS disabled. HTML isn't as expressive, but it's still "arbitrary code from the internet"
      - anyfoo 1y ago
        There is a difference. JS is turing complete, pure HTML is far from (as far as I'm aware). So HTML might (!) well be restricted enough to not be able to carry out such an attack. But I'd never state to definitively, as I don't know enough about what HTML without JS can do these days. For all I know there's a turing tarpit in there somewhere...
        nine_k 1y ago
        CSS3 is Turing-complete, but creating an exploit using just it would be... quite a feat. With JS or WASM, it's much more straightforward.
      - vlovich123 1y ago
        HTML doesn’t have the potential to deliver Spectre like attacks because: 1. No timers - timers are generally a required gadget & often they need to be hires or building a suitable timing gadget gets harder & your bandwidth of the attack goes down 2. No loops - you have to do timing stuff in a loop to exploit bugs in the predictor.
    - baobun 1y ago
      Which you wouldn't do on an internal load balancer or database server, right?
      - anyfoo 1y ago
        You are right, I sort of misread the statement I was replying to, but also wanted to reinforce that the large class of personal desktop machines is still very much affected, even if you "think" that you don't run "arbitrary code" on your machine. By the way, you have to be careful on your database server to not actually run arbitrary code as well. If your database supports stored procedures (think PL/SQL), that qualifies, if the clients that are able to create the stored procedures are not supposed to be able to access all data on that server anyway.
- gblargg 1y ago
  Who these days would trust crypto keys on their machine, given the many hardware wallets available?
  - vlovich123 1y ago
    Where do you think the crypto keys for the TLS connection securing your HTTPS browsing are stored? Although from what you said I’m now thinking you’re referring to cryptocurrency & thus aren’t on the same wavelength of the discussion here. Crypto keys —> cryptography keys, not cryptocurrency keys.
  - ActorNightly 1y ago
    I think he means crypto as in like tokens, not wallet keys.
- ActorNightly 1y ago
  >Congratulations, you are probably susceptible to JS code reading crypto keys on your machine. No wonder you guys are scared AI is going to take your job lol. Thats not how it works at all. To grab a key stored in a JS variable, the following would need to happen 1. Attacker needs to find a way to inject arbitrary JS code in a website, which means controlling either an iframe that is loaded or some component. This is a pretty hard thing to do these days with Same-Site strictness 2. The code needs to know specifically what memory address to target. When things like JWT or other tokens are stored in session or local storage, the variable name usually contains a random string. Injected code will have to figure out a way to find what that variable name is. 3. For attack to work, the cache has to get evicted. This is highly processor specific on how well it works, and also, the web app has to be in a state where no other process is referencing that variable. With JS, you also have to infer memory layout (https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html https://security.googleblog.com/2021/03/a-spectre-proof-of-c...) first, which takes time. Then you have to train the branch predictor, which also takes time. So basically, I have a statistically higher chance of losing my keys to someone who physically robs me rather than a cache timing attack. Generally when an exploit like this drops, people always have failures to update their systems, and you see it being used in the wild. With Spectre/Meltdown, this didn't really happen, because of the nature of how these attacks work and the difficulty of getting the cache timing code to work correctly without specific targeting of a processor and ability to execute arbitrary code on the machine.
  - anyfoo 1y ago
    This seems to theorize an attack where you are interested in particularly data of the particularly visited website, and at the same time assuming that the attack would have to be carried out on the same website. The vulnerability however allows arbitrary reading of any memory in the system in at least some circumstances, the presented PoC (https://www.youtube.com/watch?v=jrsOvaN7PaA https://www.youtube.com/watch?v=jrsOvaN7PaA ) demonstrates this by literally searching memory for the system's /etc/shadow and dumping that. Whether the attack is practical using JS instead of a compiled C program is unknown to me, but if it is, it's not clear to me why the attacker would need to inject JS code into other websites or know what addresses to target. (If it is not, the question is moot.)
anyfoo 1y ago
> Or people could just understand the scope of the issue better Do you understand the scope of the issue? Do you know that this couldn't personally affect you in a dragnet (so, not targeted, but spread out, think opportunistic ransomware) attack? Because this statement of yours: > Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets. was not true for Spectre. The original spectre paper notoriously mentions JS as an attack vector. If you truly disable all mitigations (assuming CPU and OS allow you to do so), you will reopen that hole. So: > The only real way this could ever be used is if you have direct access to the computer where you can run low level code. I'm a low level kernel engineer, and I don't know this to be true in the general case. JITs, i.e. the JavaScript ones, also generate "low level code". How do you know of this not being sufficient?
- ActorNightly 1y ago
  >Do you understand the scope of the issue? Do you know that this couldn't personally affect you in a dragnet The issue is not whether or not it could affect me, the issue is what is the risk. And I can say for certain that the risk is very low, because I seem to have more understanding of the space. >The original spectre paper notoriously mentions JS as an attack vector. In an analogy, having an attack vector is having a certain type of weapon, while executing a full exploit end to end is on the scope of waging a war. Sure, a right person at the right place with that weapon can take out a critical target and win the war, but just having that weapon doesn't guarantee you winning a war. In the cases of certain exploits, like Log4Shell, thats like having a portable shotgun that shoots hypersonic missiles in a scatter pattern. Log4Shell basically means that if anything gets logged, even an error message, that can be used to execute arbitrary code, and its super easy to check if this is the case - send payloads to all services with a JNI url that you control and see what pops up, and boom, you can have shells on those computers. In the case of Spectre/Meltdown, its like having a specific type of booby trap. Whether or not you can actually set up that booby trap highly depends on environment. If a website is fully protected against code injection, then executing JS cache timing would be impossible. And even if it wasn't, there would be other Of course nothing is ever for certain. For example, browsers can contain some crazy logic bug that bypasses Same-Origin checks that nobody has found yet. But the chance of this happening is extremely low, as browser code is public.

vlovich123 1y ago

> Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets That's precisely what Spectre and Meltdown were though. It's unclear whether this attack would work in modern browsers but they did reenable SharedArrayBuffer & it's unclear if the existing mitigations for Spectre/Meltdown stimy this attack. > I personally disable all the mitigations because performance boost is actually noticeable. Congratulations, you are probably susceptible to JS code reading crypto keys on your machine.

nine_k 1y ago
Disabling some mitigations makes sense for an internal box that does not run arbitrary code from the internet, like a build server, or a load balancer, or maybe even a stateless API-serving box, as long as it's not a VM on a physical machine shared with other tenants.
- anyfoo 1y ago
  You run "arbitrary code from the internet" as soon as you use a web browser with JS enabled.
  - dwattttt 1y ago
    Or with JS disabled. HTML isn't as expressive, but it's still "arbitrary code from the internet"
    - anyfoo 1y ago
      There is a difference. JS is turing complete, pure HTML is far from (as far as I'm aware). So HTML might (!) well be restricted enough to not be able to carry out such an attack. But I'd never state to definitively, as I don't know enough about what HTML without JS can do these days. For all I know there's a turing tarpit in there somewhere...
      - nine_k 1y ago
        CSS3 is Turing-complete, but creating an exploit using just it would be... quite a feat. With JS or WASM, it's much more straightforward.
    - vlovich123 1y ago
      HTML doesn’t have the potential to deliver Spectre like attacks because: 1. No timers - timers are generally a required gadget & often they need to be hires or building a suitable timing gadget gets harder & your bandwidth of the attack goes down 2. No loops - you have to do timing stuff in a loop to exploit bugs in the predictor.
  - baobun 1y ago
    Which you wouldn't do on an internal load balancer or database server, right?
    - anyfoo 1y ago
      You are right, I sort of misread the statement I was replying to, but also wanted to reinforce that the large class of personal desktop machines is still very much affected, even if you "think" that you don't run "arbitrary code" on your machine. By the way, you have to be careful on your database server to not actually run arbitrary code as well. If your database supports stored procedures (think PL/SQL), that qualifies, if the clients that are able to create the stored procedures are not supposed to be able to access all data on that server anyway.
gblargg 1y ago
Who these days would trust crypto keys on their machine, given the many hardware wallets available?
- vlovich123 1y ago
  Where do you think the crypto keys for the TLS connection securing your HTTPS browsing are stored? Although from what you said I’m now thinking you’re referring to cryptocurrency & thus aren’t on the same wavelength of the discussion here. Crypto keys —> cryptography keys, not cryptocurrency keys.
- ActorNightly 1y ago
  I think he means crypto as in like tokens, not wallet keys.
ActorNightly 1y ago
>Congratulations, you are probably susceptible to JS code reading crypto keys on your machine. No wonder you guys are scared AI is going to take your job lol. Thats not how it works at all. To grab a key stored in a JS variable, the following would need to happen 1. Attacker needs to find a way to inject arbitrary JS code in a website, which means controlling either an iframe that is loaded or some component. This is a pretty hard thing to do these days with Same-Site strictness 2. The code needs to know specifically what memory address to target. When things like JWT or other tokens are stored in session or local storage, the variable name usually contains a random string. Injected code will have to figure out a way to find what that variable name is. 3. For attack to work, the cache has to get evicted. This is highly processor specific on how well it works, and also, the web app has to be in a state where no other process is referencing that variable. With JS, you also have to infer memory layout (https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html https://security.googleblog.com/2021/03/a-spectre-proof-of-c...) first, which takes time. Then you have to train the branch predictor, which also takes time. So basically, I have a statistically higher chance of losing my keys to someone who physically robs me rather than a cache timing attack. Generally when an exploit like this drops, people always have failures to update their systems, and you see it being used in the wild. With Spectre/Meltdown, this didn't really happen, because of the nature of how these attacks work and the difficulty of getting the cache timing code to work correctly without specific targeting of a processor and ability to execute arbitrary code on the machine.
- anyfoo 1y ago
  This seems to theorize an attack where you are interested in particularly data of the particularly visited website, and at the same time assuming that the attack would have to be carried out on the same website. The vulnerability however allows arbitrary reading of any memory in the system in at least some circumstances, the presented PoC (https://www.youtube.com/watch?v=jrsOvaN7PaA https://www.youtube.com/watch?v=jrsOvaN7PaA ) demonstrates this by literally searching memory for the system's /etc/shadow and dumping that. Whether the attack is practical using JS instead of a compiled C program is unknown to me, but if it is, it's not clear to me why the attacker would need to inject JS code into other websites or know what addresses to target. (If it is not, the question is moot.)

anyfoo 1y ago

> Or people could just understand the scope of the issue better Do you understand the scope of the issue? Do you know that this couldn't personally affect you in a dragnet (so, not targeted, but spread out, think opportunistic ransomware) attack? Because this statement of yours: > Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets. was not true for Spectre. The original spectre paper notoriously mentions JS as an attack vector. If you truly disable all mitigations (assuming CPU and OS allow you to do so), you will reopen that hole. So: > The only real way this could ever be used is if you have direct access to the computer where you can run low level code. I'm a low level kernel engineer, and I don't know this to be true in the general case. JITs, i.e. the JavaScript ones, also generate "low level code". How do you know of this not being sufficient?

ActorNightly 1y ago
>Do you understand the scope of the issue? Do you know that this couldn't personally affect you in a dragnet The issue is not whether or not it could affect me, the issue is what is the risk. And I can say for certain that the risk is very low, because I seem to have more understanding of the space. >The original spectre paper notoriously mentions JS as an attack vector. In an analogy, having an attack vector is having a certain type of weapon, while executing a full exploit end to end is on the scope of waging a war. Sure, a right person at the right place with that weapon can take out a critical target and win the war, but just having that weapon doesn't guarantee you winning a war. In the cases of certain exploits, like Log4Shell, thats like having a portable shotgun that shoots hypersonic missiles in a scatter pattern. Log4Shell basically means that if anything gets logged, even an error message, that can be used to execute arbitrary code, and its super easy to check if this is the case - send payloads to all services with a JNI url that you control and see what pops up, and boom, you can have shells on those computers. In the case of Spectre/Meltdown, its like having a specific type of booby trap. Whether or not you can actually set up that booby trap highly depends on environment. If a website is fully protected against code injection, then executing JS cache timing would be impossible. And even if it wasn't, there would be other Of course nothing is ever for certain. For example, browsers can contain some crazy logic bug that bypasses Same-Origin checks that nobody has found yet. But the chance of this happening is extremely low, as browser code is public.