Om du är en OpenSSL-användare är du förmodligen medveten om det senaste högprofilerad buggfix release, som kom ut i mars 2022.

Den fixen gav oss OpenSSS 3.0.2 och 1.1.1n, uppdateringar för de två aktuella smakerna av produkten.

(Det finns en äldre version, 1.0.2, men uppdateringar av den versionen är endast tillgängliga för kunder som betalar för premiumsupport, och med tanke på ändringarna och förbättringarna i produkten sedan dagarna av 1.0.2, uppmanar vi dig att gå vidare till en mainstream-versionen även – kanske särskilt – om du planerar att fortsätta betala för support.)

Uppdateringen från mars 2022 var en viktig påminnelse om att djupt begravd kod med ovanliga buggar kan sluta förbises i flera år, särskilt om den koden är en del av en komplex, specialiserad funktion på låg nivå.

Felet fixade då relaterat till en speciell algoritm för beräkning av vad som kallas modulära kvadratrötter, som är mer komplicerade att beräkna än vanliga kvadratrötter.

Tyvärr var koden för att utföra denna beräkning, med en algoritm som först upptäcktes på 1890-talet, klumpigt kodad, slingrande skriven, dåligt kommenterad och svår att följa.

Men med tanke på att det inte fanns i en uppenbar "externt vänd" del av OpenSSL, och med tanke på att omskrivningen av det skulle ha varit en skrämmande uppgift, antar vi att den testades noggrant för korrektheten av sina svar när den presenterades med välformade siffror, men inte undersökt för sin robusthet när de ställs inför osannolik input.

Eftersom, när man ställs inför digitala certifikat som hade fällts för att producera felformade siffror, har OpenSSL:s BN_mod_sqrt() funktionen kunde luras till att loopa för alltid och försöka komma in på ett svar som inte fanns.

När du bara arbetar med heltal och inte tillåter bråk av något slag, upptäcker du att många tal inte har modulära kvadratrötter, precis som du upptäcker att många heltal inte har vanliga kvadratrötter. Alltså 7×7 = 49, så 49 har en kvadratrot som är ett heltal, nämligen 7. Men det finns inget heltal som kan multipliceras med sig självt för att ge 50, eller 51, eftersom nästa "perfekta kvadrat" är 8×8 = 64. Du kan försöka så länge du vill, men du kommer aldrig att hitta ett heltalssvar för √51.

Faktiskt aldrig felaktigt, bara ofullständigt

Med andra ord, även om OpenSSL:s BigNumber-kod (många krypteringsalgoritmer förlitar sig på att arbeta med siffror som är hundratals eller till och med tusentals siffror långa) aldrig gav en oförrätter svar, det insåg ibland inte att det inte fanns något svar att hitta och skulle fastna i en oändlig slinga.

Denna oändliga loop, som skulle kunna missbrukas för att provocera vad som kallas en Förnekande av tjänsten attack (DoS), kan utlösas om en illvillig webbplats skickas över ett digitalt certifikat.

Detta innebar ironiskt nog att programvara som var noggrann med att validera digitala certifikat kunde ställas på knä via denna bugg, dubbad CVE-2022-0778, medan program som inte alls störde certifikatvalidering inte påverkades av det.

Med tanke på de viktiga "lärbara ögonblick" som avslöjas av denna bugg, täckte vi det i detalj inte bara på Naked Security, där vi förklarade hur man skriver en bättre kodstil, men också på Sophos News, där SophosLabs visade de blodiga detaljerna om hur ett certifikat kan utlösa felet, och hur man felsöker koden för att förstå felet.

Två säkerhetshål till under tiden

Nästa OpenSSL-uppdatering var 3.0.3, eller 1.1.1o för användare av den tidigare utgåvan, som korrigerade en bugg som inte ansågs vara ett stort fel (åtminstone, vi täckte det inte på Naked Security), främst för att felet inte fanns i själva OpenSSL-krypteringsbibliotekskoden.

Istället för att påverka all programvara som förlitade sig på OpenSSL som sin krytografiska leverantör, CVE-2022-1292 påverkade just ett verktygsskript, skrivet i Perl, som följde med OpenSSL-verktygslådan.

Detta skript, känt som c_rehash (Förkortning av certifikatkatalogrehash) är ett föga känt verktyg som tar en katalog med kryptografiska certifikatfiler, till exempel de som underhålls som betrodda certifikatmyndigheter (CA) av Mozilla, och skapar en lista med filhashar som kan hjälpa programvara att hitta specifika certifikat snabbare än att söka i en alfabetisk lista över namn.

Till exempel ser Mozillas CA-certifikatkatalog ut så här...

$ ls -l /usr/share/ca-certificates/mozilla -rw-r--r-- 1 anka 2772 2022-06-23 05:32 ACCVRAIZ1.crt -rw-r--r-- 1 anka 1972 2022-06-23 05:32 AC_RAIZ_FNMT-RCM.crt -rw-r--r-- 1 anka 904 2022-06-23 05:32 AC_RAIZ_FNMT-RCM_SERVIDORES_SEGUROS.c. . .] -rw-r--r-- 1 anka 1302 2022-06-23 05:32 emSign_Root_CA_-_G1.crt -rw-r--r-- 1 anka 774 2022-06-23 05_CAC_vRR .crt -rw-r--r-- 32 anka 1 1911-2022-06 23:05 vTrus_Root_CA.crt

…medan OpenSSL c_rehash skriptet genererar en lista med symboliska länkar som gör att enskilda certifikat kan lokaliseras via hash baserade på utfärdarens namn i själva certifikatet, snarare än via dess filnamn:

