Resna varnost: GnuTLS sledi OpenSSL, odpravlja napako časovnega napada

Prejšnji teden smo pisali o kopici napake pri upravljanju pomnilnika ki so bile odpravljene v zadnji varnostni posodobitvi priljubljene šifrirne knjižnice OpenSSL.

Poleg teh pomnilniških napak smo poročali tudi o sinhronizirani napaki CVE-2022-4304: Oracle za določanje časa v dešifriranju RSA.

Pri tej napaki sprožanje istega šifriranega sporočila znova in znova na strežniku, vendar spreminjanje oblazinjenja na koncu podatkov, da postanejo podatki neveljavni, in tako izzove nekakšno nepredvidljivo vedenje ...

... ne bi trajalo dosledno dolgo, ob predpostavki, da ste blizu cilja v omrežju, da lahko zanesljivo ugibate, kako dolgo bo trajal del postopka prenosa podatkov.

Vsi podatki se ne obdelujejo enako

Če sprožite zahtevo, merite, koliko časa traja odgovor, in odštejete čas, ki ga porabi nizkonivojsko pošiljanje in prejemanje omrežnih podatkov, veste, koliko časa je strežnik potreboval, da je opravil svoj notranji izračun za obdelavo zahteve .

Tudi če niste prepričani, koliko časa je porabljenega v omrežju, lahko poiščete razlike v povratnih časih tako, da sprožite veliko zahtev in zberete kopico vzorcev.

Če je omrežje dovolj zanesljivo, da domnevamo, da je obremenitev omrežja večinoma konstantna, boste morda lahko uporabili statistične metode za sklepanje, katera vrsta spremembe podatkov povzroča kakšno dodatno zamudo pri obdelavi.

Iz tega lahko mnogi sklepajo nekaj o strukturi ali celo vsebini prvotnih nešifriranih podatkov, ki naj bi bili skrivni znotraj vsake ponovljene zahteve.

Tudi če lahko izvlečete samo en bajt golega besedila, se to ne bi smelo zgoditi.

Tako imenovano časovni napadi te vrste so vedno težavne, tudi če boste morda morali poslati na milijone lažnih paketov in jih vse časovno določiti, da boste imeli kakršno koli možnost, da obnovite samo en bajt podatkov v navadnem besedilu ...

… ker so omrežja hitrejša, bolj predvidljiva in zmožna prenesti veliko večjo obremenitev kot pred nekaj leti.

Morda mislite, da bodo milijoni zahrbtnih paketov, poslanih proti vam v, recimo, naslednji uri, izstopali kot nekakšen palec.

Toda »milijon paketov na uro več ali manj kot običajno« preprosto ni več posebno velika razlika.

Podobna napaka »oracle« v GnuTLS

No, ista oseba, ki je poročala o časovni napaki pri zadnji napaki v OpenSSL, je prijavila tudi podobna napaka v GnuTLS približno ob istem času.

Ta ima identifikator hrošča CVE-2023-0361.

Čeprav GnuTLS ni tako priljubljen ali široko uporabljan kot OpenSSL, imate verjetno v svojem IT posestvu ali celo v svojem računalniku številne programe, ki ga uporabljajo ali vključujejo, po možnosti vključno s FFmpeg, GnuPG, Mplayerjem, QEMU , Rdesktop, Samba, Wget in Wireshark.

Ironično je, da se je časovna napaka v GnuTLS pojavila v kodi, ki naj bi najprej beležila napake časovnega napada.

Kot lahko vidite iz razlike v kodi (diff) spodaj se je programer zavedal, da vsak pogojni (if ... then) operacija, ki se uporablja pri preverjanju in obravnavi napake pri dešifriranju, lahko povzroči časovne razlike, ker procesorji na splošno potrebujejo različno količino časa, odvisno od tega, v katero smer gre vaša koda po navodilu »razvejanja«.

(To še posebej velja za vejo, ki gre pogosto v eno smer in le redko v drugo, ker si procesorji ponavadi zapomnijo ali predpomnijo kodo, ki se ponavljajoče izvaja, da bi izboljšali zmogljivost, zaradi česar redko vzeta koda deluje opazno počasneje.)

Toda programer je še vedno želel zabeležiti, da se lahko zgodi napad, kar se zgodi, če if (ok) zgornji test ne uspe in se razveja v else { ... } oddelek.

Na tej točki koda pokliče _gnutls_debug_log() funkcija, ki lahko traja kar nekaj časa, da opravi svoje delo.

Zato je kodirnik namerno vstavil klic na _gnutls_no_log() v then { ... } del kode, ki se pretvarja, da beleži »napad«, ko ga ni, da bi poskušal izenačiti čas, ki ga koda porabi v obe smeri if (ok) podružnica navodila lahko traja.

Očitno pa obe poti kode nista bili dovolj podobni v času, ki sta ga porabili (ali morda _gnutls_debug_log() funkcija sama po sebi ni bila dovolj dosledna pri obravnavi različnih vrst napak), napadalec pa bi lahko začel razlikovati signale dešifriranja po približno milijonu poskusov.

Kaj storiti?

Če ste programer: popravek napake je bil preprost in je sledil načelu "manj je več".

Koda v rožnati barvi zgoraj, za katero se je štelo, da tako ali tako ne daje strašno uporabnih podatkov za odkrivanje napadov, je bila preprosto izbrisana, ker kode, ki je ni, ni mogoče prevesti po pomoti, ne glede na vaše nastavitve gradnje ...

... in koda, ki ni prevedena v, ne more nikoli delovati, bodisi po naključju ali načrtu.

Če ste uporabnik GnuTLS: nedavno izdana različica 3.7.9 in "nov okus izdelka" 3.8.0 vključite ta popravek skupaj z različnimi drugimi.

Če uporabljate distribucijo Linuxa, preverite, ali so na voljo posodobitve katere koli različice GnuTLS s centralno upravljano knjižnico v skupni rabi, kot tudi za aplikacije, ki prinašajo svojo različico.

V sistemu Linux poiščite datoteke z imenom libgnutls*.so da poiščete vse knjižnice v skupni rabi, ki ležijo naokoli, in poiščete gnutls-cli da poiščete morebitne kopije pripomočka ukazne vrstice, ki je pogosto vključen v knjižnico.

Lahko tečeš gnutls-cli -vv da ugotovite, katero različico libgnutls je dinamično povezan z:

 $ gnutls-cli -vv gnutls-cli 3.7.9 <-- moj Linux distro je prejel posodobitev prejšnji petek (2023-02-10)

---

• Distribucija vsebine in PR s pomočjo SEO. Okrepite se še danes.
• Platoblockchain. Web3 Metaverse Intelligence. Razširjeno znanje. Dostopite tukaj.
• vir: https://nakedsecurity.sophos.com/2023/02/13/serious-security-gnutls-follows-openssl-fixes-timing-attack-bug/