Vakava turvallisuus: GnuTLS seuraa OpenSSL:ää, korjaa ajoitushyökkäysvirheen

Viime viikolla kirjoitimme joukosta muistinhallinnan vikoja jotka korjattiin suositun OpenSSL-salauskirjaston uusimmassa tietoturvapäivityksessä.

Muistivirheiden lisäksi raportoimme myös bugista, joka on kopioitu CVE-2022-4304: Ajoitus Oracle RSA-salauksenpurkussa.

Tässä virheessä samaa salattua viestiä käynnistetään yhä uudelleen ja uudelleen palvelimella, mutta datan lopussa olevaa täytettä muutetaan niin, että tiedot eivät kelpaa, ja siten provosoi jonkinlaista arvaamatonta käyttäytymistä...

…ei vie tasaisesti aikaa, jos olet lähellä kohdetta verkossa, jotta voit luotettavasti arvata, kuinka kauan prosessin tiedonsiirtoosuus kestää.

Kaikkia tietoja ei käsitellä samalla tavalla

Jos käynnistät pyynnön, määrität vastauksen keston ja vähennät verkon datan matalan tason lähettämiseen ja vastaanottamiseen kuluneen ajan, tiedät kuinka kauan palvelimella kesti suorittaa sisäiset laskutoimitukset pyynnön käsittelemiseksi. .

Vaikka et olisi varma, kuinka paljon aikaa verkossa käytetään, voit etsiä vaihteluita meno-paluu-ajoissa lähettämällä paljon pyyntöjä ja keräämällä näytteitä.

Jos verkko on riittävän luotettava olettaakseen, että verkon ylimääräiset kustannukset ovat suurelta osin vakioita, voit ehkä käyttää tilastollisia menetelmiä päätelläksesi, minkälainen tietojen muutos aiheuttaa minkälaisen ylimääräisen käsittelyviiveen.

Tästä monet voivat päätellä jotain alkuperäisen salaamattoman datan rakenteesta tai jopa sisällöstä, joka on tarkoitus pitää salassa jokaisen toistuvan pyynnön sisällä.

Vaikka voit poimia vain yhden tavun selkeää tekstiä, niin sen ei pitäisi tapahtua.

Niin sanottu ajoitushyökkäykset Tällaiset ovat aina hankalia, vaikka saatat joutua lähettämään miljoonia vääriä paketteja ja ajoittamaan ne kaikki, jotta sinulla on mahdollisuus palauttaa vain yksi tavu selkeää tekstiä...

...koska verkot ovat nopeampia, ennakoitavampia ja pystyvät käsittelemään paljon enemmän kuormaa kuin muutama vuosi sitten.

Saatat ajatella, että miljoonat petolliset paketit, jotka lähetettiin sinulle esimerkiksi seuraavan tunnin aikana, erottuvat joukosta kuin peukalo.

Mutta "miljoona pakettia tunnissa enemmän tai vähemmän kuin tavallisesti" ei yksinkertaisesti ole enää erityisen suuri vaihtelu.

Samanlainen "oracle" -vika GnuTLS:ssä

No, sama henkilö, joka ilmoitti viimeiseksi korjatun virheajoitusvirheen OpenSSL:ssä, ilmoitti myös a samanlainen bugi GnuTLS:ssä suunnilleen samaan aikaan.

Tällä on virheen tunniste CVE-2023-0361.

Vaikka GnuTLS ei olekaan yhtä suosittu tai laajalti käytetty kuin OpenSSL, sinulla on luultavasti IT-alueellasi tai jopa omassa tietokoneessasi useita ohjelmia, jotka käyttävät sitä tai sisältävät sen, mukaan lukien mahdollisesti FFmpeg, GnuPG, Mplayer, QEMU. , Rdesktop, Samba, Wget ja Wireshark.

Ironista kyllä, GnuTLS:n ajoitusvirhe ilmeni koodissa, jonka piti alun perin kirjata ajoitushyökkäysvirheet.

