La conferința 39C3 (Chaos Communication Congress) care se desfășoară în Germania, au fost dezvăluite detalii despre 12 vulnerabilități necunoscute anterior și care rămân nerezolvate (0-day) în instrumentele GnuPG (GNU Privacy Guard), care oferă utilitare compatibile cu standardele OpenPGP și S/MIME pentru criptarea datelor, gestionarea semnăturilor electronice, gestionarea cheilor și accesul la depozitele publice de chei. Cele mai periculoase vulnerabilități permit ocolirea verificării semnăturilor digitale și executarea de cod în timpul procesării datelor criptate în format ASCII (ASCII Armor). Prototypele de exploatare și corecțiile promit să fie publicate ulterior. Identificatorii CVE nu au fost atribuiți deocamdată.
Vulnerabilitățile sunt cauzate de erori în codul de procesare a datelor și analiza formatelor și nu sunt legate de breșe în algoritmii criptografici. De exemplu, o eroare în parser duce la o eroare în determinarea datelor semnate efectiv și creează condiții în care datele verificate pot să nu coincidă cu datele semnate, permițând atacatorului să substituie textul simplu fără acces la cheia privată.
Problemele identificate:
- O eroare în codul parser-ului de date criptate, transmise în format ASCII-Armor (fișiere text cu blocul „BEGIN/END PGP ARMORED FILE”), care duce la scrierea în zona de memorie dincolo de limitele buffer-ului. Problema poate duce la executarea de cod în timpul procesării în gpg a datelor formate special. Vulnerabilitatea se manifestă în funcția armor_filter() și este cauzată de o dublare a incrementului contorului „n” în bucla „for” - deși se indică „n++” în chenarul buclei, contorul este crescut și în corpul buclei atunci când se scriu date în buffer-ul „buf[n++]”. În cele din urmă, un byte suplimentar este scris dincolo de buffer, iar variabila cu dimensiunea „ret_len” este setată la o valoare care depășește valoarea efectivă.
- Posibilitatea de a crea sau de a suprascrie orice fișier, în funcție de permisiunile curente, din cauza procesării incorecte a conținutului câmpului „filename” din pachetul de date. Vulnerabilitatea poate fi utilizată pentru a organiza executarea de cod în sistem atunci când destinatarii rulează comenzile „gpg —decrypt poc.enc” și „gpg poc.enc” pentru a vizualiza fișierul poc.enc trimis de atacator. Executarea codului poate fi obținută, de exemplu, prin crearea fișierelor ~/ .bash_completion sau ~/ .ssh /authorized_keys.
- Possibilitatea de a înlocui textul deschis, afișat utilizatorului atunci când se specifică opțiunea „—decrypt” și verificarea folosind semnături digitale furnizate separat (Detached Signature, create cu opțiunea „—detach-sig” și oferite într-un fișier sig separat). Problema constă în faptul că, atunci când mesajul și fișierul sig sunt trimise separat, un atacator, controlând traficul intermediar (MITM), poate modifica fișierul sig, după care verificarea va rămâne reușită, dar la vizualizarea mesajului din fișierul sig prin opțiunea „—decrypt” va apărea un alt conținut. echo Plaintext > plaintext gpg —detach-sig plaintext # modificarea plaintext.sig de către atacator cu adăugarea unui text suplimentar gpg —verify plaintext.sig plaintext # verificat gpg —decrypt plaintext.sig # verificat, dar se afișează un alt text
- Posibilitatea de a completa un mesaj semnat cu date arbitrare, menținând verificarea reușită a semnăturii. Problema apare din cauza trunchierii datelor la limita de 20000 de caractere în timpul calculării hash-ului.
- Verificarea incorectă a codurilor de criptare autentificată (MDC — Modification Detection Codes), permițând manipularea pachetelor criptate astfel încât, la decriptare, conținutul obținut să fie tratat ca un alt tip de pachet (de exemplu, perceput ca destinat publicării unei chei publice).
- Posibilitatea de a înlocui date suplimentare în semnăturile CS (Cleartext Signature), create folosind flagul „—not-dash-escaped” sau convertite din semnături furnizate separat (Detached Signature). Vulnerabilitatea poate fi utilizată pentru a crea utilizatorului o impresie falsă cu privire la datele care au fost de fapt semnate. De exemplu, utilizatorul poate descărca din surse de încredere o cheie corectă pentru verificarea semnăturii digitale, dar atacatorul, în timpul unui atac MITM, poate modifica imaginea iso descărcată de utilizator și adăuga un hash suplimentar în semnătura imaginii, astfel încât verificarea imaginii modificate să treacă cu succes, având în sistem cheia corectă de verificare.
- Substituirea datelor suplimentare în reprezentarea ASCII a semnăturii CS (Cleartext Signature) prin inserarea unui caracter cu cod nul. Vulnerabilitatea, de exemplu, permite inserarea de text arbitrar în antetul Hash.
- Interpretarea incorectă a formatului OpenPGP, care face ca mesajul „One-Pass Signed Message” în format ASCII să poată fi procesat ca mesaj „Cleartext Signature” printr-o anumită modificare a antetului. Vulnerabilitatea permite înlocuirea datelor originale semnate cu conținut dăunător, păstrând vizibilitatea unei verificări de succes.
- Lipsa unei separări clare în modul de prezentare a succesului verificării semnăturii digitale de conținutul mesajului, ceea ce permite crearea de mesaje nesemnate false, care, la executarea „gpg —decrypt”, arată ca fiind autentice.
- Posibilitatea de a crea mesaje OpenPGP care în gpg vor fi procesate diferit față de alte implementări OpenPGP. Problema este cauzată de modul în care sunt gestionate liniile foarte lungi în reprezentarea ASCII a datelor OpenPGP.
- Crearea condițiilor în procesul de verificare a semnăturii digitale pentru a reveni la un algoritm de verificare a hash-ului nesigur, SHA1.
- Posibilitatea de a înlocui propriile chei secundare (subkey) fără autorizarea acestora utilizând componenta privată a cheii principale. Atacul se realizează prin adăugarea unui depozit de chei fals folosind opțiunea „—keyring”.
Au fost identificate suplimentar două vulnerabilități în minisign, un instrument simplificat pentru crearea și verificarea semnăturilor digitale. Ambele vulnerabilități (1, 2) permit utilizarea secvențelor de control ale terminalului („\e[1E”) sau a caracterelor speciale („\r”) în câmpul comentariului pentru a modifica rezultatul programului, de exemplu, pentru a schimba informațiile despre rezultatul verificării.
Sursa: opennet.ro
