{"id":21755,"date":"2023-10-09T19:57:27","date_gmt":"2023-10-09T15:57:27","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/gpu-zip-attack\/21755\/"},"modified":"2023-10-09T19:57:40","modified_gmt":"2023-10-09T15:57:40","slug":"gpu-zip-attack","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/gpu-zip-attack\/21755\/","title":{"rendered":"GPU.zip: deft theft of secrets from video chips"},"content":{"rendered":"

Researchers from four U.S. universities have published a study<\/a> detailing a potential, intriguing attack on computer graphics subsystems \u2014 specifically targeting common integrated GPUs manufactured by both AMD and Intel. The attack was named GPU.zip, alluding to its two main features: (i) stealing secrets from the graphics system, and (ii) exploiting data compression algorithm vulnerabilities. In this post, we try as usual to explain the new research as simply as possible. But mainly we\u2019ll just marvel at how elegant and complex it is \u2014 while we\u2019ll also cringe at how, ultimately (in its current form), completely impractical it is.\n<\/p>\n

About compression algorithms<\/h2>\n

\nBefore delving into the GPU.zip attack itself, let\u2019s discuss some aspects of compression algorithms. These algorithms can be broadly categorized into lossy compression algorithms (like MP3) and lossless compression algorithms (like RAR or ZIP). The latter ones compress data in such a way that it can be completely restored. The simplest method of compression is to store repeating data only once, and then indicate where specific sets of characters or numbers should be placed. For example, the length of this post could be significantly reduced by recording all the places where the word \u201cdata\u201d appears and storing the word itself only once.<\/p>\n

From an information security perspective, compression algorithms have a vulnerability of sorts. Let\u2019s imagine that we\u2019re transmitting some data over the internet using compression. The volume of information depends on how effective the compression algorithm is \u2014 the better the compression, the smaller the data size. Back in 2002, it was shown<\/a> that this feature could be exploited to steal secrets even if the data is encrypted. One of the relatively practical attacks confirming this possibility was demonstrated<\/a> in 2012.<\/p>\n

It was found that in some cases, if information between a browser and a server is transmitted simultaneously in both compressed and encrypted forms, the compression algorithm could reveal secret information even if the encryption algorithm isn\u2019t hacked. If attackers can send numerous requests to the server, they can observe how the size of compressed data changes based on the content. And from this they can calculate the secret information character by character. It remains to be seen whether unchecked compression of graphics subsystem data can also lead to leakage of secrets.\n<\/p>\n

About the features of computer graphics<\/h2>\n

\nToday, we\u2019re discussing the graphics subsystem \u2014 or, simply put, video cards, although they\u2019re often integrated directly into the processor. Discrete GPUs are separate computational modules, usually with their own RAM. Computer gamers are familiar with the situation when the latest cool game struggles to run on a not-so-powerful video card: the frame refresh rate drops below optimal, the image is no longer smooth, and sometimes it even freezes for a fraction of a second. There can be two reasons for such behavior. Most often, the video card can\u2019t handle the calculations required to create 3D images quickly enough. Sometimes, however, the required data is transmitted too slowly from the main RAM to the graphics subsystem memory.<\/p>\n

This problem can be solved by using data compression algorithms. Games use lossy compression algorithms to compress textures. The authors of the paper found that, at least in Intel and AMD integrated GPUs, lossless compression algorithms are used as well \u2014 to transmit any graphic information that needs to be displayed on the screen (desktop, browser windows, and so on). These algorithms cannot be disabled and, moreover, are proprietary \u2013 no one but the manufacturer knows how they work. The researchers studied them in \u201cblack box\u201d mode: the very existence of the compression algorithm was determined based on indirect signs, such as the amount of data transferred from RAM to video memory, which varied depending on the image. Transmitting graphic patterns made entirely of black pixels, black and white pixels in a specific order, and random patterns, showed that when easily compressible data is sent to the video system, less information is transferred between the main RAM and video memory: exactly the way data compression should work.<\/p>\n

Most of the study is dedicated to reverse engineering these proprietary data compression algorithms. This research was deemed necessary to understand exactly how such algorithms work \u2014 for example, how graphics information is divided into blocks before compression. The researchers found that different algorithms are applied depending on the manufacturer or even the model of the graphics subsystem.<\/p>\n

The problem is that the time it takes to compress data also depends on the data itself. If we have a poorly compressible set of information (random data without any repeating elements), the processing time will differ compared to \u201csimple data\u201d. Meanwhile, an attacker can measure this time \u2014 for instance, by creating a special webpage.\n<\/p>\n

The beauty\u2026 and uselessness of the GPU.zip attack<\/h2>\n

\nImagine someone creating a \u201cmalicious\u201d webpage that also contains a request to embed another page from which they want to steal data. This person has the ability to measure the time it takes to render their page in the browser, but nothing more. If, for example, a window with the target\u2019s work email is embedded in the page, the attacker won\u2019t gain access to the content of that window. Why? Such an action is strictly prohibited by the same-origin policy<\/a> rule \u2014 you can place code on a site to track user actions, for example, but it won\u2019t work on the embedded \u201cforeign\u201d webpage. There is one exception, however: styling rules can be applied to the embedded page.<\/p>\n

The authors of the GPU.zip attack took advantage of this and began applying specific graphics patterns to the target page. This led to changes in the time required to process compressed graphic data, thereby slightly altering the duration of page rendering. Which can be measured.<\/p>\n

The original image and its copies, \"stolen\" using the GPU.zip attack

The original image and its \u201cstolen\u201d copies extracted using the features of Intel and AMD graphics systems. Source<\/a><\/p><\/div>\n

We\u2019ve finally reached the practical implementation of this attack. Here\u2019s how it works: the attacker somehow lures the user to the malicious webpage. The page contains code embedding another page from a completely different site \u2014 in this case, Wikipedia\u2019s main page. Let\u2019s assume the browser user has a Wikipedia account and is logged in. Their username will be displayed on the embedded page. By applying effects to this page and measuring the time it takes to render, the attacker can reconstruct the content of the target page from this single parameter alone. More specifically, the attackers can obtain the username. In this way, they can identify the visitor of their malicious site \u2014 even if the visitor tries to remain anonymous, for example.<\/p>\n

This is a typical side-channel attack: the attacker uses an indirect parameter that they can measure (the time it takes to render a web page) to steal data they don\u2019t have access to. But now, let\u2019s discuss the impracticality of this attack\u2026<\/p>\n

The content of the target web page is reconstructed pixel by pixel. The attacker has a timer and the ability to slightly modify the appearance of the page in the browser. As a result, it takes half an hour on an AMD Ryzen processor with integrated graphics to reconstruct not the entire page but only a small piece, as shown in the screenshot above. On an Intel processor, the algorithm works even slower \u2014 the reconstruction takes more than three hours!<\/p>\n

This means the potential victim has to open the page and forget about it for quite a while, without closing it. During all this time, the page will be refreshing, which puts a heavy load on the system. However, the accuracy of the data reconstruction is quite high (97-98%) and, most importantly, the method works even when a large volume of other data is transmitted through the video card. The researchers had a YouTube video playing in the background. Unlike previous studies, this attack works reliably even with a significant amount of such \u201cbackground noise\u201d.<\/p>\n

The final argument against the feasibility of this particular attack is that most websites cannot be embedded into other web pages if they display confidential content. This means that you can\u2019t sneakily \u201cscreenshot\u201d email messages or chat conversations in this way. The example with the Wikipedia page was actually chosen because it\u2019s a rare case where a website with a visible username can be embedded.<\/p>\n

To sum it up. Unlike other hardware vulnerabilities, it can\u2019t be said with certainty that GPU developers made a mistake in this case. We\u2019re talking about extremely complex interactions among different components \u2014 the properties of which can be exploited to steal data. The theft<\/em> itself is not mind-blowing yet, but further research may well discover a more effective method. We hope that GPU developers will take this study into account and adapt their algorithms so that they don\u2019t leak sensitive information.<\/p>\n

The quality of this study should not be underestimated either. Forgetting all the practical difficulties for a moment, the researchers essentially demonstrated a method of remote data theft and took screenshots of secret information. All this was achieved through a detailed examination of a minor feature in the operation of GPUs \u2014 and manufacturers tend not to publicize anything about the operation of their CPUs. Still, it\u2019s an impressive piece of research \u2014 even if it has no practical consequences\u2026 for now.<\/p>\n","protected":false},"excerpt":{"rendered":"

We look at a new sophisticated attack on AMD and Intel integrated graphics cards.<\/p>\n","protected":false},"author":665,"featured_media":21758,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1318,1916,1917],"tags":[2663],"class_list":{"0":"post-21755","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-side-channel"},"hreflang":[{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/gpu-zip-attack\/21755\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/gpu-zip-attack\/26322\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/gpu-zip-attack\/28999\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/gpu-zip-attack\/26605\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/gpu-zip-attack\/36235\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/gpu-zip-attack\/49169\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/gpu-zip-attack\/26899\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/gpu-zip-attack\/32608\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/gpu-zip-attack\/32263\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/me-en.kaspersky.com\/blog\/tag\/side-channel\/","name":"side-channel"},"_links":{"self":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21755","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=21755"}],"version-history":[{"count":1,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21755\/revisions"}],"predecessor-version":[{"id":21757,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21755\/revisions\/21757"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/21758"}],"wp:attachment":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=21755"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=21755"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=21755"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}