Hårdvarusäkerhet – den lägsta säkerhetsnivån

Säkerhet handlar inte bara om programvara. Hårdvarudelarna som CPU eller minne på moderna enheter kan också vara sårbara.

Hårdvarusäkerhet är ett framväxande problem eftersom det finns fler och fler enheter runt omkring oss. Fler och fler enheter som ansluter till resten av världen. Fler och fler enheter som inte är tillräckligt komplicerade för att motivera en helt sprängd dator. Tänk bara på hemautomation, intelligenta ljusbrytare, värme, dörrlås, säkerhetskameror. Även vanliga leksaker blir intelligenta. Ändå saknar dessa enheter väsentlig säkerhet, medan de kan ha vissa resurser som lockar angripare. Så precis som alla andra datorsystem måste de designas och implementeras med säkerhet i åtanke.

Vet du vad din CPU gör?

Långt borta är de tider då en transistorradio endast innehöll ett par fristående transistorer, motstånd, kondensatorer och spolar. Modern hårdvara består av miljoner och miljarder integrerade element.

Medan de första kretsarna – som de transistorradioapparater som såldes på 50-talet – innehöll mindre än 10 transistorer, innehöll Intel 4004-processorn som släpptes 1971 2250 transistorer, 8080 som släpptes 1978 innehöll cirka 29 tusen och den ökända Pentium-processorn släpptes under 1993. 3 miljoner. Men som alltid, med stor makt kommer ett stort ansvar. Mer komplexitet – oavsett om det är hårdvara eller mjukvara – ger fler möjligheter att göra fel. Och detta ger hårdvarusäkerhet på bordet. För att citera den välkända Murphys lagar: ”Allt som kan gå fel kommer att gå fel”.

Det första hårdvaruproblemet som kom upp i rubrikerna 1994 var FDIV-felet som fanns i de tidiga versionerna av 60–100 MHz P5 Pentiums från Intel. Denna bugg orsakades av att några saknade värden i en uppslagstabell resulterade i felaktiga resultat när vissa par av tal dividerades.

4 195 835 / 3 145 727 = 1,333820449136241002
(rätt värde)
4 195 835 / 3 145 727 = 1,333739068902037589
(felaktigt värde på grund av beräkningsfelet för FDIV-felet)

Du kanske tror att det inte är någon jättestor skillnad; de flesta användare skulle inte ens märka det. Men under vissa omständigheter – som att räkna upp primtal – kan dessa små avvikelser ha lagts ihop och orsakat helt felaktiga resultat, vilket kan orsaka till och med säkerhetskonsekvenser för hårdvara. Omfattningen av risken var mycket omtvistad vid den tiden, och än idag är vi inte säkra på om det verkligen var ett problem överhuvudtaget ur säkerhetssynpunkt.

Inte mycket senare, 1997, varnade ett anonymt inlägg till en nyhetsgrupp på Internet för ett annat problem, det så kallade F00F-felet, som påverkar alla P5-seriens processorer.

Den här gången var grundorsaken till felet CMPXCHG8B -instruktionen, som normalt jämför och utbyter innehållet i EDX- och EAX-registren tillsammans (4+4=8 byte) med 8 byte på en godtycklig minnesplats specificerad i < OP>. Om operanden var ett register, misslyckades instruktionen och gav ett undantag (eftersom den inte kan jämföra 8 byte med 4). Men om låsprefixet också användes för instruktionen – avsedd att göra instruktioner atomiska (inte avbrytbara) – fick det processorn att frysa exekveringen. De ogiltiga opkoderna låg i intervallet 0F C7 C8-CF och låsprefixet var F0, så de första två byten av den felande opkoden var F0 och 0F, därav namnet F00F bugg. Efter att processorn utfört denna specifika instruktion frös den. Efter det hjälpte bara en hård återställning, vilket – uppenbarligen – kunde orsaka distraktion och eventuell dataförlust.

Sedan dess har komplexiteten hos även den enklaste smarta enheten blivit flera tusen gånger så stor som för en PC med Pentium-processor. Föreställ dig möjligheterna med att en bugg smyger sig in i designen på hårdvarunivå. Det är sant att både designen och testverktygen och metoderna har utvecklats sedan dess, och avslöjade många av de oavsiktliga misstagen som gick obemärkt förut. Men det är också relativt lätt att lägga en hårdvarubakdörr med skadlig uppsåt i en processor, och det är verkligen svårt att hitta.

Några nyare hårdvarusäkerhetsproblem – Meltdown och Spectre

Meltdown utnyttjar sidokanalinformation tillgänglig på de flesta mikroprocessorarkitekturer sedan 2010. Det tillåter en angripare – som kan köra kod på den sårbara processorn – att dumpa hela kärnans adressutrymme. Detta sker genom att missbruka prestandafunktionen som kallas ”utförande i ordning”.

Exekvering i oordning fungerar genom att se före den för närvarande körda instruktionen och förbereda sig för nästa steg för att bättre utnyttja CPU:ns resurser. Detta kan dock ha oönskade biverkningar på sårbara processorer. Redan före Meltdown utnyttjades biverkningar – som tidsskillnader – för att läcka information. En attack i synnerhet (Flush+Reload) skulle kunna leda till informationsläckage genom en cache-sidokanal genom att mäta minnesåtkomsttid för att upptäcka om en viss informationsbit cachelagrades eller inte.

Säkerhetssårbarheten för Meltdown hårdvara ogiltigförklarade alla säkerhetsgarantier för minnesisolering på persondatorer och till och med servrar

