GPUs from Nvidia, AMD, Intel, and Others Vulnerable to Pixel-Stealing GPU-zip Attack

asdf
(Image credit: Shutterstock)

A new side-channel vulnerability affecting all GPU vendors may deliver private information to malicious websites without user consent. According to research hailing from the University of Texas at Austin, the new vulnerability has been shown to allow for the recovery of private, sensitive information such as usernames, passwords, and other elements. The scope of the vulnerability is so severe that it allows malicious websites to reconstruct the GPU-generated pixel rendering of another website (and the credentials used to access it). The researchers say the overall threat from the attack is low but that it is important that companies work to mitigate the issue in hardware and software.

The attack works on GPUs provided by Apple, Intel, AMD, Qualcomm, Arm, and Nvidia. Through it, a basic cybersecurity principle of the world wide web known as the same origin policy - which mandates full isolation between domains and their content - can be violated.

The vulnerability itself explores GPU data compression, a technique that allows GPUs to reduce the footprint of in-flight and stored data. Because compression is data dependent - meaning that the compressed data is a mathematical representation that "folds" the size of the original but still obviously relates to it and can be "unfolded" back - compression doesn't prevent the original information from being gleaned. Whenever there's GPU data compression, traffic within the system's DRAM and caches is a direct extension of the original data, allowing certain bits of information to be recovered.

In fact, the original data of interest (the passwords, usernames, and other elements deemed valuable to the attacker) can be reconstructed one rendered pixel at a time.

A comparison of pixel-recovery between AMD and Intel

Pixel stealing PoC for deanonymizing a user, run with other tabs open playing video. “Ground Truth” is the victim iframe (Wikipedia logged in as “Yingchenw”). “AMD” is the attack result on a Ryzen 7 4800U after 30 minutes, with 97 percent accuracy. “Intel” is the attack result for an i7-8700 after 215 minutes with 98 percent accuracy. (Image credit: Wang et al)

The attack, GPU-zip, requires a malicious website that places a link within its pages under an iFrame container - an HTML element that allows for embedding content from external websites. Additionally, the page linked to in iFrame must specifically be configured not to deny embedding, and the GPU must be the hardware responsible for rendering it (as they are 99% of the time). Due to the different ways certain browser deployments work, not all browsers make this GPU vulnerability exploitable: Edge and Chrome are currently vulnerable to it, but Safari and Firefox are not (this lets us know that the issue isn't Chromium itself and should be fixable to an extent by browser providers).

“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 to Ars. “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.”

The issue, according to the researchers, is that GPU vendors all include some GPU-based data compression algorithms to improve rendering performance. However, these compression algorithms are proprietary and largely undocumented in the public space.

Following good cybersecurity practices, the researchers privately disclosed their findings to GPU vendors (and Google) as early as March 2023. Says the paper that "the GPU vendors largely declined to act; one said the side channel was outside their threat model, another that it was the responsibility of software to mitigate. As of August 2023, Apple and Google were still deciding whether and how to mitigate." Considering the difficulty in coordinating cybersecurity responses across software and hardware complexity, we'll have to wait and see how exactly the loop is closed.

Francisco Pires
Freelance News Writer

Francisco Pires is a freelance news writer for Tom's Hardware with a soft side for quantum computing.

  • oofdragon
    If anyone here using windows is concerned about GPU or CPU or any other hardware exploitable flaw....... what can I say
    Reply
  • jaydenmiller1
    As long as said flaws require physical access to the machines, most home users should be fine. Just don't allow people you don't trust to access your system. (I know this particular flaw doesn't require physical access) but just be careful what websites you visit and what you download.
    Reply
  • andrep74
    jaydenmiller1 said:
    As long as said flaws require physical access to the machines, most home users should be fine. Just don't allow people you don't trust to access your system. (I know this particular flaw doesn't require physical access) but just be careful what websites you visit and what you download.

    This advice is so wrong as to actually be dangerous!

    Ads served in <iframe> elements would normally not have access to content in the containing site, but this vulnerability bypasses that restriction. For any site that displays the username (typically in the top right corner) and also serves ads, *any user* is at risk. Unfortunately, most email provider websites do both, and since email forms the basis for security of sites that don't serve ads, can be used to help gain access to those otherwise-secure sites. Hell, even non-browser applications that use Electron or a webview-like control to display ads, could read screen data.

    The only mitigating factor is that passwords are not usually displayed on screen, except as dots, and this vulnerability takes quite a while to read screen data.
    Reply
  • hotaru251
    Yet another reason to add Firefox superiority. ;p

    for real though this sucks if some ppl end up getting harmed by this in future.
    Reply
  • jaydenmiller1
    andrep74 said:
    This advice is so wrong as to actually be dangerous!

    Ads served in <iframe> elements would normally not have access to content in the containing site, but this vulnerability bypasses that restriction. For any site that displays the username (typically in the top right corner) and also serves ads, *any user* is at risk. Unfortunately, most email provider websites do both, and since email forms the basis for security of sites that don't serve ads, can be used to help gain access to those otherwise-secure sites. Hell, even non-browser applications that use Electron or a webview-like control to display ads, could read screen data.

    The only mitigating factor is that passwords are not usually displayed on screen, except as dots, and this vulnerability takes quite a while to read screen data.
    I wasn't referring to iframe vulnerabilities, I was referring to the fact that as long as ANY vulnerabilities require physical access to the host machine, it is not that big of a deal as long as you don't leave your device unattended for long periods of time.
    Reply
  • Brian28
    >"Edge and Chrome are currently vulnerable to it, but Safari and Firefox are not (this lets us know that the issue isn't Chromium itself"

    I don't follow: Safari and Firefox are not Chromium, Edge and Chrome are. How does the conclusion "it isn't Chromium" follow from this data?
    Reply
  • InvalidError
    oofdragon said:
    If anyone here using windows is concerned about GPU or CPU or any other hardware exploitable flaw....... what can I say
    This isn't a Windows issue, it is a cross-platform browser iframe issue: they say it even works on Apple's stuff.

    The solution: don't open your bank, tax and other sensitive accounts from third-party pages which may insert an iframe. Type the site's address directly.
    Reply
  • wbfox
    Brian28 said:
    >"Edge and Chrome are currently vulnerable to it, but Safari and Firefox are not (this lets us know that the issue isn't Chromium itself"

    I don't follow: Safari and Firefox are not Chromium, Edge and Chrome are. How does the conclusion "it isn't Chromium" follow from this data?
    Because of the non-transverse property. Because A ≠ B and B = C therefore A = Chromium. duh.
    Reply
  • NinoPino
    jaydenmiller1 said:
    I wasn't referring to iframe vulnerabilities, I was referring to the fact that as long as ANY vulnerabilities require physical access to the host machine, it is not that big of a deal as long as you don't you your device unattended for long periods of time.
    From what is written in the article this vulnerability need only a website, no physical access. And thera are a lot of other vulnerabilities that do not need physical access (networking in general).
    Reply
  • NinoPino
    Can someone explain me what is the point of password pixel reconstruction when 100% of the password requests are obfuscated ? In case of phishing, pixel stealing is the last problem. Maybe I am missing something ?
    Reply