4 ms·

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 cp

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 JavaScript, which can (kind of) be mitigated in software without affecting the rest of the system, so no one really cares about these attacks. But the fundamental abstraction leak between physics and programming will always be there.

bhawks 3y ago
So you browse the Internet with JavaScript turned off? You're a bigger person than I am ;). The risk here is that there are more individuals with the skills to take this type of attack and bring it to a browser near you. One apps data is another apps code.
- PhilipRoman 3y ago
  Indeed, the scary thing is that there is no theoretical limit to how sophisticated a side channel attack could be. Imagine all the timing data that could in theory be gathered from html layout engines and css, even without javascript, just by resource loading times. I would like to salute my shitty ISP for keeping me safe from timing attacks using their unreliable network infrastructure.
  - robin_reala 3y ago
    This attack is now why browsers segment caching into a combination of requesting domain and asset URL, rather than just caching the asset on its own. It slows down for example Google Fonts, but means that a site can’t check to see that you’ve visited a competitor by timing an asset load from their site to see whether it’s in the cache.
- pmontra 3y ago
  I use uMatrix and allow first party JS. When some sites break I open the matrix look at what they would like to load and allow one more origin and reload. An example: chatgpt works by allowing JS from the first party domain, *azure.com and oaistatic.com, which looks like something from OpenAI. It would like to load JS from three other domains but it works even if I don't allow them, so there is no need to let that code run.
  - rpdillon 3y ago
    This is the way. Unfortunately, I've had no luck getting others to buy into the idea that they should understand this level of detail so they can make these calls. Quite frustrating and depressing, since companies will relentlessly exploit their indifference.
    - TheDong 3y ago
      If other people buy into this idea, then every site will begin proxying third-party javascript. If the only way to get trackers on the average person is to serve it from the same first-party domain, or to bundle it in with the giant 'app.js', you better believe they'll do that. Right now, the fact that only a small fraction of people run adblockers, and an even smaller fraction block javascript, is what allows it to work.
    - pmontra 3y ago
      Not many developers do that. The general population won't even understand what they are looking at. If you are good at teaching you can give them an idea and a few of them maybe will do it, but the time invested in the allow/reload loop is probably too much unless one is really committed. In my case when every attempt fails I know it could be the side effect of some other privacy add on. If it's a random blog/news, that's the end of it. If I really have to use that site I open Chrome, do what I have to do, close it. Of course given a choice I pick sites that work well with only JS from a few inevitable sources.
mort96 3y ago
OpenSSL is "trusted code". The problem isn't that OpenSSL is doing something nefarious, but that the CPU breaks assumptions it makes about how one can write constant-time algorithms.
- deleted 3y ago
  [deleted]
- tsimionescu 3y ago
  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.
  - eru 3y ago
    Anything you execute on behalf of a user, even if the binaries are trusted, can effectively become untrusted code.
  - mort96 3y ago
    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?
    - tsimionescu 3y ago
      Because the timing difference is extraordinarily subtle, far too small to measure compared to regular network timing noise.
      - adrianN 3y ago
        That usually just means that you need to collect more data to filter out the network noise.
