Als u een OpenSSL-gebruiker bent, kent u waarschijnlijk de meest recente spraakmakende bugfix release, die in maart 2022 uitkwam.

Die oplossing bracht ons OpenSSS 3.0.2 en 1.1.1n, updates voor de twee huidige volledig ondersteunde smaken van het product.

(Er is een oudere versie, 1.0.2, maar updates voor die versie zijn alleen beschikbaar voor klanten die betalen voor premium-ondersteuning, en gezien de veranderingen en verbeteringen in het product sinds de dagen van 1.0.2, raden we u aan om vooruit te gaan naar een mainstream-versie zelfs – misschien vooral – als u van plan bent te blijven betalen voor ondersteuning.)

De update van maart 2022 was een essentiële herinnering dat diepgewortelde code met ongebruikelijke bugs jarenlang over het hoofd kan worden gezien, vooral als die code deel uitmaakt van een complexe, gespecialiseerde functie op laag niveau.

De toen gerepareerde bug had betrekking op een speciaal algoritme voor het berekenen van wat bekend staat als modulaire vierkantswortels, die ingewikkelder zijn om te berekenen dan gewone vierkantswortels.

Helaas was de code om deze berekening uit te voeren, met behulp van een algoritme dat voor het eerst werd ontdekt in de jaren 1890, onhandig gecodeerd, kronkelig geschreven, slecht becommentarieerd en moeilijk te volgen.

Aangezien het echter niet in een voor de hand liggend "extern gericht" deel van OpenSSL was, en aangezien het herschrijven ervan een ontmoedigende taak zou zijn geweest, gaan we ervan uit dat het zorgvuldig is getest op de juistheid van de antwoorden wanneer het wordt gepresenteerd met goed gevormde getallen, maar niet onderzocht op zijn robuustheid bij onwaarschijnlijke invoer.

Omdat OpenSSL's, wanneer ze geconfronteerd werden met digitale certificaten die in een boobytrap waren gezet om slecht gevormde nummers te produceren, BN_mod_sqrt() functie kan worden misleid om voor altijd in een lus te blijven, in een poging een antwoord te sluiten dat niet bestaat.

Als je alleen met gehele getallen werkt en breuken van welke soort dan ook niet toestaat, zul je zien dat veel getallen geen modulaire vierkantswortels hebben, net zoals je merkt dat veel gehele getallen geen reguliere vierkantswortels hebben. Dus 7×7 = 49, dus 49 heeft een vierkantswortel die een geheel getal is, namelijk 7. Maar er is geen geheel getal dat met zichzelf vermenigvuldigd kan worden om 50 of 51 te geven, omdat het volgende “perfecte vierkant” 8×8 is = 64. Je kunt het zo lang proberen als je wilt, maar je zult nooit een antwoord met een geheel getal vinden voor √51.

Nooit echt onjuist, alleen incompleet

Met andere woorden, hoewel de BigNumber-code van OpenSSL (veel coderingsalgoritmen vertrouwen op het werken met getallen die honderden of zelfs duizenden cijfers lang zijn) nooit een verkeerd antwoord, realiseerde het zich soms niet dat er geen antwoord te vinden was en kwam het vast te zitten in een oneindige lus.

Deze oneindige lus, die kan worden misbruikt om wat bekend staat als a . uit te lokken Denial-of-Service aanval (DoS), kan worden geactiveerd als een kwaadwillende website een digitaal certificaat met boobytraps verzendt.

Dit betekende ironisch genoeg dat software die nauwgezet was in het valideren van digitale certificaten op de knieën kon worden gebracht via deze bug, genaamd CVE-2022-0778, terwijl programma's die zich helemaal niet bezighielden met certificaatvalidatie er niet door werden beïnvloed.

Gezien de belangrijke "leermomenten" die door deze bug worden onthuld, hebben we het in detail besproken, niet alleen op Naked Security, waar we uitlegden hoe een betere codestijl te schrijven, maar ook op Sophos News, waar SophosLabs de bloederige details liet zien van hoe een boobytrap-certificaat de fout zou kunnen veroorzaken, en hoe de code te debuggen om de bug te begrijpen.

