Googles sikkerhetsforsker Tavis Ormandy har identifisert en ny sårbarhet (CVE-2023-23583) i Intel-prosessorer, med kodenavnet Reptar, som primært utgjør en trussel mot skysystemer som kjører virtuelle maskiner som tilhører forskjellige brukere. Sårbarheten kan føre til at systemet henger eller krasjer når visse operasjoner utføres i uprivilegerte gjestesystemer. Et verktøy som skaper betingelser for utnyttelse, er publisert for testformål.
Teoretisk sett kan sårbarheten utnyttes til å eskalere rettigheter fra ring 3 til ring 0 (CPL0) og unnslippe isolerte miljøer, men dette scenariet er ennå ikke bekreftet i praksis på grunn av vanskeligheter med feilsøking på mikroarkitekturnivå. Intern testing hos Intel viste også potensialet for utnyttelse av sårbarheten til eskalering av rettigheter under visse forhold.
Ifølge forskeren påvirker sårbarheten Intel-prosessorene Ice Lake, Rocket Lake, Tiger Lake, Raptor Lake, Alder Lake og Sapphire Rapids. Intels rapport bemerker at problemet påvirker 10. generasjons (Ice Lake) Intel Core-prosessorer og tredje generasjons Xeon Scalable-prosessorer, samt Xeon E/D/W-prosessorer (Ice Lake, Skylake, Haswell, Broadwell, Skylake, Sapphire Rapids, Emerald Rapids, Cascade Lake, Cooper Lake, Comet Lake, Rocket Lake) og Atom-prosessorer (Apollo Lake, Jasper Lake, Arizona Beach, Alder Lake, Parker Ridge, Snow Ridge, Elkhart Lake og Denverton). Sårbarheten ble rettet i gårsdagens mikrokodeoppdatering 20231114.
Sårbarheten skyldes en bestemt mikroarkitektonisk tilstand der utførelsen av instruksjonen «REP MOVSB» er kodet med et redundant «REX»-prefiks, noe som fører til udefinert oppførsel. Problemet ble oppdaget under testing av redundante prefikser, som teoretisk sett burde ignoreres, men som i praksis førte til merkelige effekter, som å ignorere ubetingede hopp og forstyrre pekerlagring i xsave- og call-instruksjoner. Videre analyse viste at det å legge til et redundant prefiks i instruksjonen «REP MOVSB» ødelegger innholdet i ROB (ReOrder Buffer), som brukes til rekkefølge av instruksjoner.
Feilen antas å være forårsaket av en feil beregning av MOVSB-instruksjonsstørrelsen, noe som fører til en forstyrrelse i adresseringen av instruksjoner skrevet til ROB-bufferen etter MOVSB med et for høyt prefiks, og en feiljustering av instruksjonspekeren. Denne desynkroniseringen kan være begrenset til å forstyrre mellomliggende beregninger med påfølgende gjenoppretting av en konsistent tilstand. Men hvis krasjet utløses samtidig på flere kjerner eller SMT-tråder, kan det forårsake tilstrekkelig mikroarkitekturell korrupsjon til å forårsake et krasj.
Kilde: opennet.ru