Till skillnad från Meltdown bröt Spectre inte isoleringen mellan användarapplikationer och OS-nivån utan gjorde det möjligt att läcka information mellan applikationer. Namnet Spectre kommer från ”spekulativ exekvering”, en funktion som gör att processorn kan ”förutsäga” nästa steg för att påskynda exekveringen. När förutsägelsen visar sig vara felaktig, är allt ogjort, förutom att cachen kommer att innehålla förberäknade data baserat på den förutspådda informationen, kanske en del känslig information, såsom en kryptografisk nyckel. Denna information kan läsas på liknande sätt som med Meltdown.

Men felet kan inte bara vara i CPU:n som gör beräkningen. Även minnet som används kan vara sårbart. Den så kallade rowhammer-sårbarheten (eller ”row hammer” – med två ord – som den faktiskt myntades av Intel i vissa patent medan den länkade uppsatsen skrevs) är möjlig på grund av bieffekterna av hög integration. Dess namn kommer från hur det fungerar. Minnet är uppbyggt av rader och kolumner. När angränsande rader ”hamras” (skrivs om igen och igen) med ett specifikt mönster, kan det ändra värdet på den riktade minnesraden. På så sätt kan en motståndare modifiera minnet så att det innehåller den önskade koden eller data.

Se också detta senaste dokument som analyserar verkliga mottagligheten hos moderna DRAM-chips för Rowhammer-attacker, vilket bevisar att det fortfarande är ett hårdvarusäkerhetsproblem som är relevant idag.

Uppenbarligen, ju mer komplext ett system är, desto större chanser för en oförutsedd sårbarhet. Och som alltid, för en angripare räcker det ofta med att hitta ett enda problem som de kan utnyttja för att iscensätta en komplex attack.

Tillgången till undergång

Det är enkelt. Om en angripare har tillgång till ett system kan de med största sannolikhet hitta sätt att höja sina privilegier för att göra mer skada. Detta gäller även när det kommer till hårdvarusäkerhet.

Till exempel finns alla kontroller på ett flygplan i cockpit – förutom när det finns en ”Seat Electronic Box” installerad under sätet som ger fysisk åtkomst till nätverket. Dessa anslutningar är till för att underlätta underhållet av flygplanet för teknikerna men kan också missbrukas av en angripare för att ta över flygplanets interna nätverk – inklusive datorn som styr flygningen. En säkerhetsforskare gjorde just det 2015.

Saknad eller trasig autentisering är ett vanligt säkerhetsproblem för maskinvara inom bilsäkerhet. På en fysisk nivå tillåter vissa bilar fysisk åtkomst till CAN-bussen från utsidan på grund av ett designfel. Till exempel kan fotgängarvarningshögtalarna på vissa elbilar – placerade nära stötfångarna – kopplas till en liten specialbyggd enhet för att avlyssna och generera CAN Bus-trafik. En angripare kan plantera den här enheten på några sekunder medan fordonet är parkerat, och sedan få direktåtkomst för att läsa och ändra data som skickas mellan fordonets olika styrenheter (ECU). Det här är en slags ”Evil Maid”-attack: liknande en situation när du har din elektronik tillgänglig för städpersonal, som kan byta ut den obemärkt mot en uppsåtligt modifierad enhet, som annars är identisk med blotta ögat. Till exempel kan man låsa upp bilen, sätta den i rörelse, accelerera eller bromsa en bil, flytta styrningen eller ändra riktning. Allt genom data som skickas via några ledningar som är tillgängliga för vem som helst. Och låt oss inte glömma felsöknings- och testportar som finns på de flesta moderna kort. Dessa portar möjliggör enklare testning av hårdvaran men kan också ge en angripare ett sätt att komma åt systemet.

När man tittar på hårdvarusäkerhet ignoreras ofta sidokanalsattacker. Ett system som det som ska attackeras kan kartläggas genom att analysera strömförbrukningen eller tidpunkten för operationerna eller till och med den elektromagnetiska strålningen det avger, och använda den inlärda informationen (t.ex. algoritmer eller hemliga nycklar som används) för att utföra attacken . När angriparen har tillgång till hårdvaran kan de också använda invasiva sidokanalsattacker, t.ex. rowhammer, för att ändra innehållet i skyddat minnesutrymme som beskrivits tidigare.

Förutom sidokanalattacker är det värt att nämna att minnet inte förlorar sitt innehåll i samma ögonblick som strömmen stängs av. Därför finns det också möjlighet att återställa vissa hemligheter med en ”kallstartsattack”. I det här scenariot återställer angriparen enheten och som en konsekvens av det dumpar enheten sitt minne till en beständig lagring, som sedan är tillgänglig för motståndaren. Återigen: detta dumpade minne kan innehålla känslig information, som hemliga nycklar, tokens eller liknande.

Finns det något jag kan göra?

Precis som alltid är det bästa försvaret mot attacker proaktivitet. Designa och bygg dina enheter med säkerhet i åtanke. Till exempel kan UEFI (Unified Extensible Firmware Interface) skydda mot ”Evil Maid”-attacker och vissa HW-tillverkare som ARM gör sina processorer för att vara resistenta mot Spectre och Meltdown. Du kan också inaktivera JTAG, använda full minneskryptering, använda hårdvarusäkerhetsmoduler, använda ett OS som skyddar mot Meltdown/S.

Lär dig mer om säker mjukvarudesign och -implementeringspraxis på en av våra kurser och säker mjukvaruutveckling i den inbäddade världen i C och C++:
Secure Coding in C and C++

Här kan du se alla Informators kurser i IT-säkerhet