Kuten koodin erosta näkyy (JM) alla ohjelmoija tiesi, että kaikki ehdolliset (if ... then) -toiminto, jota käytetään salauksen purkuvirheen tarkistamisessa ja käsittelyssä, saattaa aiheuttaa ajoitusvaihteluita, koska CPU:t vievät yleensä eri ajan sen mukaan, mihin suuntaan koodisi kulkee "haara"-käskyn jälkeen.

(Tämä pätee erityisesti haaraan, joka kulkee usein yhteen suuntaan ja harvoin toiseen suuntaan, koska prosessorit yleensä muistavat tai tallentavat välimuistiin koodin, joka suoritetaan toistuvasti suorituskyvyn parantamiseksi, mikä tekee harvoin otetun koodin suorittamisesta havaittavasti hitaampaa.)

Mutta ohjelmoija halusi silti kirjata, että hyökkäys saattaa olla tapahtumassa, mikä tapahtuu, jos if (ok) yllä oleva testi epäonnistuu ja haarautuu else { ... } osiossa.

Tässä vaiheessa koodi kutsuu _gnutls_debug_log() toimintoa, joka voi kestää jonkin aikaa toimiakseen.

Siksi kooderi lisäsi tarkoituksellisen kutsun _gnutls_no_log() vuonna then { ... } osa koodista, joka teeskentelee kirjaavansa "hyökkäyksen", kun sitä ei ole, yrittääkseen tasoittaa aikaa, jonka koodi viettää kumpaankin suuntaan. if (ok) sivuliikkeen opetus voi kestää.

Ilmeisesti nämä kaksi koodipolkua eivät kuitenkaan olleet riittävän samankaltaisia ​​käyttöaikana (tai kenties _gnutls_debug_log() toiminto yksinään ei ollut riittävän johdonmukainen erilaisten virheiden käsittelyssä), ja hyökkääjä saattoi alkaa erottaa salauksen purkamisen ilmaisimia noin miljoonan yrityksen jälkeen.

Mitä tehdä?

Jos olet ohjelmoija: Virheenkorjaus oli yksinkertainen ja noudattaa "vähemmän on enemmän" -periaatetta.

Yllä oleva vaaleanpunainen koodi, jonka ei katsottu antavan hirveän hyödyllistä hyökkäyksen havaitsemisdataa, poistettiin yksinkertaisesti sillä perusteella, että koodia, jota ei ole, ei voida vahingossa kääntää sisään rakennusasetuksistasi riippumatta...

…ja koodi, jota ei ole käännetty, ei voi koskaan ajaa, joko vahingossa tai suunnittelussa.

Jos olet GnuTLS-käyttäjä: äskettäin julkaistu versio 3.7.9 ja "uuden tuotteen maku" 3.8.0 sisällytä tämä korjaus useiden muiden ohella.

Jos käytät Linux-distroa, tarkista, onko saatavilla päivityksiä mihin tahansa GnuTLS:n keskitetysti hallinnoituun jaettuun kirjastoversioon sekä sovelluksiin, jotka tuovat mukanaan oman versionsa.

Etsi Linuxissa tiedostoja, joilla on nimi libgnutls*.so löytääksesi jaettuja kirjastoja ja etsiäksesi niitä gnutls-cli löytääksesi kopiot komentorivityökalusta, joka usein sisältyy kirjastoon.

Voit ajaa gnutls-cli -vv saadaksesi selville, mikä versio libgnutls se on dynaamisesti linkitetty:

 $ gnutls-cli -vv gnutls-cli 3.7.9 <-- Linux-distroni sai päivityksen viime perjantaina (2023-02-10)

---

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• Platoblockchain. Web3 Metaverse Intelligence. Tietoa laajennettu. Pääsy tästä.
• Lähde: https://nakedsecurity.sophos.com/2023/02/13/serious-security-gnutls-follows-openssl-fixes-timing-attack-bug/