We beginnen met de belangrijke dingen: de langverwachte OpenSSL-bugfixes die vorige week zijn aangekondigd zijn uit.

OpenSSL 1.1.1 gaat naar versie 1.1.1s, en patcht een vermelde beveiligingsgerelateerde bug, maar deze bug heeft geen beveiligingsclassificatie of een officieel CVE-nummer.

We raden u ten zeerste aan om bij te werken, maar de KRITIEKE update die u in de cyberbeveiligingsmedia hebt gezien, is niet van toepassing op deze versie.

OpenSSL 3.0 gaat naar versie 3.0.7, en patcht niet één maar twee CVE-genummerde beveiligingsbugs die officieel zijn aangewezen als HOOG.

We raden je ten zeerste aan om bij te werken, met zo veel urgentie als je kunt opbrengen, maar de KRITIEKE oplossing waar iedereen het over had, is nu gedegradeerd tot HOOG.

Dit weerspiegelt de mening van het OpenSSL-team:

Vooraankondigingen van CVE-2022-3602 beschreef dit probleem als KRITIEK. Nadere analyse op basis van enkele van de verzachtende factoren die [in de release-opmerkingen] worden beschreven, hebben ertoe geleid dat dit is verlaagd naar HOOG. Gebruikers worden nog steeds aangemoedigd om zo snel mogelijk te upgraden naar een nieuwe versie.

Ironisch genoeg, een tweede en soortgelijke bug, genaamd CVE-2022-3786, werd ontdekt terwijl de oplossing voor CVE-2022-3602 werd voorbereid.

De originele bug staat een aanvaller alleen toe om vier bytes op de stack te corrumperen, wat de exploiteerbaarheid van het gat beperkt, terwijl de tweede bug een onbeperkte hoeveelheid stack-overflow toestaat, maar blijkbaar alleen van het "dot"-teken (ASCII 46, of 0x2E ) keer op keer herhaald.

Beide kwetsbaarheden worden blootgelegd tijdens TLS-certificaatverificatie, waarbij een boobytrap-client of -server zichzelf "identificeert" met de server of client aan de andere kant met een opzettelijk verkeerd gevormd TLS-certificaat.

Hoewel dit soort stapeloverloop (een van beperkte grootte en de andere van beperkte gegevenswaarden) klinkt alsof ze moeilijk te exploiteren zijn voor code-uitvoering (vooral in 64-bits software, waar vier bytes slechts de helft van een geheugenadres is) …

...ze zijn vrijwel zeker gemakkelijk te exploiteren voor DoS-aanvallen (denial of service), waarbij de afzender van een frauduleus certificaat de ontvanger van dat certificaat naar believen kan laten crashen.

Gelukkig zijn bij de meeste TLS-uitwisselingen clients betrokken die servercertificaten verifiëren, en niet andersom.

De meeste webservers vereisen bijvoorbeeld niet dat bezoekers zich identificeren met een certificaat voordat ze de site kunnen lezen, dus de "crashrichting" van werkende exploits is waarschijnlijk dat malafide servers ongelukkige bezoekers laten crashen, wat over het algemeen wordt beschouwd als veel minder ernstig dan servers die crashen elke keer dat ze worden bezocht door een enkele frauduleuze bezoeker.

Niettemin moet elke techniek waarmee een gehackte web- of e-mailserver een bezoekende browser of e-mailapp gratis kan laten crashen als gevaarlijk worden beschouwd, niet in de laatste plaats omdat elke poging van de clientsoftware om de verbinding opnieuw te proberen ertoe leidt dat de app steeds opnieuw crasht opnieuw.

Dat wil je dus zeker patch hier zo snel mogelijk tegen.

Wat te doen?

Zoals hierboven vermeld, heb je nodig: OpenSSL 1.1.1s or SSL 3.0.7 openen om de versie die je op dit moment hebt te vervangen.

OpenSSL 1.1.1s krijgt een beveiligingspatch die wordt beschreven als repareren "een regressie [een oude bug die opnieuw verscheen] geïntroduceerd in OpenSSL 1.1.1r die de te ondertekenen certificaatgegevens niet ververst voordat het certificaat wordt ondertekend", aan die bug is geen ernst of CVE toegewezen ...

…maar laat dat je er niet van weerhouden om zo snel mogelijk te updaten.

SSL 3.0.7 openen krijgt de twee CVE-genummerde HIGH-severity fixes die hierboven zijn vermeld, en hoewel ze nu niet zo eng klinken als in het nieuwsfestijn voorafgaand aan deze release, moet je aannemen dat:

• Veel aanvallers zullen snel weten hoe ze dit gat kunnen misbruiken voor DoS-doeleinden. Dat kan in het gunstigste geval leiden tot verstoring van de workflow en in het slechtste geval tot problemen met de cyberbeveiliging, vooral als de bug kan worden misbruikt om belangrijke geautomatiseerde processen (zoals updates) in uw IT-ecosysteem te vertragen of te onderbreken.
• Sommige aanvallers kunnen deze bugs oplossen voor uitvoering van externe code. Dit zou criminelen een goede kans geven om webservers met boobytraps te gebruiken om clientsoftware te ondermijnen die wordt gebruikt voor veilige downloads in uw eigen bedrijf.
• Als er een proof-of-concept (PoC) wordt gevonden, zal deze grote belangstelling trekken. Zoals je je zult herinneren van Log4Shell, sprongen duizenden zelfverklaarde "onderzoekers" zodra PoC's werden gepubliceerd op de kar door het internet te scannen en aan te vallen onder het mom van "helpen" mensen te vinden problemen op hun netwerken.

Merk op dat OpenSSL 1.0.2 nog steeds wordt ondersteund en bijgewerkt, maar alleen privé, voor klanten die betaalde contracten hebben met het OpenSSL-team. -genummerde bugs in OpenSSL 3.0 zijn niet van toepassing op de OpenSSL 1.0.2-serie.

Je kunt Lees verder, en haal je OpenSSL-updates, van de OpenSSL-website.

Merk ook op dat Google's BoringSSL bibliotheek, Firefox's Netwerkbeveiligingsdiensten (NSS), en OpenBSD's LibreSSL, die allemaal dezelfde functionaliteit bieden als OpenSSL (en in het geval van LibreSSL er nauw mee compatibel zijn), worden allemaal niet beïnvloed door deze bugs.

Oh, en als PoC's online verschijnen, wees dan geen slimme klompen en begin die PoC's te "uitproberen" tegen de computers van andere mensen in de veronderstelling dat je "helpt" met enig soort van "onderzoek".