GPUs From All Major Suppliers Are Vulnerable To New Pixel-Stealing Attack (arstechnica.com) 26
An anonymous reader quotes a report from Ars Technica: GPUs from all six of the major suppliers are vulnerable to a newly discovered attack that allows malicious websites to read the usernames, passwords, and other sensitive visual data displayed by other websites, researchers have demonstrated in a paper (PDF) published Tuesday. The cross-origin attack allows a malicious website from one domain -- say, example.com -- to effectively read the pixels displayed by a website from example.org, or another different domain. Attackers can then reconstruct them in a way that allows them to view the words or images displayed by the latter site. This leakage violates a critical security principle that forms one of the most fundamental security boundaries safeguarding the Internet. Known as the same origin policy, it mandates that content hosted on one website domain be isolated from all other website domains. [...]
GPU.zip works only when the malicious attacker website is loaded into Chrome or Edge. The reason: For the attack to work, the browser must:
1. allow cross-origin iframes to be loaded with cookies
2. allow rendering SVG filters on iframes and
3. delegate rendering tasks to the GPU
For now, GPU.zip is more of a curiosity than a real threat, but that assumes that Web developers properly restrict sensitive pages from being embedded by cross-origin websites. End users who want to check if a page has such restrictions in place should look for the X-Frame-Options or Content-Security-Policy headers in the source. "This is impactful research on how hardware works," a Google representative said in a statement. "Widely adopted headers can prevent sites from being embedded, which prevents this attack, and sites using the default SameSite=Lax cookie behavior receive significant mitigation against personalized data being leaked. These protections, along with the difficulty and time required to exploit this behavior, significantly mitigate the threat to everyday users. We are in communication and are actively engaging with the reporting researchers. We are always looking to further improve protections for Chrome users."
An Intel representative, meanwhile, said that the chipmaker has "assessed the researcher findings that were provided and determined the root cause is not in our GPUs but in third-party software." A Qualcomm representative said "the issue isn't in our threat model as it more directly affects the browser and can be resolved by the browser application if warranted, so no changes are currently planned." Apple, Nvidia, AMD, and ARM didn't comment on the findings.
An informational write-up of the findings can be found here.
GPU.zip works only when the malicious attacker website is loaded into Chrome or Edge. The reason: For the attack to work, the browser must:
1. allow cross-origin iframes to be loaded with cookies
2. allow rendering SVG filters on iframes and
3. delegate rendering tasks to the GPU
For now, GPU.zip is more of a curiosity than a real threat, but that assumes that Web developers properly restrict sensitive pages from being embedded by cross-origin websites. End users who want to check if a page has such restrictions in place should look for the X-Frame-Options or Content-Security-Policy headers in the source. "This is impactful research on how hardware works," a Google representative said in a statement. "Widely adopted headers can prevent sites from being embedded, which prevents this attack, and sites using the default SameSite=Lax cookie behavior receive significant mitigation against personalized data being leaked. These protections, along with the difficulty and time required to exploit this behavior, significantly mitigate the threat to everyday users. We are in communication and are actively engaging with the reporting researchers. We are always looking to further improve protections for Chrome users."
An Intel representative, meanwhile, said that the chipmaker has "assessed the researcher findings that were provided and determined the root cause is not in our GPUs but in third-party software." A Qualcomm representative said "the issue isn't in our threat model as it more directly affects the browser and can be resolved by the browser application if warranted, so no changes are currently planned." Apple, Nvidia, AMD, and ARM didn't comment on the findings.
An informational write-up of the findings can be found here.
Software Issue (Score:5, Insightful)
"An Intel representative, meanwhile, said that the chipmaker has "assessed the researcher findings that were provided and determined the root cause is not in our GPUs but in third-party software." A Qualcomm representative said "the issue isn't in our threat model as it more directly affects the browser and can be resolved by the browser application if warranted, so no changes are currently planned."
but lets leave the headline falsely claiming its a GPU issue....
Re: (Score:1)
I warned them all that iframes were a bad idea...
Re: (Score:2)
that is why i am a very difficult web developer to work with.
client tells me:
why can't I have SoundCloud on my website? So I can upload songs all by myself
why so controlling?
because: security.
i just dunno how or why.
having an iframe load external sites seems like a bad idea.
plus it makes a website look cheap / tacky.
tomorrow the external resource might be hacked or go offline.
then things will look pretty bad.
Re: (Score:2)
The problem arises when you want to load into the iframe the content of a site over which you have no control and where you can't even trust the author of the site in question, then you're going to have problems.
Re:Software Issue (Score:5, Informative)
Doubling up on your statement, from TFA:
"Under-the-hood differences in the way Firefox and Safari work prevent the attack from succeeding when those browsers process an attack page."
Re: Software Issue (Score:2)
I'm also curious as to whether this is OS-dependant as well. I know firefox uses the same engine across platforms, but how it interfaces with the gpu and drivers is going to be different between platforms (i.e, Windows vs Linux vs macOS). TFA does not mention this, aside from the generic prerequisites for an attack surface.
Re: (Score:1)
I'm also curious as to whether this is OS-dependant as well.
I think this may answer your question.
"All of the GPUs analyzed use proprietary forms of compression to optimize the bandwidth available in the memory data bus of the PC, phone, or other device displaying the targeted content. The compression schemes differ from manufacturer to manufacturer and are undocumented, so the researchers reverse-engineered each one."
I think this is also an important tidbit.
"As noted earlier, GPU.zip works only when the malicious attacker website is loaded into Chrome or Edge. The
Re: (Score:2)
"I'm also curious as to whether this is OS-dependant as well."
No, FireFox and Safari simply do not allow cross-site injection garbage like Chromium browsers allow.
Re: Software Issue (Score:2)
That still does not answer the question of whether or not Chrome/Chromium for Linux is going to be affected. Linux drivers and APIs trend towards being more security focused (Aging X11 stack aside)
Re:Software Issue (Score:5, Insightful)
This paper challenges the above conventional wisdom by demonstrating the existence of, and exploiting, software-transparent uses of compression. Specifically, we find that integrated GPUs from Intel and AMD vendors compress graphical data in vendor-specific and undocumented ways — even when software does not specifically request compression. Compression induces data-dependent DRAM traffic and cache utilization, which can be measured through side-channel analysis. We show the efficacy of this side channel by performing cross-origin SVG filter pixel stealing attacks through the browser.
and
The technical core of the paper is a detailed investigation of integrated GPU (iGPU)-based software-transparent lossless compression schemes deployed on Intel and AMD processors.
This definitely seems to be GPU-related, even if it's an "iGPU"...
Re: (Score:2)
Yeah, but most people probably should have something like first-party isolation enabled anyway. That would prevent the targeted site in the iframe from accessing any cookies or cache that is available when the target domain is displayed in the Location Bar. The attacking site would see a "you're not logged in" version of the target site... https://www.ghacks.net/2017/11... [ghacks.net]
Re:Software Issue (Score:5, Insightful)
...a malicious page must be loaded into the Chrome or Edge browsers. Under-the-hood differences in the way Firefox and Safari work prevent the attack from succeeding
This is not a GPU problem, it is a bug in Chrome.
Re: (Score:3)
It's not a bug, it's the GPU not behaving in the way that the API implies it will. Chrome does not ask for the data to be compressed, but the GPU (or rather the driver) does it anyway. It's particularly an issue on integrated GPUs, which share system RAM, presumably because they benefit greatly from both reducing the amount of memory used and the amount of memory bandwidth required.
The compression results in data becoming extractable via a side-channel attack.
It was not unreasonable for the Chrome developer
Re: (Score:3)
Why it seems like only a day or two ago headlines were announcing the Inaugural Brightline train run, Kills Pedestrian while failing to clarify the dead pedestrian was laying on a completely different railroad track, in front of a completely different train.
And now today, it's not merely a "GPU issue" but GPUs from all six of the major suppliers" being shit on at once?
Just how many stock prices we gonna try and crash this week with clickbait bullshit?
Nice. (Score:1)
What does this have to do with GPUs (Score:1)
Re: (Score:2)
They do direct rendering now - check the thread names on your browser.
At least SuperMicro cheaped out and put a Matrox chip on my Intel servers!
What about Chromium? (Score:5, Interesting)
As written, TFS claims this is a vulnerability in proprietary software. Yawn.
If Chromium is also affected, that's a problem.
Re: (Score:1)
Good question, actually.
Re:What about Chromium? (Score:4, Insightful)
It affects Chrome and Edge, so I would say there's about a 99.9999% chance that the answer is yes. Yawn.
So... (Score:3)
So Google's browser has a vulnerability that lets cross-origin iframes steal information. I wonder where most cross-origin iframes come from? Google Ads maybe?
Re: (Score:2)
It's the attacker site that frames the victim site in this attack, not the other way around.
Isn't Easier To Just Capture The Packets (Score:2)
And avoid all that overhead?
FPI in Firefox probably prevents this (Score:5, Informative)
First-party isolation (if it is turned on) should prevent "site B" identity from being accessed via cookies, because the FPI context of site A (the iframe embedder) won't have access to the cookie/cache storage that is used when site B is visible in the Location Bar. So the embedded iframe of the target site (B) would not display personal information, but instead show the page as if you needed to login.
Easiest way to turn on FPI in Firefox is to set Enhanced Tracking Protection to 'Strict' in Settings. It can also be specifically enabled via about:config.
GPU.zip works only when the malicious attacker web (Score:1)
Mitigations? (Score:1)
It seems blocking all third-party iframes can mitigate this issue, using this uBlock Origin rule:
||*^$subdocument,third-party