SIKKERHET

Spekulativt: Google og Microsoft har funnet en fjerde prosessorsårbarhet

Kan avsløre passord og annen sensitiv informasjon via nettleseren.

Spekulativ funksjonalitet i prosessorer kan gjøre det mulig for ondsinnet programvare å lese data som tilhører annen programvare.
Spekulativ funksjonalitet i prosessorer kan gjøre det mulig for ondsinnet programvare å lese data som tilhører annen programvare. Illustrasjon: Red Hat
Harald BrombachHarald BrombachNyhetsleder
22. mai 2018 - 14:48

Sikkerhetsforskere hos Google og Microsoft har uavhengig av hverandre funnet enda en alvorlig sårbarhet i prosessorer fra AMD, ARM, Intel og IBM. Denne kalles for Speculative Store Bypass (SSB) og er en variant av de allerede kjente Meltdown- og Spectre-sårbarhetene, da den finnes i prosessorenes spekulative funksjonalitet (vi kommer tilbake til hva dette er litt lenger ned). 

Sårbarheten (CVE-2018-3639) kan i utgangspunktet utnyttes via moderne nettlesere, som har støtte for Just-in-Time-kompilering av JavaScript, noe som genererer systemspesifikk kode. 

Koordinert avsløring

Sikkerhetsforskerne har koordinert offentliggjøringen av detaljer om sårbarhetene i samarbeid med blant annet leverandører av prosessorer, operativsystemer og nettlesere for å redusere faren for utnyttelse av SSB-sårbarheten.

Ifølge Microsoft skal både Internet Explorer, Edge og andre mye brukte nettlesere allerede ha blitt utstyrt med sikkerhetsfikser som i alle fall gjøre det vanskeligere å utnytte SSB-sårbarheten. 

I tillegg skal det komme sikkerhetsfikser på både operativsystem- og mikrokodenivå. Intel opplyser at betautgaver av kommende mikrokodeoppdateringer har blitt sendt ut til mange systemleverandører og andre i partnere i økosystemet. Oppdateringen gir prosessorene støtte for det som kalles for Speculative Store Bypass Disable (SSBD), noe som skal forhindre utnyttelse av SSB-sårbarheten. 

Ikke bare Intel

Også AMD, ARM og IBM har publisert informasjon om i hvilken grad SSB berører selskapenes respektive prosessor- og kjerneprodukter. I stor grad berører sårbarhetene alle prosessorkjerner som støtter at instruksjoner kjøres utenom rekkefølge («out-of-order»).  Det skal likevel bare være en håndfull av ARMs Cortex-kjerner som er berørt. 

I tillegg kommer muligens ARM-baserte prosessorkjerner fra en rekke andre leverandører. 

Spekulativt

Selv sårbarheten er også denne gang knyttet til hvordan prosessorer forsøker å spekulere i hva et program kommer til å gjøre litt lenger fram i kjøringen, for så å finne fram eller beregne verdier på forhånd, slik at disse ligger klare når det eventuelt blir bruk for dem. 

Dersom prosessoren «gjetter» riktig, kan dette gi en betydelig ytelsesforbedring.

Under kjøringen kan en prosessor utføre mange lese- og skriveinstruksjoner (egentlig load og store) som opererer mot samme minneadresse. Dersom det ligger både lese- og skriveinstruksjoner i instruksjonskøen, vil i utgangspunktet alle skriveinstruksjonene utføres først, slik at leseinstruksjonene mottar helt oppdaterte data. 

Men for å gjør det hele mer effektivt, siden det tar tid å utføre leseinstruksjoner, forsøker moderne prosessorer å finne ut hvilke leseinstruksjoner som ikke avhenger av skriveinstruksjoner som ligger foran i køen, for så å utføre leseinstruksjonene allerede før adressene til de foregående skriveinstruksjonene er kjent for prosessoren.

Speculative Store Buffer

Disse spekulativt leste verdiene lagres i et bufferminne (Speculative Store Buffer) hvor de ikke alltid er godt beskyttet mot tilgang fra andre prosesser. Det gjør det potensielt mulig for ikke-autoriserte brukere å se hva som ligger i dette bufferminnet, ved å narre prosessoren til å tro at den leser fra én adresse, mens den i virkeligheten leser fra en annen adresse. 

Alt mulig av data kan ligge i dette bufferminnet, inkludert sensitiv informasjon som passord og kredittkortnummer.

Red Hat har publisert flere detaljer om hvordan det hele fungerer på denne siden. I tillegg har selskapet utgitt videoen nedenfor, som forklarer sårbarheten ved hjelp av en analogi hentet fra restaurantbransjen.

Artikkelen fortsetter etter annonsen
annonse
Innovasjon Norge
På trappene til internasjonal suksess
På trappene til internasjonal suksess

Ytelsestap

Den enkleste måten å forhindre utnyttelse av sårbarhetene, er ifølge Red Hat å skru av hele den spekulative funksjonaliteten. Men dette vil få dramatiske konsekvenser for ytelsen, uten at det nødvendigvis bidrar til svært mye bedre sikkerhet. Applikasjoner som benytter isolasjon på prosessnivå mellom tiltrodd og ikke-tiltrodd kode, er nemlig ikke berørt av denne sårbarheten. 

Red Hat omtaler derfor en rekke ulike nivåer av beskyttelse mot utnyttelse av SSB-sårbarheten, hvorav flere er på applikasjonsnivå. I tillegg skal det i alle fall i Linux-kjernen innføres en ny parameter, «speculative_store_bypass_disable». Dermed kan systemadministratorer rett og slett deaktivere Speculative Store Buffer Bypassing-funksjonaliteten til hele systemet, dersom dette er ønskelig.

Mikrokodeoppdateringene vil uansett medføre et ytelsestap, men bare for visse operasjoner, og ikke i like stor grad som sikkerhetsfiksene for Spectre og Meltdown. Ifølge Intel vil ytelsesreduksjonen være på mellom 3 og 8 prosent i visse ytelsestester.

Fordi SSB-sårbarheten har visse fellestrekk med Spectre 1-sårbarheten, skal sikkerhetsfikser som beskytter mot Spectre 1-angrep, også gjøre det vanskeligere å utnytte SSB-sårbarheten. 

Variant 3a

I tillegg til SSB-sårbarheten, som også kalles for Variant 4, skal i alle fall Intel utgi mikrokodeoppdateringer som beskytter mot utnyttelse av det som kalles for Variant 3a eller Rogue System Register Read eller CVE-2018-3640. Denne sårbarheten kan åpne for angrep hvor angriper med lokal brukertilgang kan avsløre visse systemparametere.

Også noen få av ARMs Cortex-kjerner er berørt av Variant 3a. Det har så langt ikke blitt funnet AMD-prosessorer som er berørt av denne sårbarheten.

Det er ikke kjent at nevnte sårbarhetene har blitt utnyttet i faktiske angrep, men det kan heller ikke utelukkes.

Del
Kommentarer:
Du kan kommentere under fullt navn eller med kallenavn. Bruk BankID for automatisk oppretting av brukerkonto.