pmontra 3y ago
So, CPUs or cores (and maybe RAM) dedicated to run only trusted and only untrusted code? Examples (I'm running Debian) The kernel, the X11 server, terminal, ssh, bash, anything coming from the official Debian repos including the password manager: in the trusted environment. browsers, electron apps, anything installed from unofficial repos or language and package managers (npm, rvm, asdf, etc): in the untrusted environment. It reminds me of mainframes and their redundant and compartmentalized hardware architecture.
- sofixa 3y ago
  > terminal, ssh, bash > X11 server Those can very easily execute untrusted code.
  - pmontra 3y ago
    Yes, but it can be countered by pinning "random-script-from-the-internet.sh" to the untrusted environment. The fork/exec inside bash (or whatever bash is using now) should take care or that, or the kernel itself which is probably a better option. bash + ls -> trusted because ls is in some way marked as trusted, bash + random-script -> untrusted, possibly by default.
  - PhilipRoman 3y ago
    Well it makes no sense to worry about side channel attacks if you don't have isolation in the first place, so there is an implicit assumption that you have a sandboxing layer like VM/container/browser (or the built in unix user separation) which don't care about terminals or X11 (usually a separate X server is used which is running inside the sandbox context).
aaomidi 3y ago
The entire point of this chip is to keep secrets hidden from local processes.
JediPig 3y ago
the author(s) of the article, completely ignore the cpu itself can be patched. there is microcode underneath the ARM instructions for such scenarios. Look at intel, there has been undocumented microcode for decades I beleive these articles are just hype for street cred.
- eek2121 3y ago
  From what I have read, the microcode on M-series chips is NOT updatable. If this is the case, tsk tsk Apple.
  - not_the_fda 3y ago
    I thought microcode was an artifact of CISC architectures, while the Arm is a RISC architecture.

bhawks 3y ago

So you browse the Internet with JavaScript turned off? You're a bigger person than I am ;). The risk here is that there are more individuals with the skills to take this type of attack and bring it to a browser near you. One apps data is another apps code.

PhilipRoman 3y ago
Indeed, the scary thing is that there is no theoretical limit to how sophisticated a side channel attack could be. Imagine all the timing data that could in theory be gathered from html layout engines and css, even without javascript, just by resource loading times. I would like to salute my shitty ISP for keeping me safe from timing attacks using their unreliable network infrastructure.
- robin_reala 3y ago
  This attack is now why browsers segment caching into a combination of requesting domain and asset URL, rather than just caching the asset on its own. It slows down for example Google Fonts, but means that a site can’t check to see that you’ve visited a competitor by timing an asset load from their site to see whether it’s in the cache.
pmontra 3y ago
I use uMatrix and allow first party JS. When some sites break I open the matrix look at what they would like to load and allow one more origin and reload. An example: chatgpt works by allowing JS from the first party domain, *azure.com and oaistatic.com, which looks like something from OpenAI. It would like to load JS from three other domains but it works even if I don't allow them, so there is no need to let that code run.
- rpdillon 3y ago
  This is the way. Unfortunately, I've had no luck getting others to buy into the idea that they should understand this level of detail so they can make these calls. Quite frustrating and depressing, since companies will relentlessly exploit their indifference.
  - TheDong 3y ago
    If other people buy into this idea, then every site will begin proxying third-party javascript. If the only way to get trackers on the average person is to serve it from the same first-party domain, or to bundle it in with the giant 'app.js', you better believe they'll do that. Right now, the fact that only a small fraction of people run adblockers, and an even smaller fraction block javascript, is what allows it to work.
  - pmontra 3y ago
    Not many developers do that. The general population won't even understand what they are looking at. If you are good at teaching you can give them an idea and a few of them maybe will do it, but the time invested in the allow/reload loop is probably too much unless one is really committed. In my case when every attempt fails I know it could be the side effect of some other privacy add on. If it's a random blog/news, that's the end of it. If I really have to use that site I open Chrome, do what I have to do, close it. Of course given a choice I pick sites that work well with only JS from a few inevitable sources.

mort96 3y ago

OpenSSL is "trusted code". The problem isn't that OpenSSL is doing something nefarious, but that the CPU breaks assumptions it makes about how one can write constant-time algorithms.

deleted 3y ago
[deleted]
tsimionescu 3y ago
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.
- eru 3y ago
  Anything you execute on behalf of a user, even if the binaries are trusted, can effectively become untrusted code.
- mort96 3y ago
  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?
  - tsimionescu 3y ago
    Because the timing difference is extraordinarily subtle, far too small to measure compared to regular network timing noise.
    - adrianN 3y ago
      That usually just means that you need to collect more data to filter out the network noise.

pmontra 3y ago

So, CPUs or cores (and maybe RAM) dedicated to run only trusted and only untrusted code? Examples (I'm running Debian) The kernel, the X11 server, terminal, ssh, bash, anything coming from the official Debian repos including the password manager: in the trusted environment. browsers, electron apps, anything installed from unofficial repos or language and package managers (npm, rvm, asdf, etc): in the untrusted environment. It reminds me of mainframes and their redundant and compartmentalized hardware architecture.

sofixa 3y ago
> terminal, ssh, bash > X11 server Those can very easily execute untrusted code.
- pmontra 3y ago
  Yes, but it can be countered by pinning "random-script-from-the-internet.sh" to the untrusted environment. The fork/exec inside bash (or whatever bash is using now) should take care or that, or the kernel itself which is probably a better option. bash + ls -> trusted because ls is in some way marked as trusted, bash + random-script -> untrusted, possibly by default.
- PhilipRoman 3y ago
  Well it makes no sense to worry about side channel attacks if you don't have isolation in the first place, so there is an implicit assumption that you have a sandboxing layer like VM/container/browser (or the built in unix user separation) which don't care about terminals or X11 (usually a separate X server is used which is running inside the sandbox context).

aaomidi 3y ago

The entire point of this chip is to keep secrets hidden from local processes.

JediPig 3y ago

the author(s) of the article, completely ignore the cpu itself can be patched. there is microcode underneath the ARM instructions for such scenarios. Look at intel, there has been undocumented microcode for decades I beleive these articles are just hype for street cred.

eek2121 3y ago
From what I have read, the microcode on M-series chips is NOT updatable. If this is the case, tsk tsk Apple.
- not_the_fda 3y ago
  I thought microcode was an artifact of CISC architectures, while the Arm is a RISC architecture.