Na odbywającej się w Niemczech konferencji 39C3 (Chaos Communication Congress) ujawniono szczegóły dotyczące 12 wcześniej nieznanych i pozostających niepoprawionych (0-day) luk w oprogramowaniu GnuPG (GNU Privacy Guard), które oferuje zgodne z standardami OpenPGP i S/MIME narzędzia do szyfrowania danych, pracy z podpisami elektronicznymi, zarządzania kluczami oraz dostępu do publicznych magazynów kluczy. Najbardziej niebezpieczne luki umożliwiają ominięcie weryfikacji podpisu cyfrowego i wykonanie kodu podczas przetwarzania zaszyfrowanych danych w formacie ASCII (ASCII Armor). Prototypy exploitów i poprawki mają być opublikowane w późniejszym czasie. Numery identyfikacyjne CVE nie zostały jeszcze przypisane.
Luki są spowodowane błędami w kodzie do przetwarzania danych i analizy formatów, i nie są związane z dziurami w algorytmach kryptograficznych. Na przykład, błąd w parserze prowadzi do awarii w określaniu faktycznie podpisanych danych i tworzy warunki, w których weryfikowane dane mogą nie odpowiadać danym podpisanym, co pozwala atakującemu na zamianę otwartego tekstu bez dostępu do klucza prywatnego.
Zidentyfikowane problemy:
- Błąd w kodzie parsera zaszyfrowanych danych, przekazywanych w formacie ASCII-Armor (pliki tekstowe z blokiem „BEGIN/END PGP ARMORED FILE”), prowadzący do zapisu w obszarze pamięci poza granicami bufora. Problem może prowadzić do wykonania kodu podczas przetwarzania w gpg specjalnie sformatowanych danych. Luka ujawnia się w funkcji armor_filter() i jest spowodowana podwójnym inkrementowaniem licznika „n” w pętli „for” — pomimo wskazania „n++” w samej pętli, licznik zwiększa się również w ciele pętli podczas zapisywania danych w buforze „buf[n++]”. W rezultacie do bufora zapisywany jest dodatkowy bajt, a zmienna o rozmiarze „ret_len” jest ustawiana na wartość przekraczającą rzeczywistą.
- Możliwość tworzenia lub nadpisywania dowolnego pliku, w zależności od aktualnych praw dostępu, z powodu niewłaściwego przetwarzania zawartości pola „filename” w pakiecie z danymi. Luka ta może być wykorzystywana do wykonania kodu w systemie podczas wykonywania przez odbiorcę komend „gpg —decrypt poc.enc” i „gpg poc.enc” w celu przeglądania przesłanego przez atakującego pliku poc.enc. Wykonanie kodu można osiągnąć, na przykład, poprzez utworzenie plików ~/bash_completion lub ~/ssh/authorized_keys.
- Możliwość podmiany otwartego tekstu wyświetlanego użytkownikowi przy użyciu opcji „—decrypt” oraz weryfikacji za pomocą oddzielnie dostarczonych cyfrowych podpisów (Detached Signature, tworzone przez opcję „—detach-sig” i dostarczane w osobnym pliku sig). Istota problemu polega na tym, że przy osobnej wysyłce wiadomości i pliku sig, atakujący kontrolujący pośredni ruch (MITM) może wprowadzić zmiany w pliku sig, po czym weryfikacja pozostanie pomyślna, ale przy wyświetlaniu wiadomości z pliku sig za pomocą opcji „—decrypt” zostanie wyprowadzone inne zawartość. echo Plaintext > plaintext gpg —detach-sig plaintext # zmiana plaintext.sig przez atakującego poprzez dodanie dodatkowego tekstu gpg —verify plaintext.sig plaintext # zweryfikowano gpg —decrypt plaintext.sig # zweryfikowano, ale wyświetla inną treść
- Możliwość dopisania do podpisanej wiadomości dowolnych danych przy zachowaniu pomyślnej weryfikacji podpisu. Problem wynika z obcinania danych na granicy 20000 znaków podczas obliczania hasha.
- Nieprawidłowa weryfikacja kodów autoryzowanego szyfrowania (MDC — Modification Detection Codes), pozwalająca na manipulowanie zaszyfrowanymi pakietami w taki sposób, że przy odszyfrowaniu otrzymana zawartość będzie traktowana jako inny typ pakietu (na przykład zinterpretowana jako przeznaczona do publikacji otwarty klucz).
- Możliwość podstawienia dodatkowych danych w CS-podpisach (Cleartext Signature), utworzonych z użyciem flagi „—not-dash-escaped” lub przekształconych z odrębnie dostarczonych podpisów (Detached Signature). Luka ta może być wykorzystywana do stworzenia u użytkownika fałszywego wrażenia, jakie dane faktycznie zostały podpisane. Na przykład użytkownik może pobrać z zaufanych źródeł poprawny klucz do weryfikacji cyfrowego podpisu, ale atakujący w trakcie ataku MITM może podmienić pobierany przez użytkownika obraz iso i dodać do podpisu obrazu dodatkowy hash w sposób, w jaki weryfikacja podmienionego obrazu zakończy się sukcesem przy posiadaniu w systemie poprawnego klucza weryfikacyjnego.
- Podstawianie dodatkowych danych w ASCII-reprezentacji CS-podpisu (Cleartext Signature) poprzez wstawienie znaku o zerowym kodzie. Luka ta pozwala na przykład wstawić dowolny tekst do nagłówka Hash.
- Niepoprawna interpretacja formatu OpenPGP, przez co wiadomość „One-Pass Signed Message” w formacie ASCII może być przetwarzana jako „Cleartext Signature” przy pewnej zmianie nagłówka. Luka pozwala na zastąpienie oryginalnych podpisanych danych złośliwą treścią, zachowując pozory udanej weryfikacji.
- Brak wyraźnego rozdzielenia w wyjściu informacji o sukcesie weryfikacji podpisu cyfrowego i treści wiadomości, co umożliwia tworzenie fałszywych, nies odpowiednich wiadomości, które po wykonaniu „gpg —decrypt” wyglądają na autentyczne.
- Możliwość tworzenia wiadomości OpenPGP, które w gpg będą przetwarzane inaczej niż w innych implementacjach OpenPGP. Problem wynika z cechy przetwarzania bardzo długich linii w ASCII-reprezentacji danych OpenPGP.
- Tworzenie warunków podczas weryfikacji podpisu cyfrowego do kompromitacji algorytmu weryfikacji hasha do niebezpiecznego SHA1.
- Możliwość podmiany własnych kluczy pomocniczych (subkey) bez ich autoryzacji przy użyciu prywatnego komponentu klucza głównego. Atak realizowany jest poprzez dodanie fałszywego repozytorium kluczy za pomocą opcji „—keyring”.
Dodatkowo zidentyfikowano dwie luki w minisign, uproszczonym narzędziu do tworzenia i weryfikacji podpisów cyfrowych. Obie luki (1, 2) umożliwiają wykorzystanie sekwencji sterujących terminala („\e[1E”) lub znaków specjalnych („\r”) w polu komentarza do modyfikacji wyjścia programu, na przykład do zamiany informacji o wyniku weryfikacji.
Źródło: opennet.ru
