Googles sikkerhedsforsker Tavis Ormandy har identificeret en ny sårbarhed (CVE-2023-23583) i Intel-processorer, kodenavnet Reptar, som primært udgør en trussel mod cloud-systemer, der kører virtuelle maskiner til forskellige brugere. Sårbarheden gør det muligt for systemet at hænge eller gå ned, når der udføres visse handlinger i uprivilegerede gæstesystemer. Der er udgivet et hjælpeprogram til at teste deres systemer, hvilket skaber betingelser for, at sårbarhed kan manifestere sig.
Teoretisk set kunne sårbarheden bruges til at eskalere privilegier fra den tredje til nul beskyttelsesring (CPL0) og undslippe isolerede miljøer, men dette scenarie er endnu ikke blevet bekræftet i praksis på grund af vanskelighederne med at fejlfinde på mikroarkitektonisk niveau. En intern gennemgang hos Intel fandt også ud af, at sårbarheden potentielt kunne udnyttes til at hæve privilegier under visse forhold.
Ifølge forskeren er sårbarheden til stede i processorfamilierne Intel Ice Lake, Rocket Lake, Tiger Lake, Raptor Lake, Alder Lake og Sapphire Rapids. Intels rapport nævner, at problemet påvirker 10. generations (Ice Lake) Intel Core og 20231114. generations Xeon Scalable-processorer, samt Xeon E/D/W (Ice Lake, Skylake, Haswell, Broadwell, Skylake, Sapphire Rapids, Emerald Rapids, Cascade Lake, Cooper Lake, Comet Lake, Rocket A Lake, Arizona Lake, Rocket A, Lake, Ridder Lake , Snow Ridge, Elkhart Lake og Denverton) processorer. Den pågældende sårbarhed blev rettet i gårsdagens mikrokodeopdatering XNUMX.
Sårbarheden er forårsaget af, at udførelsen af "REP MOVSB"-instruktionen under visse mikroarkitektoniske omstændigheder er kodet med et redundant "REX"-præfiks, hvilket fører til udefineret adfærd. Problemet blev opdaget under test af redundante præfikser, som teoretisk set burde ignoreres, men som i praksis resulterede i mærkelige effekter, såsom ignorering af ubetingede hop og breaking pointer-lagring i xsave og call instruktioner. Yderligere analyse viste, at tilføjelse af et ekstra præfiks til REP MOVSB-instruktionen forårsager korruption af indholdet af den ROB (ReOrder Buffer), der bruges til at bestille instruktioner.
Fejlen menes at være forårsaget af forkert beregning af størrelsen af "MOVSB" instruktionen, hvilket resulterer i forkert adressering af instruktioner skrevet til ROB bufferen efter MOVSB med et for højt præfiks og en offset af instruktionsmarkøren. En sådan desynkronisering kan være begrænset til en overtrædelse af mellemliggende beregninger med efterfølgende genoprettelse af den integrale tilstand. Men hvis du crasher med flere kerner eller SMT-tråde på én gang, kan du forårsage nok mikroarkitektonisk korruption til at forårsage et nedbrud.
Kilde: opennet.ru
