Google publicou varios prototipos de exploit que mostran a posibilidade de explotar vulnerabilidades da clase Spectre ao executar código JavaScript no navegador, evitando os métodos de protección engadidos anteriormente. Os exploits pódense usar para acceder á memoria do proceso que procesa o contido web na pestana actual. Para probar o funcionamento do exploit, lanzouse o sitio web leaky.page e publicouse en GitHub o código que describe a lóxica do traballo.
O prototipo proposto está deseñado para atacar sistemas con procesadores Intel Core i7-6500U nun ambiente con Linux e Chrome 88. Para usar o exploit noutros ambientes, son necesarias modificacións. O método de explotación non é específico dos procesadores Intel: despois da adaptación adecuada, confirmouse que o exploit funciona en sistemas con CPU doutros fabricantes, incluído o Apple M1 baseado na arquitectura ARM. Despois de pequenos axustes, o exploit tamén é viable noutros sistemas operativos e noutros navegadores baseados no motor Chromium.
Nun entorno baseado en procesadores estándar de Chrome 88 e Intel Skylake, foi posible filtrar datos do proceso encargado de procesar o contido web na pestana actual de Chrome (proceso de renderizado) a unha velocidade de 1 kilobyte por segundo. Ademais, desenvolvéronse prototipos alternativos, por exemplo, unha explotación que permite, a costa de reducir a estabilidade, aumentar a taxa de fuga a 8 kB/s cando se utiliza o temporizador performance.now() cunha precisión de 5 microsegundos (0.005 milisegundos). ). Tamén se preparou unha versión que funcionaba cunha precisión de temporizador dun milisegundo, que podía utilizarse para organizar o acceso á memoria doutro proceso a unha velocidade duns 60 bytes por segundo.
O código de demostración publicado consta de tres partes. A primeira parte calibra o temporizador para estimar o tempo de execución das operacións necesarias para restaurar os datos que quedan na caché do procesador como resultado da execución especulativa das instrucións da CPU. A segunda parte determina a disposición da memoria utilizada ao asignar a matriz JavaScript.
A terceira parte explota directamente a vulnerabilidade Spectre para determinar o contido da memoria do proceso actual como resultado da creación de condicións para a execución especulativa de determinadas operacións, cuxo resultado é descartado polo procesador despois de determinar unha predición non exitosa, pero os rastros da a execución deposítanse na caché xeral e pódense restaurar mediante métodos para determinar o contido da caché por canles de terceiros que analizan os cambios no tempo de acceso aos datos en caché e non.
A técnica de explotación proposta permite prescindir de temporizadores de alta precisión dispoñibles a través da API performance.now() e sen soporte para o tipo SharedArrayBuffer, que permite crear matrices na memoria compartida. O exploit inclúe o gadget Spectre, que provoca a execución especulativa controlada do código, e un analizador de fugas de canles laterales, que detecta os datos almacenados na caché obtidos durante a execución especulativa.
O gadget está implementado mediante unha matriz JavaScript na que se intenta acceder a unha área fóra dos límites do búfer, afectando o estado do bloque de predición de rama debido á presenza dunha comprobación do tamaño do búfer engadido polo compilador (o procesador realiza especulativamente o acceder antes de tempo, pero retrotrae o estado despois de verificalo). Para analizar o contido da caché en condicións de precisión do temporizador insuficiente, propúxose un método que engana a estratexia de expulsión da caché Tree-PLRU empregada nos procesadores e que permite, ao aumentar o número de ciclos, aumentar significativamente a diferenza de tempo á hora de retornar. un valor da caché e cando non hai ningún valor na caché.
Nótase que Google publicou un prototipo do exploit co fin de mostrar a viabilidade dos ataques utilizando vulnerabilidades da clase Spectre e para animar aos desenvolvedores web a utilizar técnicas que minimicen os riscos deste tipo de ataques. Ao mesmo tempo, Google cre que sen unha reelaboración significativa do prototipo proposto, é imposible crear exploits universais que estean listos non só para a demostración, senón tamén para o seu uso xeneralizado.
Para reducir o risco, recoméndase aos propietarios dos sitios que utilicen as cabeceiras implementadas recentemente: Política de apertura cruzada (COOP), Política de incrustación de orixes cruzadas (COEP), Política de recursos entre orixes (CORP), Solicitude de obtención de metadatos, X-Frame- Opcións, X -Content-Type-Options e SameSite Cookie. Estes mecanismos non protexen directamente contra ataques, pero permiten illar os datos do sitio da fuga en procesos nos que se pode executar o código JavaScript do atacante (a fuga prodúcese desde a memoria do proceso actual, que ademais do código do atacante). , tamén pode procesar datos doutro sitio aberto nesa mesma pestana). A idea principal é separar a execución do código do sitio en diferentes procesos do código de terceiros recibido de fontes pouco fiables, por exemplo, incluído a través dun iframe.
Fonte: opennet.ru