Komoly biztonság: A GnuTLS az OpenSSL-t követi, javítja az időzítési támadási hibát

A múlt héten egy csomó dologról írtunk memóriakezelési hibák amelyeket a népszerű OpenSSL titkosítási könyvtár legújabb biztonsági frissítésében javítottak ki.

Ezekkel a memóriahibákkal együtt beszámoltunk egy szinkronizált hibáról is CVE-2022-4304: Az Oracle időzítése az RSA visszafejtésben.

Ebben a hibában ugyanazt a titkosított üzenetet újra és újra leütik egy szerveren, de módosítják az adatok végén lévő kitöltést, hogy az adatok érvénytelenek legyenek, és ezáltal valamiféle előre nem látható viselkedést váltson ki…

…nem tartana állandóan sok időt, ha feltételezzük, hogy közel van a célhoz a hálózaton, hogy megbízhatóan meg tudja tippelni, mennyi ideig tart a folyamat adatátviteli része.

Nem minden adatot dolgoznak fel egyformán

Ha elindít egy kérést, időzíti, mennyi ideig tart a válasz, és levonja a hálózati adatok alacsony szintű küldéséhez és fogadásához szükséges időt, akkor tudni fogja, mennyi ideig tartott a szerver a belső számítás elvégzéséhez a kérés feldolgozásához. .

Még akkor is, ha nem biztos benne, hogy mennyi időt használnak fel a hálózatban, sok kérés indításával és rengeteg minta gyűjtésével keresheti az oda-vissza utazási idő eltéréseit.

Ha a hálózat elég megbízható ahhoz, hogy feltételezzük, hogy a hálózati többletterhelés nagymértékben állandó, akkor statisztikai módszerekkel következtethet arra, hogy az adatmódosítás milyen típusú többletfeldolgozási késleltetést okoz.

Ebből sokan következtethetnek az eredeti, titkosítatlan adatok szerkezetére, vagy akár tartalmára, amelyet minden ismételt kérésben titokban kell tartani.

Még ha csak egy bájt egyszerű szöveget is tud kivonni, ennek nem szabad megtörténnie.

Úgynevezett időzítési támadások az ilyen jellegűek mindig gondot okoznak, még akkor is, ha hamis csomagok millióit kell küldenie, és mindegyiket időzítenie kell, hogy esélye legyen csak egy bájt egyszerű szöveges adat helyreállítására...

…mert a hálózatok gyorsabbak, kiszámíthatóbbak és sokkal nagyobb terhelést képesek kezelni, mint néhány évvel ezelőtt.

Azt gondolhatná, hogy a rád küldött áruló csomagok milliói, mondjuk a következő órában, úgy tűnnek majd fel, mint egy hüvelykujj.

De „egymillió csomag óránként több vagy kevesebb, mint máskor” egyszerűen nem jelent különösebben nagy eltérést.

Hasonló „oracle” hiba a GnuTLS-ben

Nos, ugyanaz a személy, aki bejelentette az OpenSSL-ben végleg kijavított hibaidőzítési hibát, szintén beszámolt a hasonló hiba a GnuTLS-ben nagyjából ugyanabban az időben.

Ennek megvan a hibaazonosítója CVE-2023 0361-.

Bár a GnuTLS nem annyira népszerű vagy széles körben használt, mint az OpenSSL, valószínűleg számos olyan program van az IT-területén, vagy akár a saját számítógépén, amelyek használják vagy tartalmazzák, például FFmpeg, GnuPG, Mplayer, QEMU. , Rdesktop, Samba, Wget és Wireshark.

Ironikus módon a GnuTLS időzítési hibája abban a kódban jelent meg, amelynek eleve az időzítési támadási hibákat kellett volna naplóznia.

Ahogy a kódkülönbségből is látszik (diff) alatt a programozó tisztában volt azzal, hogy minden feltételes (if ... then) a visszafejtési hiba ellenőrzésére és kezelésére használt művelet időbeli eltéréseket okozhat, mivel a CPU-k általában eltérő időt vesznek igénybe attól függően, hogy a kód melyik irányba halad egy „elágazó” utasítás után.

(Ez különösen igaz egy olyan ágra, amely gyakran megy az egyik irányba, és ritkán a másik irányba, mert a CPU-k hajlamosak megjegyezni vagy gyorsítótárazni azt a kódot, amely többször fut a teljesítmény javítása érdekében, így a ritkán használt kódok észlelhetően lassabban futnak.)

De a programozó továbbra is naplózni akarta, hogy támadás történhet, ami akkor történik, ha a if (ok) A fenti teszt meghiúsul, és a else { ... } szakasz.

Ezen a ponton a kód meghívja a _gnutls_debug_log() funkciót, amely elég sokáig tarthat a működéséhez.

Ezért a kódoló szándékosan hívta be _gnutls_no_log() a then { ... } a kód egy része, amely úgy tesz, mintha „támadást” naplózna, ha nincs, annak érdekében, hogy megpróbálja kiegyenlíteni azt az időt, amelyet a kód eltölt a if (ok) ági utasítást vehet igénybe.

Úgy tűnik azonban, hogy a két kódútvonal nem volt kellően hasonló az elhasználódásuk ideje alatt (vagy talán a _gnutls_debug_log() a funkció önmagában nem volt kellően konzisztens a különböző típusú hibák kezelésében), és a támadó körülbelül egymillió próbálkozás után képes volt megkülönböztetni a visszafejtési visszajelzőket.

Mit kell tenni?

Ha programozó vagy: A hibajavítás itt egyszerű volt, és a „kevesebb több” elvet követte.

A fenti rózsaszínű kódot, amelyről úgy ítélték meg, hogy amúgy sem volt túl hasznos támadásészlelési adat, egyszerűen törölték, azzal az indokkal, hogy az ott nem található kódot nem lehet véletlenül lefordítani, függetlenül a build beállításaitól…

…és a nem lefordított kód soha nem futhat le, akár véletlenül, akár tervszerűen.

Ha Ön GnuTLS felhasználó: a nemrég megjelent verzió 3.7.9 és az „új termék íze” 3.8.0 tartalmazza ezt a javítást számos mással együtt.

Ha Linux disztribúciót futtat, ellenőrizze, hogy vannak-e frissítések a GnuTLS központilag felügyelt megosztott könyvtári verziójához, valamint a saját verziójukat hozó alkalmazásokhoz.

Linuxon keressen fájlokat a névvel libgnutls*.so hogy megtalálja a körülöttük lévő megosztott könyvtárakat, és keressen rá gnutls-cli hogy megtalálja a könyvtárban gyakran megtalálható parancssori segédprogram másolatait.

Futtathatod gnutls-cli -vv hogy megtudja, melyik verziója libgnutls dinamikusan kapcsolódik:

 $ gnutls-cli -vv gnutls-cli 3.7.9 <-- a Linux disztribúcióm múlt pénteken kapta meg a frissítést (2023-02-10)

---

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. Hozzáférés itt.
• Forrás: https://nakedsecurity.sophos.com/2023/02/13/serious-security-gnutls-follows-openssl-fixes-timing-attack-bug/