Vulnerabilità Reptar che colpisce i processori Intel

Tavis Ormandy, un ricercatore di sicurezza di Google, ha identificato una nuova vulnerabilità (CVE-2023-23583) nei processori Intel, nome in codice Reptar, che rappresenta una minaccia principalmente per i sistemi cloud che eseguono macchine virtuali di diversi utenti. La vulnerabilità consente al sistema di bloccarsi o bloccarsi quando determinate operazioni vengono eseguite su sistemi guest non privilegiati. Per testare i vostri sistemi è stata pubblicata un'utilità che crea le condizioni per la manifestazione delle vulnerabilità.

Teoricamente la vulnerabilità può essere utilizzata per escalare i privilegi dal terzo all'anello di protezione zero (CPL0) e uscire da ambienti isolati, ma questo scenario non è stato ancora confermato nella pratica a causa delle difficoltà di debug a livello microarchitetturale. Una revisione interna presso Intel ha inoltre mostrato il potenziale di sfruttamento della vulnerabilità per aumentare i privilegi in determinate condizioni.

Secondo il ricercatore, la vulnerabilità è presente nelle famiglie di processori Intel Ice Lake, Rocket Lake, Tiger Lake, Raptor Lake, Alder Lake e Sapphire Rapids. Il rapporto Intel afferma che il problema si manifesta a partire dalla decima generazione (Ice Lake) di processori Intel Core e dalla terza generazione di processori Xeon Scalable, nonché nei processori Xeon E/D/W (Ice Lake, Skylake, Haswell, Broadwell , Skylake, Sapphire Rapids, Emerald Rapids, Cascade Lake, Cooper Lake, Comet Lake, Rocket Lake) e Atom (Apollo Lake, Jasper Lake, Arizona Beach, Alder Lake, Parker Ridge, Snow Ridge, Elkhart Lake e Denverton). La vulnerabilità in questione è stata risolta nell'aggiornamento del microcodice 10 di ieri.

La vulnerabilità è causata dal fatto che in determinate circostanze microarchitettoniche, l'esecuzione dell'istruzione "REP MOVSB" è codificata con un prefisso "REX" eccessivo, che porta a un comportamento indefinito. Il problema è stato scoperto durante il test dei prefissi ridondanti, che in teoria dovrebbero essere ignorati, ma in pratica hanno portato a strani effetti, come ignorare i rami incondizionati e interrompere il salvataggio del puntatore nelle istruzioni xsave e call. Ulteriori analisi hanno mostrato che l'aggiunta di un prefisso ridondante all'istruzione "REP MOVSB" provoca la corruzione del contenuto del buffer ROB (ReOrder Buffer) utilizzato per ordinare le istruzioni.

Si ritiene che l'errore sia causato da un errato calcolo della dimensione dell'istruzione "MOVSB", che porta alla violazione dell'indirizzamento delle istruzioni scritte nel buffer ROB dopo la MOVSB ​​con prefisso eccessivo, e dell'offset del puntatore dell'istruzione. Tale desincronizzazione può limitarsi all'interruzione dei calcoli intermedi con successivo ripristino dello stato integrale. Ma se si bloccano più core o thread SMT contemporaneamente, è possibile danneggiare lo stato della microarchitettura abbastanza da causare un arresto anomalo.

Fonte: opennet.ru

Aggiungi un commento