Ondertussen nog twee gaten in de beveiliging

De volgende OpenSSL-update was 3.0.3of 1.1.1o voor gebruikers van de vorige release, die een bug heeft gepatcht die niet als een grote fout werd beschouwd (tenminste, we hebben het niet behandeld op Naked Security), voornamelijk omdat de bug niet in de OpenSSL-coderingsbibliotheekcode zelf zat.

In plaats van alle software te beïnvloeden die op OpenSSL als cryptografische provider vertrouwde, CVE-2022-1292 heeft zojuist een hulpprogramma-script aangetast, geschreven in Perl, dat bij de OpenSSL-toolkit werd geleverd.

Dit script, bekend als c_rehash (kort voor certificaat directory rehash) is een weinig bekende tool die een map met cryptografische certificaatbestanden neemt, zoals degene die door Mozilla worden onderhouden als vertrouwde certificeringsinstanties (CA's), en een lijst met bestandshashes maakt waarmee software specifieke certificaten sneller kan vinden dan zoeken op een alfabetische lijst met namen.

De CA-certificaatmap van Mozilla ziet er bijvoorbeeld als volgt uit...

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

... terwijl OpenSSL's c_rehash script genereert een lijst met symbolische links waarmee individuele certificaten kunnen worden gelokaliseerd via hashes op basis van de naam van de uitgever in het certificaat zelf, in plaats van via de bestandsnaam:

lrwxrwxrwx 1 eend eend 23 2022-06-24 13:41 002c0b4f.0 -> GlobalSign_Root_R46.crt lrwxrwxrwx 1 eend eend 45 2022-06-24 13:41 02265526.0 -> Entrust_Root_Certification_Authority_-_G2.crt 1rwx 36 eend -2022 06:24 13a41 -> Staat_der_Nederlanden_EV_Root_CA.crt [. . .] lrwxrwxrwx 03179 eend eend 64.0 1-19-2022 06:24 fe13a41cd8 -> SZAFIR_ROOT_CA2.crt lrwxrwxrwx 8.0 eend eend 2 1-23-2022 06:24 feffd13 -> GlobalSign_Root_E41.crt lrwx eendrwxrw 413.0 -46-1 49:2022 ff06af24f.13 -> TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_41.crt

Sommige software vertrouwt op deze "hashlinks" om te fungeren als een soort basisdatabasesysteem voor het indexeren en vinden van specifieke certificaten.

Bovendien roepen sommige distributies van besturingssystemen automatisch de c_rehash script op de achtergrond om deze speciale links up-to-date te houden.

Shell-metatekens als schadelijk beschouwd

Helaas vertrouwde het script op de Perl system() functie (of een equivalent commando) om de bestandshashes te berekenen, en de system() systeem start automatisch een opdrachtshell, zoals Bash, om alle benodigde subprogramma's te starten.

En, zoals je waarschijnlijk weet, behandelen opdrachtshells hun opdrachtregelargumenten niet altijd letterlijk, dus als je speciale tekens in die argumenten plaatst, behandelt de shell ze op potentieel gevaarlijke manieren.

Bijvoorbeeld het commando echo runthis drukt de tekst letterlijk af runthis, maar het commando echo $(runthis) drukt de tekens niet rechtstreeks af $(runthis).

In plaats daarvan, de zogenaamde metacommando $(runthis) middel commando vervanging, dus er staat: "Voer de opdracht uit" runthis en vervang de $(...) deel met de uitvoer van dat commando als het klaar is":

   # argument letterlijk behandeld, geen metatekens gevonden $ echo runthis runthis # probeert 'runthis' uit te voeren, maar zo'n commando bestaat niet $ echo $(runthis) -bash: runthis: commando niet gevonden # voert twee commando's uit, verzamelt uitvoer van beide $ echo $(whoami; uname -s -r) duck Linux 5.18.6

Als het risico van $(...) klinkt bekend, dat komt omdat het de metacommand-kwetsbaarheid was die werd misbruikt in de recente "Follina"-bug op Windows. Voor meer informatie en om die bug live in actie te zien, kun je ons opgenomen webinar bekijken. Klik maar op de afbeelding hieronder. [Registratie vereist, toegang is onmiddellijk daarna.]

Wat is er opgelost?

Scripts die niet-vertrouwde invoer van iemand anders accepteren - of dat nu een tekenreeks is die in een webformulier is getypt of een verzonnen bestandsnaam die van buitenaf wordt aangeleverd - moet heel voorzichtig zijn dat deze speciale metacommando's niet als shell-argumenten naar buiten lekken wanneer ze op de opdracht vertrouwen shell voor het uitvoeren van externe hulpprogramma's.

Hieronder ziet u de code die is gewijzigd van 1.1.1n naar 1.1.1o:

Een Perl-opdracht van het formulier `...` (een commando tussen backticks, zoals `runthis`, is gewoon een ouderwetse manier om de . te schrijven $(runthis) opdrachtvervanging) werd vervangen door een speciale interne functie genaamd compute_hash die meer zorg besteedt aan vreemde metatekens in de geconstrueerde opdrachtreeks.

Welnu, het blijkt dat de beheerders niet alle plaatsen in dit hulpprogramma-script hebben opgemerkt waar een extern commando zonder de nodige zorg en aandacht werd uitgevoerd.

Deze week dus zag de release van OpenSSL 3.0.4 en 1.1.1p, om een ​​ander riskant systeemcommando in de . te repareren c_rehash nut:

Deze keer was het een oproep aan de cp (bestand kopiëren) commando via de shell-based system() functie die werd vervangen door een veiligere, speciale interne functie genaamd copy_file.

Deze bugfix heeft de officiële identifier CVE-2022-2068.

Zoals de OpenSSL changelog waarschuwt:

[The c_rehash]-script wordt door sommige besturingssystemen gedistribueerd op een manier waarop het automatisch wordt uitgevoerd. Op dergelijke besturingssystemen kan een aanvaller willekeurige opdrachten uitvoeren met de privileges van het script.

Wat te doen?

• Werk OpenSSL zo snel mogelijk bij. Als je op je Linux-distro vertrouwt om een ​​centraal geïnstalleerde kopie te beheren, neem dan contact op met je distro-maker voor details. Als u vertrouwt op uw eigen build van OpenSSL in plaats van (of naast) een systeembrede versie, vergeet dan niet om die kopie ook bij te werken. Je zoekt 3.0.4 or 1.1.1p. Rennen openssl version om te zien welke versie je hebt.
• Overweeg om met pensioen te gaan c_rehash hulpprogramma als u het gebruikt. Het alles-in-één hulpprogramma openssl, dat in de eerste plaats vaak wordt gebruikt voor het genereren en ondertekenen van certificaten, bevat nu een ingebouwde subopdracht met de naam rehash hetzelfde werk te doen. Proberen openssl rehash -help te bezoeken voor meer informatie.
• Reinig uw in- en uitgangen. Ga er nooit vanuit dat de invoer die u ontvangt veilig is om ongewijzigd te gebruiken, en wees voorzichtig met de gegevens die u doorgeeft als uitvoer naar andere delen van uw code.
• Wees waakzaam voor meerdere fouten bij het beoordelen van code voor specifieke soorten bugs. Een programmeur die onvoorzichtig was met een system() commando op een plaats in de code kan elders soortgelijke fouten hebben gemaakt.

Programmeurs produceren (of reproduceren) vaak hetzelfde soort bug, meestal om volkomen onschuldige en begrijpelijke redenen.

Of ze waren zich niet bewust van die soort bug op het moment dat ze aan de code werkten, of ze namen een "tijdelijke snelkoppeling" om het prototypewerk te versnellen, maar gingen nooit meer terug om het later op te ruimen, of ze kopieerden en plakten iemand anders's gebrekkige code en maakten het hun eigen...