Serieuze beveiliging: GnuTLS volgt OpenSSL, repareert timing-aanvalsbug

Vorige week schreven we over een aantal fouten in geheugenbeheer die zijn opgelost in de nieuwste beveiligingsupdate van de populaire OpenSSL-coderingsbibliotheek.

Naast deze geheugenbugs hebben we ook gerapporteerd over een bug genaamd CVE-2022-4304: Timing Oracle in RSA-decodering.

In deze bug wordt hetzelfde gecodeerde bericht keer op keer naar een server verzonden, maar wordt de opvulling aan het einde van de gegevens aangepast om de gegevens ongeldig te maken, wat een soort onvoorspelbaar gedrag uitlokt...

…zou geen consistente hoeveelheid tijd in beslag nemen, ervan uitgaande dat je dicht bij het doel op het netwerk was en je op betrouwbare wijze kon raden hoe lang het gegevensoverdrachtgedeelte van het proces zou duren.

Niet alle gegevens worden gelijk verwerkt

Als u een verzoek afvuurt, meet hoe lang het antwoord duurt en de tijd aftrekt die is verbruikt bij het verzenden en ontvangen van netwerkgegevens op laag niveau, weet u hoe lang het de server heeft gekost om zijn interne berekening uit te voeren om het verzoek te verwerken .

Zelfs als u niet zeker weet hoeveel tijd er in het netwerk wordt verbruikt, kunt u op zoek gaan naar variaties in de retourtijden door veel verzoeken af ​​te vuren en heel veel monsters te verzamelen.

Als het netwerk betrouwbaar genoeg is om aan te nemen dat de netwerkoverhead grotendeels constant is, kunt u mogelijk statistische methoden gebruiken om af te leiden welk soort gegevenswijziging welke extra verwerkingsvertraging veroorzaakt.

Hieruit kunnen jullie iets afleiden over de structuur, of zelfs de inhoud, van de originele, niet-versleutelde gegevens die bij elk herhaald verzoek geheim moeten worden gehouden.

Zelfs als je maar één byte platte tekst kunt extraheren, dan zou dat niet mogen gebeuren.

Zogenaamd timing aanvallen van dit soort zijn altijd lastig, zelfs als je miljoenen valse pakketten moet verzenden en ze allemaal moet timen om enige kans te maken om slechts één byte aan platte tekstgegevens te herstellen...

…omdat netwerken sneller, voorspelbaarder zijn en veel meer belasting kunnen verwerken dan een paar jaar geleden.

Je zou kunnen denken dat miljoenen verraderlijke pakketjes die bijvoorbeeld het komende uur naar je worden verzonden, opvallen als een soort duim.

Maar “een miljoen pakketten per uur meer of minder dan normaal” is simpelweg geen bijzonder grote variatie meer.

Soortgelijke “orakel”-bug in GnuTLS

Welnu, dezelfde persoon die de bug-timing-bug voor het laatst opgelost in OpenSSL rapporteerde, rapporteerde ook een soortgelijke bug in GnuTLS rond dezelfde tijd.

Deze heeft de bug-ID CVE-2023-0361.

Hoewel GnuTLS niet zo populair of veelgebruikt is als OpenSSL, heeft u waarschijnlijk een aantal programma's in uw IT-omgeving, of zelfs op uw eigen computer, die het gebruiken of bevatten, mogelijk inclusief FFmpeg, GnuPG, Mplayer, QEMU , Rdesktop, Samba, Wget en Wireshark.

Ironisch genoeg verscheen de timingfout in GnuTLS in code die eigenlijk timingaanvalfouten moest registreren.

Zoals je kunt zien aan het codeverschil (diff) hieronder was de programmeur zich ervan bewust dat elke voorwaardelijke (if ... then) bewerking die wordt gebruikt bij het controleren en afhandelen van een decoderingsfout kan timingvariaties veroorzaken, omdat CPU's over het algemeen een andere hoeveelheid tijd nodig hebben, afhankelijk van welke kant uw code op gaat na een "branch" -instructie.

(Dat geldt vooral voor een branch die vaak de ene kant op gaat en zelden de andere kant op, omdat CPU's de neiging hebben om code die herhaaldelijk wordt uitgevoerd te onthouden of in de cache op te slaan om de prestaties te verbeteren, waardoor de zelden gebruikte code detecteerbaar trager wordt uitgevoerd.)

Maar de programmeur wilde nog steeds registreren dat er een aanval zou kunnen plaatsvinden, wat gebeurt als de if (ok) bovenstaande test mislukt en vertakt zich naar de else { ... } pagina.

Op dit punt roept de code de _gnutls_debug_log() functie, die enige tijd nodig heeft om zijn werk te doen.

Daarom heeft de codeur een opzettelijke oproep ingevoegd naar _gnutls_no_log() in de then { ... } deel van de code, dat pretendeert een ‘aanval’ te loggen terwijl er geen is, om te proberen de tijd die de code in beide richtingen besteedt, gelijk te trekken. if (ok) takinstructie kan duren.

Blijkbaar waren de twee codepaden echter niet voldoende vergelijkbaar in de tijd die ze in beslag namen (of misschien wel de tijd die ze in beslag namen). _gnutls_debug_log() (de functie op zichzelf was onvoldoende consistent in het omgaan met verschillende soorten fouten) en een aanvaller kon na ongeveer een miljoen pogingen de decryptie-verklikkers gaan onderscheiden.

Wat te doen?

Als je een programmeur bent: de bugfix hier was eenvoudig en volgde het ‘less is more’-principe.

De code in het roze hierboven, waarvan werd aangenomen dat deze sowieso geen erg nuttige aanvalsdetectiegegevens opleverde, werd eenvoudigweg verwijderd, op grond van het feit dat code die er niet is, niet per ongeluk kan worden gecompileerd, ongeacht je build-instellingen...

…en code die niet is gecompileerd, kan nooit worden uitgevoerd, hetzij per ongeluk, hetzij door opzet.

Als u een GnuTLS-gebruiker bent: de onlangs uitgebrachte versie 3.7.9 en de “nieuwe productsmaak” 3.8.0 heb deze oplossing, samen met verschillende andere, inbegrepen.

Als je een Linux-distributie gebruikt, controleer dan of er updates zijn voor elke centraal beheerde gedeelde bibliotheekversie van GnuTLS die je hebt, en ook voor apps die hun eigen versie met zich meebrengen.

Zoek op Linux naar bestanden met de naam libgnutls*.so om gedeelde bibliotheken te vinden die rondslingeren, en zoek naar gnutls-cli om kopieën te vinden van het opdrachtregelhulpprogramma dat vaak bij de bibliotheek wordt geleverd.

Je kan lopen gnutls-cli -vv om erachter te komen welke versie van libgnutls het is dynamisch gekoppeld aan:

 $ gnutls-cli -vv gnutls-cli 3.7.9 <-- mijn Linux-distro kreeg afgelopen vrijdag de update (2023-02-10)

---

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://nakedsecurity.sophos.com/2023/02/13/serious-security-gnutls-follows-openssl-fixes-timing-attack-bug/