Sikkerhetseksperter beskrev to svært etterlengtede sårbarheter som OpenSSL Project-teamet lappet tirsdag som problemer som må løses raskt, men som ikke nødvendigvis fortjener en slipp-alt-annet type nødrespons.
Utgivelsen av versjon 3.0.7 av det nesten allestedsnærværende kryptografiske biblioteket adresserer to bufferoverløpssårbarheter, som finnes i OpenSSL versjoner 3.0.0 til 3.0.6.
I forkant av avsløringen hadde sikkerhetseksperter advart om at et av problemene, opprinnelig karakterisert som en "kritisk" eksternt kodeutførelsesproblem, kan presentere et Heartbleed-nivå, alle-hender-på-dekk-problem. Heldigvis ser det ikke ut til å være tilfelle - og da OpenSSL-prosjektteamet avslørte feilen, sa de hadde bestemt seg for å nedgrader trusselen til "høy" basert på tilbakemeldinger fra organisasjoner som hadde testet og analysert feilen.
Et par buffere renner over
Den første feilen (CVE-2022-3602) kunne faktisk – under et spesifikt sett av omstendigheter – aktivere RCE, noe som opprinnelig førte til at noen sikkerhetseksperter bekymret seg for at feilen kunne få konsekvenser for hele industrien. Men det viser seg at det er formildende omstendigheter: For det første er det vanskelig å utnytte, som forklart nedenfor. Dessuten er ikke alle systemer påvirket.
Spesifikt er det bare nettlesere som støtter OpenSSL 3.0.0 til 3.0.6, som Firefox og Internet Explorer, som er berørt på dette tidspunktet, ifølge Mark Ellzey, senior sikkerhetsforsker ved Censys; spesielt upåvirket er Google Chrome, som er den ledende nettleseren.
"Konsekvensen forventes å være minimal på grunn av kompleksiteten til angrepet og begrensningene i hvordan det kan utføres," sier han. "Organisasjoner bør friske opp phishing-opplæringen sin og holde øye med kilder for trusseletterretning for å sikre at de er forberedt hvis de blir målrettet av et angrep som dette."
For å starte opp, bemerket Alex Ilgayev, ledende sikkerhetsforsker ved Cycode, at feilen ikke kan utnyttes på visse Linux-distribusjoner; og mange moderne OS-plattformer implementerer overløpsbeskyttelse for å redusere trusler som disse uansett, sier Ilgayev.
Den andre sårbarheten (CVE-2022-3786), som ble avdekket mens en løsning for den opprinnelige feilen ble utviklet, kan brukes til å utløse tjenestenekt-forhold (DoS). OpenSSL-teamet vurderte sårbarheten til å være av høy alvorlighetsgrad, men utelukket muligheten for at den ble brukt til RCE-utnyttelse.
Begge sårbarhetene er knyttet til en funksjonalitet kalt punycode for koding av internasjonaliserte domenenavn.
"Brukere av OpenSSL 3.0.0 – 3.0.6 er oppfordres til å oppgradere til 3.0.7 så snart som mulig", sa OpenSSL-teamet i en blogg som fulgte med avsløringen av feil og utgivelsen av den nye versjonen av det kryptografiske biblioteket. "Hvis du får din kopi av OpenSSL fra din operativsystemleverandør eller annen tredjepart, bør du søke å få en oppdatert versjon fra dem så snart som mulig."
Ikke en annen hjerteblødning
Avsløringen av feilen vil garantert dempe - for øyeblikket i det minste - den utbredte bekymringen utløste av OpenSSL-teamets varsling forrige uke om deres da forestående feilavsløring. Spesielt beskrivelsen av den første feilen som «kritisk» hadde ført til flere sammenligninger med 2014s «Heartbleed»-feil – den eneste andre feilen i OpenSSL som fikk en kritisk vurdering. Denne feilen (CVE-2014-0160) påvirket et bredt spekter av Internett, og selv nå har ikke mange organisasjoner blitt behandlet fullt ut.
"Heartbleed ble avslørt som standard på all programvare som brukte en sårbar versjon av OpenSSL, og det var veldig lett å utnytte av angripere for å se kryptografiske nøkler og passord lagret i serverminnet," sier Jonathan Knudsen, leder for global forskning ved Synopsys Cybersecurity Research Center . "De to sårbarhetene som nettopp er rapportert i OpenSSL er alvorlige, men ikke av samme størrelse."
OpenSSL-feil er vanskelige å utnytte ...
For å utnytte noen av de nye feilene, må sårbare servere be om autentisering av klientsertifikater, noe som ikke er normen, sier Knudsen. Og sårbare klienter må koble seg til en ondsinnet server, som er en vanlig og forsvarlig angrepsvektor, sier han.
"Ingen hår bør brenne for disse to sårbarhetene, men de er alvorlige og bør håndteres med passende hastighet og flid," bemerker han.
I et blogginnlegg beskrev SANS Internet Storm Center i mellomtiden OpenSSL-oppdateringen som fikse et bufferoverløp under sertifikatverifiseringsprosessen. For at en utnyttelse skal fungere, må sertifikatet inneholde et ondsinnet Punycode-kodet navn, og sårbarheten vil utløses først etter at sertifikatkjeden er bekreftet.
"En angriper må først kunne ha et ondsinnet sertifikat signert av en sertifiseringsinstans klienten stoler på," bemerket SANS ISC. "Dette ser ikke ut til å kunne utnyttes mot servere. For servere kan dette utnyttes hvis serveren ber om et sertifikat fra klienten."
Bunnlinjen: Sannsynligheten for utnyttelse er lav siden sårbarheten er kompleks å utnytte, det samme er flyten og kravene for å utløse den, sier Cycodes Ilgayev. I tillegg påvirker det et relativt lite antall systemer, sammenlignet med de som bruker tidligere versjoner av OpenSSL.
…Men vær flittig
Samtidig er det viktig å huske på at vanskelige å utnytte sårbarheter har blitt utnyttet tidligere, sier Ilgayev og peker på en null-klikk utnyttelse som NSO-gruppen utviklet for en sårbarhet i iOS i fjor.
"[Også], som OpenSSL-teamet sier, er det 'ingen måte å vite hvordan hver plattform og kompilatorkombinasjon har ordnet bufferne på stabelen', og derfor kan ekstern kjøring av kode fortsatt være mulig på noen plattformer," advarer han.
Og faktisk, Ellzey skisserer ett scenario for hvordan angripere kunne utnytte CVE-2022-3602, feilen som OpenSSL-teamet opprinnelig hadde vurdert som kritisk.
"En angriper vil være vert for en ondsinnet server og forsøke å få ofre til å autentisere seg for den med en applikasjon som er sårbar for OpenSSL v3.x, potensielt gjennom tradisjonell phishing-taktikk," sier han, selv om omfanget er begrenset på grunn av at utnyttelsen hovedsakelig er klient- side.
Sårbarheter som dette fremhever viktigheten av å ha en programvareliste (SBOM) for hver binær som brukes, bemerker Ilgayev. "Å se på pakkeadministratorer er ikke nok, siden dette biblioteket kan kobles sammen og kompileres i forskjellige konfigurasjoner som vil påvirke utnyttelsen," sier han.
