4 ms·

I simply don't understand what they did here, and this press release doesn't actually say what they did. > The team was able to track changes in the cache by f

I simply don't understand what they did here, and this press release doesn't actually say what they did. > The team was able to track changes in the cache by filling it themselves using code in the JavaScript via WebGPU and monitoring when their own data was removed from the cache by input. This made it possible to analyse the keystrokes relatively quickly and accurately. By segmenting the cache more finely, the researchers were also able to use a second attack to set up their own secret communication channel, in which filled and unfilled cache segments served as zeros and ones and thus as the basis for binary code. They used 1024 of these cache segments and achieved transfer speeds of up to 10.9 kilobytes per second, which was fast enough to transfer simple information. Attackers can use this channel to extract data that they were able to attain using other attacks in areas of the computer that are disconnected from the internet. I don't understand which cache they're talking about, and why this has anything to do with keystrokes. And suggesting the use of cache invalidation to transmit information from one process to the browser doesn't really sound like a very concerning attack vector (how did you get a process running on the host computer in the first place, but without Internet access?) > The third attack targeted AES encryption, which is used to encrypt documents, connections and servers. Here, too, they filled up the cache, but with their own AES encryption. The reaction of the cache enabled them to identify the places in the system that are responsible for encryption and access the keys of the attacked system. Sorry, what? No part of this tracks for me. Who is even using the GPU for AES encryption? Or is this looking at the CPU cache by way of webgpu? If there's good work being done here, this article is frankly doing it a massive disservice.

remram 3y ago
The paper is linked at the bottom: https://ginerlukas.com/publications/papers/WebGPUAttacks.pdf https://ginerlukas.com/publications/papers/WebGPUAttacks.pdf It looks like it targets AES and keystrokes if they're processed on the GPU. They detect which parts of AES lookup tables (T-Tables) are getting added to the cache, which gives information about the key (section 6).
- bastawhiz 3y ago
  It sounds like the keystroke attack they claim isn't practical? > Despite the high recall, with the low precision, we can consider this attack mostly failed or severely degraded And in to what I said originally (who is actually doing AES on a GPU?) it sounds like the key recovery is also impractical: > In order to implement a last-round attack, we assume the attacker has access to the victim’s ciphertexts, but not the plaintext or the key. How exactly is a browser supposed to get access to the ciphertext in the first place?
  - gpm 3y ago
    > How exactly is a browser supposed to get access to the ciphertext in the first place? MITM attacks are usually considered relatively easy to pull off. Run a fake wifi-hotspot in an airport, use the "login portal" to get access to their browser, use the hotspot itself to get access to the cipher texts when they visit other https page (edit: I suppose those would be decrypted on the CPU... but when they use whatever odd program that thought decrypting messages to it on the GPU is a good idea).
    - bastawhiz 3y ago
      That assumes the encrypted content is transferred in plaintext (not over https). I think you'd be hard pressed to find a HTTPS client that decrypts on the GPU. And then of course, the thing being decrypted needs to be big enough for the process to take long enough for them to perform the attack, which means many gigabytes (terabytes?). And then you'd still need to send the data from the mitm server back to the browser for processing before you start measuring anything. It's obvious they accomplished something, but the scenario they set up simply isn't something that is practical in the real world
      - freeone3000 3y ago
        DRM-encrypted streaming video, perhaps? Gigabytes of encrypted data that needs to be decrypted and displayed?
baybal2 3y ago
[dead]
redrabbyte 3y ago
It's always hard to communicate fairly academic side channels in a way that the audience of a press-release (which is typically anyone) can get any level of detail. We tried to walk the line between enough information and not overwhelming, but it doesn't always work out :D Luckily there's always the paper. This article also did a pretty good job of a high-level summary imo https://www.securityweek.com/new-attack-shows-risks-of-browsers-giving-websites-access-to-gpu/ https://www.securityweek.com/new-attack-shows-risks-of-brows...

remram 3y ago

The paper is linked at the bottom: https://ginerlukas.com/publications/papers/WebGPUAttacks.pdf https://ginerlukas.com/publications/papers/WebGPUAttacks.pdf It looks like it targets AES and keystrokes if they're processed on the GPU. They detect which parts of AES lookup tables (T-Tables) are getting added to the cache, which gives information about the key (section 6).

bastawhiz 3y ago
It sounds like the keystroke attack they claim isn't practical? > Despite the high recall, with the low precision, we can consider this attack mostly failed or severely degraded And in to what I said originally (who is actually doing AES on a GPU?) it sounds like the key recovery is also impractical: > In order to implement a last-round attack, we assume the attacker has access to the victim’s ciphertexts, but not the plaintext or the key. How exactly is a browser supposed to get access to the ciphertext in the first place?
- gpm 3y ago
  > How exactly is a browser supposed to get access to the ciphertext in the first place? MITM attacks are usually considered relatively easy to pull off. Run a fake wifi-hotspot in an airport, use the "login portal" to get access to their browser, use the hotspot itself to get access to the cipher texts when they visit other https page (edit: I suppose those would be decrypted on the CPU... but when they use whatever odd program that thought decrypting messages to it on the GPU is a good idea).
  - bastawhiz 3y ago
    That assumes the encrypted content is transferred in plaintext (not over https). I think you'd be hard pressed to find a HTTPS client that decrypts on the GPU. And then of course, the thing being decrypted needs to be big enough for the process to take long enough for them to perform the attack, which means many gigabytes (terabytes?). And then you'd still need to send the data from the mitm server back to the browser for processing before you start measuring anything. It's obvious they accomplished something, but the scenario they set up simply isn't something that is practical in the real world
    - freeone3000 3y ago
      DRM-encrypted streaming video, perhaps? Gigabytes of encrypted data that needs to be decrypted and displayed?

baybal2 3y ago

[dead]

redrabbyte 3y ago

It's always hard to communicate fairly academic side channels in a way that the audience of a press-release (which is typically anyone) can get any level of detail. We tried to walk the line between enough information and not overwhelming, but it doesn't always work out :D Luckily there's always the paper. This article also did a pretty good job of a high-level summary imo https://www.securityweek.com/new-attack-shows-risks-of-browsers-giving-websites-access-to-gpu/ https://www.securityweek.com/new-attack-shows-risks-of-brows...