{"id":182817,"date":"2026-08-10T19:49:35","date_gmt":"2026-08-10T17:49:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/tontou-ataka-na-cpu-intel-i-amd-pozvolyayushhaya-obojti-zashhitu-ot-uyazvimostej-spectre-v2"},"modified":"2026-08-10T19:49:35","modified_gmt":"2026-08-10T17:49:35","slug":"tontou-ataka-na-cpu-intel-i-amd-pozvolyayushhaya-obojti-zashhitu-ot-uyazvimostej-spectre-v2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/tontou-ataka-na-cpu-intel-i-amd-pozvolyayushhaya-obojti-zashhitu-ot-uyazvimostej-spectre-v2","title":{"rendered":"TONTOU \u2014 attacco alla CPU Intel e AMD, che consente di bypassare la protezione dalle vulnerabilit\u00e0 Spectre v2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
I ricercatori del Massachusetts Institute of Technology hanno identificato la tecnica di attacco TONTOU (Time-of-Neutralization to Time-of-Use), che offre un nuovo modo per sfruttare vulnerabilit\u00e0 microarchitettoniche di tipo Spectre v2. La vulnerabilit\u00e0 consente di determinare il contenuto della memoria del kernel durante l'esecuzione di un exploit nello spazio utente. Il codice per bloccare lo sfruttamento della vulnerabilit\u00e0 \u00e8 stato integrato nel kernel Linux il 5 agosto ed \u00e8 incluso nelle versioni 7.1.7, 6.18.43, 6.12.102, 6.6.149, 6.1.181, 5.15.214 e 5.10.263. <\/p>\n
I ricercatori hanno dimostrato la possibilit\u00e0 di un attacco da parte di un utente locale non privilegiato per determinare l'hash della password dell'utente root, memorizzata nel file \/etc\/shadow e caricata in memoria durante l'autenticazione nel sistema. I ricercatori sono riusciti ad ottenere una fuoriuscita di dati dalla memoria del kernel con una velocit\u00e0 di 5,47 byte al secondo e una precisione del 91,97%. Su 10 esecuzioni dell'exploit, durate in media 18 minuti, in met\u00e0 dei casi \u00e8 stato possibile identificare con successo la presenza nella memoria del file \/etc\/shadow ed estrarne il contenuto. <\/p>\n
L'exploit \u00e8 stato dimostrato su sistemi con processori AMD e pu\u00f2 essere applicato con CPU AMD delle famiglie Zen 1-4. Su sistemi Intel, l'attacco \u00e8 comunque realizzabile, ma lo sfruttamento \u00e8 pi\u00f9 complesso. Per proteggere da overflow dello stack degli indirizzi di ritorno e bloccare la vulnerabilit\u00e0 SRSO (Speculative Return Stack Overflow) nei processori AMD viene utilizzato un meccanismo di protezione Safe-RET, che pulisce il buffer di previsione dei salti dopo ogni utilizzo e restringe la finestra di attacco a 2 istruzioni, eseguite in un paio di decine di nanosecondi. <\/p>\n
Per aggirare questa protezione e ampliare la finestra di attacco, \u00e8 stata implementata una tecnica di rallentamento della CPU, che ha permesso di eseguire la sostituzione dell'interruzione al momento giusto per reindirizzare il flusso di esecuzione nel kernel e utilizzare il gestore delle interruzioni per alterare la registrazione nel buffer delle predizioni di salto. Per sfruttare la vulnerabilit\u00e0 SRSO, l'attaccante pu\u00f2 creare condizioni in cui il blocco di predizione dei salti esegue speculativamente un gran numero di chiamate CALL errate, sufficienti a sovraccaricare lo stack degli indirizzi di ritorno e sovrascrivere i punti di ritorno correttamente previsti, posizionati all'inizio dello stack. Di conseguenza, gli elementi iniziali dello stack possono essere sovrascritti con valori scelti dall'attaccante, portando all'utilizzo di questi valori sostituiti durante l'esecuzione speculativa dell'istruzione RET nel contesto di un altro processo. <\/p>\n
Il processore riconoscer\u00e0 che la previsione del ramo non si \u00e8 avverata e annuller\u00e0 l'operazione allo stato originale, ma i dati elaborati durante l'esecuzione speculativa rimarranno nel cache e nei buffer microarchitettonici. Se il blocco eseguito erroneamente accede alla memoria, la sua esecuzione speculativa porter\u00e0 all'accumulo nel cache generale e dei dati letti dalla memoria. Per estrarre informazioni dal cache pu\u00f2 essere utilizzato uno dei metodi basati sull'analisi delle variazioni dei tempi di accesso ai dati in cache e non in cache. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"