GPUs from all major suppliers are vulnerable to new pixel-stealing attack

A previously unknown compression side channel in GPUs can expose images thought to be private.

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 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, as the proof-of-concept attack has been named, starts with a malicious website that places a link to the webpage it wants to read inside of an iframe, a common HTML element that allows sites to embed ads, images, or other content hosted on other websites. Normally, the same origin policy prevents either site from inspecting the source code, content, or final visual product of the other. The researchers found that data compression that both internal and discrete GPUs use to improve performance acts as a side channel that they can abuse to bypass the restriction and steal pixels one by one.
Advertisement

“We found that modern GPUs automatically try to compress this visual data, without any application involvement,” Yingchen Wang, the lead author and a researcher at the University of Texas at Austin, wrote in an email. “This is done to save memory bandwidth and improve performance. Since compressibility is data dependent, this optimization creates a side channel which can be exploited by an attacker to reveal information about the visual data.”

https://arstechnica.com/security/2023/09/gpus-from-all-major-suppliers-are-vulnerable-to-new-pixel-stealing-attack/

GPUs from all major suppliers are vulnerable to new pixel-stealing attack

A previously unknown compression side channel in GPUs can expose images thought to be private.

Ars Technica

I'm not sure how to think of this new GPU.zip attack. The side channel exists in the GPUs themselves, so it seems fair to think they are vulnerable.

On the other hand, the only (known) way to exploit this side channel is loading iframes into Chrome or Edge, so it also seems reasonable to say these browsers are the things that are vulnerable.

I'm curious to know what you think.

https://arstechnica.com/security/2023/09/gpus-from-all-major-suppliers-are-vulnerable-to-new-pixel-stealing-attack/

GPUs from all major suppliers are vulnerable to new pixel-stealing attack

A previously unknown compression side channel in GPUs can expose images thought to be private.

Ars Technica
@dangoodin the vulnerability is still with the GPUs even if it requires very specific circumstances to exploit. AFAICT it's not that the browsers are doing anything *wrong* per se, it's just that the way Chrome handles things happens to allow this exploit to work.
@spad @dangoodin I think this is a good example of why the concept of a piece of software being "vulnerable" can only take us so far. It is users who are vulnerable and all software can be improved even if it isn't currently "wrong". e.g. If ssh clients responded to packet timing side channels with "not our fault the network has such low latency" we would have all moved on.
@spad @dangoodin Giving the website any access at all to a historically-vulnerable-garbage hardware device (the GPU) falls under "browser doing something wrong" in my book.

@dalias iframes are the issue for me. I’d love to see them die in a fire. Literally nothing but abuse comes from them. Worst browser decision ever.

That being said, the GPU is definitely vulnerable and there’s probably another way to abuse the information leakage.

@0x0FFF @dalias
I use IFrames to embed stuff in SharePoint pages at work all the time. 🤷‍♂️
@JamesDBartlett3 I mean, I personally wouldn't do that. At least not without a lot of restrictions. It's asking for trouble. If it’s an internal sharepoint and that’s what everyone has agreed on then you do you. Just know you're playing with fire from a security view depending on what you're embedding and whether or not you're restricting the domains you can embed from.
@0x0FFF
Yeah, it's an internal SharePoint site, I'm only embedding Power BI reports from our organization, and we have it locked down to only show said reports to people already signed in with their SSO.
@0x0FFF @JamesDBartlett3 iframe isn't the problem. The problem was the complete lack of consideration of privilege boundaries when it, and later features that interact with it like other potentially transparent elements partly or fully obscuring the iframe, were added, which is par for the course when it comes to browser devs. 🤬
@0x0FFF @JamesDBartlett3 Every feature you add that the browser exposes to sites, by default, us a violation of the user's mental model of what sites can do to them and their computer. This problem won't be fixed until the highest paid members of browser teams, with full veto power, are experts in privacy and consent rather than experts in marketing, data harvesting, eye candy, etc.
@dalias @JamesDBartlett3 tell that to Apple who runs an iframe sandbox in safari and literally just had a remote code execution vulnerability in the sandbox. Iframes are the problem.
@0x0FFF @JamesDBartlett3 The words "iframe sandbox" apparently don't mean the same thing to us and to Apple...
@dalias lol I’ll agree with you there
@dalias in all seriousness though, if something is so hard to implement correctly then in my opinion it’s the problem. Similar to how rust was created to provide an alternative to C/C++ that was easier for people to use in a memory safe way. No one really said C/C++ weren’t the issue even though you could technically use them in memory safe ways. It was just too difficult for the majority of people/groups to do so. Just my take.

