Ang isang pangkat ng mga mananaliksik mula sa ilang mga unibersidad sa US ay bumuo ng isang bagong side-channel attack technique na nagbibigay-daan sa kanila na muling likhain ang visual na impormasyong naproseso sa GPU. Gamit ang iminungkahing paraan, na tinatawag na GPU.zip, matutukoy ng isang attacker ang impormasyong ipinapakita sa screen. Sa iba pang mga bagay, ang pag-atake ay maaaring isagawa sa pamamagitan ng isang web browser, halimbawa, ang pagpapakita kung paano ang isang nakakahamak na web page na binuksan sa Chrome ay makakakuha ng impormasyon tungkol sa mga pixel na ipinapakita kapag nag-render ng isa pang web page na binuksan sa parehong browser.
Ang pinagmulan ng pagtagas ng impormasyon ay ang pag-optimize na ginagamit sa mga modernong GPU na nagbibigay ng compression ng graphic na data. Ang problema ay nangyayari kapag gumagamit ng compression sa lahat ng pinagsamang GPU na nasubok (AMD, Apple, ARM, Intel, Qualcomm) at NVIDIA discrete graphics card. Kasabay nito, natuklasan ng mga mananaliksik na ang pinagsamang Intel at AMD GPU ay palaging nagpapagana ng graphics data compression, kahit na ang application ay hindi partikular na humiling ng paggamit ng naturang pag-optimize. Ang paggamit ng compression ay nagiging sanhi ng DRAM na trapiko at pag-load ng cache upang maiugnay sa likas na katangian ng data na pinoproseso, na maaaring i-reconstruct na pixel-by-pixel sa pamamagitan ng side-channel analysis.
Ang pamamaraan ay medyo mabagal, halimbawa, sa isang system na may pinagsamang AMD Ryzen 7 4800U GPU, isang pag-atake upang matukoy ang pangalan kung saan nag-log in ang user sa Wikipedia sa isa pang tab ay tumagal ng 30 minuto at pinapayagan ang mga nilalaman ng mga pixel na matukoy na may 97% na katumpakan. Sa mga system na may pinagsamang Intel i7-8700 GPU, ang isang katulad na pag-atake ay tumagal ng 215 minuto na may katumpakan na 98%.
Kapag nagsasagawa ng isang pag-atake sa pamamagitan ng isang browser, ang target na site ay umiikot sa isang iframe upang simulan ang pag-render. Upang matukoy ang impormasyong ipapakita, ang output ng iframe ay iko-convert sa isang itim-at-puting representasyon, kung saan inilalapat ang isang SVG filter, na nagsasagawa ng sunud-sunod na overlay ng mga maskara na nagpapakilala at hindi nagpapakilala ng maraming redundancy sa panahon ng compression. Batay sa isang pagtatasa ng mga pagbabago sa oras ng pagguhit ng mga sample ng sanggunian, ang pagkakaroon ng madilim o maliwanag na mga pixel sa isang partikular na posisyon ay naka-highlight. Ang pangkalahatang imahe ay muling binuo sa pamamagitan ng sunud-sunod na pixel-by-pixel na inspeksyon gamit ang mga katulad na maskara.
Ang mga tagagawa ng GPU at browser ay naabisuhan tungkol sa problema noong Marso, ngunit wala pang nagtitinda na gumawa ng isang pag-aayos, dahil ang pag-atake ay kaduda-dudang sa pagsasanay sa ilalim ng hindi mainam na mga kondisyon at ang problema ay higit na teoretikal na interes. Hindi pa napagpasyahan ng Google kung haharangan ang pag-atake sa antas ng browser ng Chrome. Mahina ang Chrome dahil pinapayagan nito ang pag-load ng iframe mula sa isa pang site nang hindi kine-clear ang Cookie, pinapayagan ang mga filter ng SVG na mailapat sa iframe, at mga delegado na nagre-render sa GPU. Ang Firefox at Safari ay hindi apektado ng kahinaan dahil hindi nila natutugunan ang mga pamantayang ito. Ang pag-atake ay hindi rin nalalapat sa mga site na nagbabawal sa pag-embed sa pamamagitan ng iframe sa iba pang mga site (halimbawa, sa pamamagitan ng pagtatakda ng X-Frame-Options HTTP header sa halagang βSAMEORIGINβ o βDENYβ, gayundin sa pamamagitan ng mga setting ng pag-access gamit ang Content -Security-Policy header ).
Pinagmulan: opennet.ru