lrwxrwxrwx 1 anka 23 2022-06-24 13:41 002c0b4f.0-> Globalsign_root_r46.crt lrwxrwxrwx 1 anka 45 2022-06-24 13:41 02265526.0-> entry_certifiering -2 1:36 2022a06 -> Staat_der_Nederlanden_EV_Root_CA.crt [. . .] lrwxrwxrwx 24 anka 13 41-03179-64.0 1:19 FE2022A06CD24-> SZAFIR_ROOT_CA13 -41-8 2:8.0 ff2af1f.23 -> TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_2022.crt

Vissa program förlitar sig på dessa "hash-länkar" för att fungera som ett slags grundläggande databassystem för att indexera och hitta specifika certifikat.

Dessutom anropar vissa operativsystemsdistributioner automatiskt c_rehash skript i bakgrunden för att hålla dessa speciallänkar uppdaterade.

Skalmetakaraktärer anses vara skadliga

Tyvärr förlitade manuset sig på Perl system() funktion (eller ett motsvarande kommando) för att beräkna filhasharna, och system() Systemet startar automatiskt ett kommandoskal, såsom Bash, för att starta alla nödvändiga underprogram.

Och, som du säkert vet, behandlar kommandoskal inte alltid sina kommandoradsargument bokstavligt, så om du lägger in specialtecken i dessa argument, hanterar skalet dem på potentiellt farliga sätt.

Till exempel kommandot echo runthis bokstavligen skriver ut texten runthis, men kommandot echo $(runthis) skriver inte ut tecknen direkt $(runthis).

Istället s.k metakommando $(runthis) betyder kommandosubstitution, så det står, "Kör kommandot runthis och byt ut $(...) del med utdata från det kommandot när det är klart”:

   # argument behandlas bokstavligt, inga metatecken hittades $ echo runthis runthis # försöker köra 'runthis', men inget sådant kommando existerar $ echo $(runthis) -bash: runthis: kommandot hittades inte # kör två kommandon, samlar utdata från båda $ echo $(whoami; uname -s -r) duck Linux 5.18.6

Om risken medför $(...) låter bekant, det beror på att det var metakommandosårbarheten som utnyttjades under den senaste tiden "Follina" bugg på Windows. För att lära dig mer och se buggen live i aktion kan du titta på vårt inspelade webbseminarium. Klicka bara på bilden nedan. [Registrering krävs, åtkomst är omedelbart därefter.]

Vad fixades?

Skript som accepterar otillförlitlig input från någon annan – oavsett om det är en sträng som skrivits in i ett webbformulär eller ett påhittat filnamn som tillhandahålls utifrån – måste vara mycket försiktiga så att de inte tillåter dessa speciella metakommandon att läcka ut som skalargument när de förlitar sig på kommandot skal för att köra externa verktyg.

Nedan kan du se koden som ändrades från 1.1.1n till 1.1.1o:

Ett Perl-kommando av formen `...` (ett kommando mellan backticks, som t.ex `runthis`, är helt enkelt ett gammaldags sätt att skriva $(runthis) kommandosubstitution) ersattes med en dedikerad intern funktion som kallas compute_hash som är mer försiktig med konstiga metatecken i den konstruerade kommandosträngen.

Tja, det visar sig att underhållarna inte riktigt fångade alla ställen i detta verktygsskript där ett externt kommando kördes utan vederbörlig omsorg och uppmärksamhet.

Den här veckan alltså såg släppet av OpenSSL 3.0.4 och 1.1.1p, för att fixa ett annat riskabelt systemkommando i c_rehash verktyg:

Den här gången var det en uppmaning till cp (kopiera fil) kommandot via det skalbaserade system() funktion som ersattes med en säkrare, dedikerad intern funktion kallad copy_file.

Denna buggfix har den officiella identifieraren CVE-2022-2068.

Som OpenSSL-ändringsloggen varnar:

[Den c_rehash]-skriptet distribueras av vissa operativsystem på ett sätt där det körs automatiskt. På sådana operativsystem kan en angripare utföra godtyckliga kommandon med skriptets privilegier.

Vad göra?

• Uppdatera OpenSSL så snart du kan. Om du litar på din Linux-distro för att hantera en centralt installerad kopia, kontakta din distrotillverkare för mer information. Om du förlitar dig på din egen version av OpenSSL istället för (eller lika väl som) en systemomfattande, glöm inte att uppdatera den kopian också. Du letar efter 3.0.4 or 1.1.1p. Springa openssl version för att se vilken version du har.
• Överväg att gå i pension c_rehash verktyget om du använder det. Allt-i-ett-verktyget openssl, som vanligtvis används för att generera och signera certifikat i första hand, innehåller nu ett inbyggt underkommando som heter rehash att göra samma jobb. Prova openssl rehash -help för ytterligare information.
• Rengör dina ingångar och utgångar. Anta aldrig att indata du får är säker att använda i befintligt skick, och var försiktig med de data du skickar vidare som utdata till andra delar av din kod.
• Var uppmärksam på flera fel när du granskar koden för specifika typer av buggar. En programmerare som slarvade med en system() kommandot på ett ställe i koden kan ha gjort liknande misstag någon annanstans.

Programmerare producerar (eller reproducerar) ofta samma typ av bugg många gånger, vanligtvis av helt oskyldiga och förståeliga skäl.

Antingen var de inte medvetna om den klassen av buggar när de arbetade med koden, eller så tog de en "tillfällig genväg" för att påskynda prototyparbete men gick aldrig tillbaka och städade senare, eller så kopierade och klistrade de någon else's felaktiga kod och gjorde den till sin egen...