@0x0FFF @dalias agree with you there, bad engineering choices makes overall solution look bad and work even worse.

iframes are nothing but PITA, these are the things that are seriously needed to be removed from modern day browsers.

A similar analogy could be, using RSA after 2025.

@xld @0x0FFF RSA is really the more secure option, just costly. Even if QC turns out not to be utter bs, you can just up the key size to like 64k and it'll be secure forever.

@dalias @0x0FFF I beg to differ, first of all finding prime number for exponent this big would be very time consuming process for such simple problem.

Second QC is just on the horizon with IBM presumably launching 4k qubit QC at the end of this year (it will be delayed most probably), but by Shor's algorithm, QC above 1000 qubits deems to shorten the exponent searching problem by an order of magnitude faster.

TL;DR: Let's start adopting PQ crypto, for now lattice based cryptosystem seems promising :)

@xld @0x0FFF QC has been on the horizon for decades. There's still no evidence it can actually scale without corresponding scaling of physical measurement precision beyond what's physically possible, and no meaningful (i.e. not specific to the number being factored, which might as well be a hard coded answer) demo of factoring even of small numbers.

@dalias @0x0FFF True and because of that the comapnies and agencies building it, will try their absolute best to keep it's abilities a secret in order to prevent spreading a mass hysteria across the internet.

Therefore, if we actually want a solid practical proof of its abilities, more people are needed to have its access, which I think, is just another play on surveillance of its usage.

@dangoodin
I wonder if Safari and Firefox are likely vulnerable, but the researchers didn't feel the need to create a POC.
@dangoodin
For me though, I'm breaking out my old Matrox card.

@dangoodin
I think it is a GPU bug, because it is breaking the same origin promise due to GPU behavior rather than browser behavior.

At the same time I'm not sure it matters at all: The bandwidth of the side channel seems very low (1/2 hour to read data? OWch), and critically it can't be done in an invisible iFrame because it has to be rendered for this to work.

@dangoodin I think you need to look at it as they’re both vulnerable. Or rather there’s one vulnerability when both systems are put together. The browser iframes are being abused (literally the only thing to ever come from iframes is abuse) so they definitely have an issue but the GPU has an information leakage issue which needs to be addresssed. Either with some sort of variable padding or in some other way. I’m not really a low level hardware guy.

So they both have issues for sure, although I’d say they aren’t really vulnerabilities unless combined. Although I’d love to see the death of iframes as soon as possible. They’re way too easy to abuse.

@dangoodin Really great article, and super neat theoretical research. The comment you promoted would have been great to address in part of the article where you go into the mechanics.

In terms of "How to think of this new attack" - IMHO, this would be on browsers to fix _if_ it was anywhere close to practical. Taking 30 minutes to extract a couple hundred pixels from a carefully chosen zone in Wikipedia in (I assume no other significant computer activity or GPU load) makes it a fun parlor trick.

I'm going to go out on a limb and take a wild guess that you didn't get past the 5th paragraph.

@dangoodin It's along the lines of "If you are a domain admin, you can install malware!"

Uh, if you are a domain admin, you can do whatever you want.

@Sempf OK, now I KNOW you didn't read the post.

@dangoodin Yeah I did! Every word, like I always do with your articles.

That's not saying that I didn't have a woosh moment.

@dangoodin Don't take my reply literally. I was categorizing it with all the "if lots is wrong then THIS is possible" vulnerabilities.
@dangoodin Haven't got to the first paragraph yet… I think we momentarily broke the server.
@stuartl @dangoodin lol infosec people are jinxed when it comes to visiting new sites haha.
@dangoodin Hey, not everyone here is running Firefox on top of their favorite flavor of Linux.
@dangoodin @airadam Buried lede: only affects #Chrome and Chrome-based browsers. #Firefox and #Safari not affected.
@aral @dangoodin @airadam it’s not clear to me that Apple’s GPUs are affected either. They said ARM, but Apple designs their own chips, right?

@JetForMe @aral @airadam

The researchers tested Apple GPUs and found that they were, in fact, vulnerable. What exactly is unclear to you?

@dangoodin @aral @airadam Oh! I completely missed that when I was reading that sentence. Thanks for making me go back for a second look.
@aral
Minor nitpick: It's actually the #lede that was buried, not the #lead. A very common misconception, but still worth knowing the difference.
https://www.merriam-webster.com/wordplay/bury-the-lede-versus-lead
Why do we 'bury the lede?'

We buried 'lead' so far down that we forgot how to spell it