Säkerhetsexperter beskrev två efterlängtade sårbarheter som OpenSSL Project-teamet korrigerade i tisdags som problem som måste åtgärdas snabbt, men som inte nödvändigtvis förtjänar en nödåtgärd av typen släpp allt annat.
Utgivningen av version 3.0.7 av det nästan allmänt använda kryptografiska biblioteket åtgärdar två buffertspillsårbarheter, som finns i OpenSSL-versionerna 3.0.0 till 3.0.6.
Inför avslöjandet hade säkerhetsexperter varnat för att ett av problemen, ursprungligen karakteriserad som en "kritisk" Fjärrkodexekveringsproblem, kan utgöra ett problem på Heartbleed-nivå, alla händer på däck. Tack och lov verkar det inte vara fallet – och när OpenSSL-projektgruppen avslöjade felet sa de hade beslutat att nedgradera hotet till "högt" baserat på feedback från organisationer som hade testat och analyserat felet.
Ett par buffertar svämmar över
Den första buggen (CVE-2022-3602) skulle verkligen – under en specifik uppsättning omständigheter – möjliggöra RCE, vilket ursprungligen fick vissa säkerhetsexperter att oroa sig för att felet skulle kunna få konsekvenser för hela branschen. Men det visar sig att det finns förmildrande omständigheter: För det första är det svårt att utnyttja, som förklaras nedan. Dessutom påverkas inte alla system.
Specifikt är det bara webbläsare som stöder OpenSSL 3.0.0 till 3.0.6, som Firefox och Internet Explorer, som påverkas för närvarande, enligt Mark Ellzey, senior säkerhetsforskare på Censys; särskilt opåverkad är Google Chrome, som är den ledande webbläsaren.
"Konsekvensen förväntas bli minimal på grund av attackens komplexitet och begränsningarna i hur den kan utföras", säger han. "Organisationer bör fräscha upp sin nätfisketräning och hålla ett öga på hotintelligenskällor för att säkerställa att de är förberedda om de utsätts för en attack som denna."
För att starta upp, noterade Alex Ilgayev, ledande säkerhetsforskare på Cycode, att felet inte kan utnyttjas på vissa Linux-distributioner; och många moderna OS-plattformar implementerar stack overflow-skydd för att mildra mot hot som dessa i alla fall, säger Ilgayev.
Den andra sårbarheten (CVE-2022-3786), som avslöjades medan en fix för det ursprungliga felet utvecklades, kunde användas för att utlösa DoS-villkor (denial of service). OpenSSL-teamet bedömde sårbarheten som av hög allvarlighetsgrad men uteslöt möjligheten att den skulle användas för RCE-exploatering.
Båda sårbarheterna är knutna till en funktion som kallas punycode för kodning av internationaliserade domännamn.
"Användare av OpenSSL 3.0.0 – 3.0.6 är uppmuntras att uppgradera till 3.0.7 så snart som möjligt", sa OpenSSL-teamet i en blogg som åtföljde buggavslöjandet och släppet av den nya versionen av det kryptografiska biblioteket. "Om du skaffar din kopia av OpenSSL från din operativsystemsleverantör eller annan tredje part bör du försöka få en uppdaterad version från dem så snart som möjligt."
Inte en annan Heartbleed
Avslöjandet av buggar kommer säkerligen att minska - för tillfället åtminstone - den utbredda oron utlöste av OpenSSL-teamets meddelande förra veckan om dess då förestående buggavslöjande. Beskrivningen av den första bristen som "kritisk", i synnerhet, hade föranlett flera jämförelser med 2014 års "Heartbleed"-bug - den enda andra buggen i OpenSSL som fick ett kritiskt betyg. Den buggen (CVE-2014-0160) påverkade ett brett spektrum av Internet och har inte ens nu åtgärdats fullt ut i många organisationer.
"Heartbleed exponerades som standard på alla program som använde en sårbar version av OpenSSL, och det var mycket lätt att exploatera av angripare för att se kryptografiska nycklar och lösenord lagrade i serverminne", säger Jonathan Knudsen, chef för global forskning vid Synopsys Cybersecurity Research Center . "De två sårbarheterna som just rapporterats i OpenSSL är allvarliga men inte av samma storlek."
OpenSSL-buggar är svåra att utnyttja...
För att utnyttja någon av de nya bristerna skulle sårbara servrar behöva begära autentisering av klientcertifikat, vilket inte är normen, säger Knudsen. Och sårbara klienter skulle behöva ansluta till en skadlig server, vilket är en vanlig och försvarbar attackvektor, säger han.
"Ingen hår bör brinna angående dessa två sårbarheter, men de är allvarliga och bör hanteras med lämplig hastighet och flit," konstaterar han.
I ett blogginlägg beskrev SANS Internet Storm Center under tiden OpenSSL-uppdateringen som fixa ett buffertöverskridande under certifikatverifieringsprocessen. För att en exploatering ska fungera måste certifikatet innehålla ett skadligt Punycode-kodat namn, och sårbarheten skulle utlösas först efter att certifikatkedjan har verifierats.
"En angripare måste först kunna ha ett skadligt certifikat signerat av en certifikatutfärdare som klienten litar på", noterade SANS ISC. "Detta verkar inte kunna utnyttjas mot servrar. För servrar kan detta utnyttjas om servern begär ett certifikat från klienten."
Sammanfattning: Sannolikheten för utnyttjande är låg eftersom sårbarheten är komplex att utnyttja, liksom flödet och kraven för att utlösa den, säger Cycodes Ilgayev. Dessutom påverkar det ett relativt litet antal system, jämfört med de som använder pre-3.0 versioner av OpenSSL.
…men var flitig
Samtidigt är det viktigt att ha i åtanke att svårutnyttjade sårbarheter har utnyttjats tidigare, säger Ilgayev och pekar på en nollklicksexploatering som NSO-gruppen utvecklade för en sårbarhet i iOS förra året.
"[Också], som OpenSSL-teamet säger, det finns 'inget sätt att veta hur varje plattform och kompilatorkombination har ordnat buffertarna på stacken', och därför kan fjärrkörning av kod fortfarande vara möjlig på vissa plattformar," varnar han.
Och faktiskt, Ellzey skisserar ett scenario för hur angripare kunde utnyttja CVE-2022-3602, det fel som OpenSSL-teamet ursprungligen bedömde som kritiskt.
"En angripare skulle vara värd för en skadlig server och försöka få offer att autentisera till den med en applikation som är sårbar för OpenSSL v3.x, potentiellt genom traditionell nätfisketaktik", säger han, även om omfattningen är begränsad på grund av att utnyttjandet till övervägande del är klient- sida.
Sårbarheter som denna belyser vikten av att ha en materialförteckning för programvara (SBOM) för varje binär som används, noterar Ilgayev. "Det räcker inte att titta på pakethanterare eftersom det här biblioteket kan länkas och kompileras i olika konfigurationer som kommer att påverka exploateringen", säger han.
