Spectre - en gruppe hardwaresårbarheder , en fejl i de fleste moderne processorer, der har spekulativ instruktionsudførelseog avanceret brancheforudsigelse , der gør det muligt at læse data gennem en tredjepartskanal i form af et fælles cachehierarki . Påvirker de fleste moderne mikroprocessorer, især x86/x86_64-arkitekturer (Intel og AMD) og nogle ARM- processorkerner [1] .
Sårbarheden tillader potentielt lokale applikationer (en lokal hacker, når de kører et specielt program) at få adgang til indholdet af den virtuelle hukommelse i den aktuelle applikation eller andre programmer [2] [3] [4] . Truslen er blevet tildelt to CVE - identifikatorer: CVE-2017-5753 og CVE-2017-5715 .
Spectre blev opdaget uafhængigt af forskere ved den nordamerikanske virksomhed Google ( Project Zero ) og en gruppe, der samarbejdede med Paul Kocher, med deltagelse af medarbejdere fra Graz University of Technology . Sårbarheden blev fundet i midten af 2017 og var under lukket diskussion og rettelse i flere måneder. Offentliggørelsen af detaljer og rettelser var planlagt til den 9. januar 2018, men detaljerne om sårbarheden blev offentliggjort den 4. januar 2018 samtidig med Meltdown- angrebet , på grund af udgivelser fra The Register [5] journalister , der lærte om KAISER/KPTI-rettelserne for at bekæmpe Meltdown fra Linux-kernens mailingliste [6] .
Spectre-fejlen tillader ondsindede brugerapplikationer, der kører på en given computer, at få læseadgang til vilkårlige steder i computerens hukommelse , der bruges af offerprocessen, såsom andre applikationer (dvs. bryde hukommelsesisolation mellem programmer). Spectre-angrebet påvirker de fleste computersystemer, der bruger højtydende mikroprocessorer, inklusive personlige computere, servere, bærbare computere og en række mobile enheder [7] . Spectre-angrebet blev især demonstreret på processorer fremstillet af Intel- og AMD- selskaber og på chips ved hjælp af ARM- processorkerner .
Der er en variant af Spectre-angrebet, der bruger JavaScript-programmer til at få adgang til browseres hukommelse (læser data fra andre websteder eller data gemt i browseren) [8] .
Lad os antage, at kodestykket af offerprocessen
if ( x < array1_size ) y = matrix2 [ matrix1 [ x ] * 256 ];er en del af en funktion, der modtager et usigneret heltal x fra en kilde, der ikke er tillid til, og processen, der udfører denne kode, har adgang til et array af usignerede 8-bit heltal array1 af størrelse array1_size , og et andet array af usignerede 8-bit heltal array2 af størrelse 64 kb.
Dette uddrag starter med at kontrollere, at x er en gyldig værdi. Og denne kontrol er essentiel ud fra et sikkerhedsmæssigt synspunkt. Det forhindrer især læsning af information ud over grænserne for array1 . I dets fravær kan ugyldige x -værdier enten give en undtagelse, når du forsøger at læse data uden for processens tilgængelige hukommelse, eller læse procestilgængelige fortrolige oplysninger ved at specificere x = <secret_byte_address> - <array1_address_array1> .
Desværre kan fejlforudsigelsen af en betinget gren i spekulativ udførelse af instruktioner føre til eksekvering af en gren af programkoden, som under normale forhold aldrig ville blive eksekveret [9] .
For eksempel kan kodestykket ovenfor udføres under følgende betingelser:
Sådanne forhold kan opstå spontant, men de kan også dannes målrettet, for eksempel ved at læse en stor mængde uvedkommende data for at fylde processorcachen med disse data og dermed slå array1_size og array2 ud af cachen, og kald derefter kernefunktionen, der bruger den hemmelige byte k , for at cache den. Men hvis cachestrukturen er kendt, eller processoren frivilligt giver en cache-nulstillingsinstruktion (for eksempel cflush- instruktionen for x86 - familieprocessorer ), så er opgaven med at skabe de nødvendige betingelser for at udføre et kodefragment meget forenklet.
Kodestykket starter med at sammenligne værdien af x med værdien af array1_size . Aflæsning af værdien af array1_size under de ovenfor beskrevne betingelser vil resultere i en cache-miss, som igen vil resultere i, at man venter på, at værdien af array1_size bliver hentet fra RAM. På grund af tilstedeværelsen af en spekulativ instruktionsudførelsesmekanisme i processoren vil processoren i ventetiden ikke inaktiv, men vil forsøge at udføre en af programkodens grene efter greninstruktionen.
Da tidligere adgange til fragmentet blev udført med gyldige værdier på x , vil grenprædiktoren antage, at denne gang vil prædikatet (x < array1_size) være sandt, og processoren vil forsøge at udføre den tilsvarende sekvens af instruktioner. Den vil nemlig læse byten ved <array1_address> + x , det vil sige den hemmelige byte k , som takket være specielt dannede betingelser allerede er i cachen. Derefter bruger processoren den resulterende værdi til at evaluere udtrykket k * 256 og læse elementet af array2[k * 256] , hvilket vil resultere i en anden cache-miss, og vente på, at værdien af array2[k * 256] bliver hentet fra RAM. På dette tidspunkt vil værdien af array1_size blive hentet fra RAM'en , processoren vil genkende fejlen i grenprædiktoren og genoprette den arkitektoniske tilstand til tidspunktet før starten af udførelsen af den forkerte gren af programkoden.
På rigtige processorer vil en spekulativ læsning af array2[k * 256] imidlertid påvirke tilstanden af processorens cache, og denne tilstand vil afhænge af k . For at fuldføre angrebet er det kun nødvendigt at detektere denne ændring ved hjælp af et sidekanalangreb (angriberen skal have adgang til den delte processorcache og den nøjagtige tidskilde), og baseret på den beregne den hemmelige byte k . Dette er nemt at gøre, da læsning af elementerne i matrix2[n * 256] vil være hurtig for n = k og langsom for andre værdier.
En indirekte filial kan bruge mere end to adresser til at forgrene sig. For eksempel kan x86 -familie -processorinstruktioner springe ved hjælp af en adresseværdi i et register ( jmp eax ), i hukommelsen ( jmp [eax] eller jmp dword ptr [0xdeadc0de] ) eller på stakken ( ret ). Indirekte springinstruktioner findes også i ARM ( mov pc, r14 ), MIPS ( jr $ra ), SPARC ( jmpl %o7 ), RISC-V ( jarl x0,x1,0 ) og mange andre.
Hvis bestemmelse af en indirekte grenadresse forsinkes på grund af en cache-miss, og den indirekte grenprædiktor er "trænet" med specielt valgte adresser, kan spekulativ udførelse af instruktioner på adressen givet af angriberen forekomme. Kommandoer, der ellers aldrig ville være blevet udført. Hvis en sådan præstation efterlader målbare bivirkninger , bliver brugen af den et kraftfuldt værktøj i hænderne på angriberen.
I øjeblikket er der ingen færdiglavede softwareteknologier til at beskytte mod Spectre-angrebet, selvom der arbejdes lidt [10] . Ifølge et websted, der er dedikeret til at promovere angrebet, "er det ikke så nemt at rette, og det (fejlen) vil hjemsøge os i lang tid."
En softwarefix kan omfatte genkompilering af softwaren ved hjælp af nye compilere til at erstatte sårbare maskinkodesekvenser (den såkaldte "retpoline"-mekanisme, implementeret i GCC og Clang / LLVM ) [11] .
Adskillige rettelser er blevet foreslået af processorproducenter, nogle kræver opdatering af processorens mikrokode, andre kræver, at der tilføjes nye instruktioner til fremtidige processorer. Rettelser bør kombineres med softwaregenkompilering [11] .
I tidlige versioner af Spectre CVE-meddelelsen foreslog CERT at udskifte processorer som en reaktion på sårbarheden: "Sårbarheden er forårsaget af valg i mikroprocessordesign. Fuldstændig fjernelse af sårbarheden kræver udskiftning af berørte mikroprocessorer." Men i efterfølgende tekster blev denne version af rettelsen ikke længere nævnt [11] .