Reptar-sårbarhet som påverkar Intel-processorer

Tavis Ormandy, en säkerhetsforskare på Google, har identifierat en ny sårbarhet (CVE-2023-23583) i Intel-processorer, kodnamnet Reptar, som främst utgör ett hot mot molnsystem som kör virtuella maskiner från olika användare. Sårbarheten gör att systemet hänger sig eller kraschar när vissa operationer utförs på oprivilegierade gästsystem. För att testa dina system har ett verktyg publicerats som skapar förutsättningar för manifestation av sårbarheter.

Teoretiskt sett kan sårbarheten användas för att eskalera privilegier från tredje till nollskyddsringen (CPL0) och fly från isolerade miljöer, men detta scenario har ännu inte bekräftats i praktiken på grund av svårigheterna med att felsöka på mikroarkitektonisk nivå. En intern granskning hos Intel visade också potentialen för utnyttjande av sårbarheten för att eskalera privilegier under vissa förhållanden.

Enligt forskaren finns sårbarheten i processorfamiljerna Intel Ice Lake, Rocket Lake, Tiger Lake, Raptor Lake, Alder Lake och Sapphire Rapids. Intel-rapporten nämner att problemet uppstår från den 10:e generationen (Ice Lake) av Intel Core-processorer och den tredje generationen av Xeon Scalable-processorer, såväl som i Xeon E/D/W-processorer (Ice Lake, Skylake, Haswell, Broadwell , Skylake, Sapphire Rapids, Emerald Rapids, Cascade Lake, Cooper Lake, Comet Lake, Rocket Lake) och Atom (Apollo Lake, Jasper Lake, Arizona Beach, Alder Lake, Parker Ridge, Snow Ridge, Elkhart Lake och Denverton). Sårbarheten i fråga åtgärdades i gårdagens mikrokoduppdatering 20231114.

Sårbarheten orsakas av det faktum att exekveringen av "REP MOVSB"-instruktionen under vissa mikroarkitektoniska omständigheter kodas med ett överdrivet "REX"-prefix, vilket leder till odefinierat beteende. Problemet upptäcktes under testning av redundanta prefix, vilket i teorin bör ignoreras, men ledde i praktiken till konstiga effekter, som att ignorera ovillkorliga grenar och bryta pekarens sparande i xsave- och anropsinstruktionerna. Ytterligare analys visade att lägga till ett redundant prefix till "REP MOVSB"-instruktionen orsakar korruption av innehållet i ROB-bufferten (ReOrder Buffer) som används för att beställa instruktioner.

Det antas att felet orsakas av en felaktig beräkning av storleken på "MOVSB" -instruktionen, vilket leder till brott mot adresseringen av instruktioner skrivna till ROB-bufferten efter MOVSB ​​med ett överdrivet prefix och offset av instruktionspekaren. Sådan desynkronisering kan begränsas till störningar av mellanliggande beräkningar med efterföljande återställande av integraltillståndet. Men om du kraschar flera kärnor eller SMT-trådar samtidigt, kan du skada det mikroarkitektoniska tillståndet tillräckligt för att krascha.

Källa: opennet.ru

Lägg en kommentar