Dyskusja o podatności CVE-2014-2734

Zamieszczone przez emboss 2014-05-09
Tłumaczone przez crabonature

Zostaliśmy niedawno poinformowani o możliwej luce bezpieczeństwa opublikowanej jako CVE-2014-2734. Jednakże bazując na naszej szczegółowej poniższej analizie, nie uważamy by Ruby był podatny.

Luka ta może umożliwić osobie atakującej podrobić arbitralne główne certyfikaty modyfikując podpis certyfikatu, zastępując efektywnie oryginalny klucz prywatny certyfikatu z jednym wybranym przez atakującego.

Dowód koncepcji

Poniżej jest nasza analiza CVE-2014-2734, byliśmy w stanie zredukować oryginalny dowód, która wierzymy, że obejmuje esencję dowodu:

require 'openssl'

forge_key = OpenSSL::PKey::RSA.new(2048)
raw_certificate = File.read("arbitrary.cer")
cert = OpenSSL::X509::Certificate.new(raw_certificate)
resigned_cert = cert.sign(spoof, OpenSSL::Digest::SHA1.new)

resigned_cert.verify(key) #=> true

Może być zaskakujące, że X509Certificate#verify zwraca true. Oryginalny certyfikat może zawierać Subject Public Key Info wskazujący oryginalny klucz publiczny, który jest różny od publicznego klucza forge_key. Dokładniej, para kluczy publiczny / prywatny użyta do ponownego podpisu certyfikatu nie pasuje dłużej do oryginalnego klucza publicznego wskazywanego w Subject Public Key Info. Dlaczego #verify zwraca true?

Jak klucze są weryfikowane

X509Certificate#verify używa funkcji OpenSSLa X509_verify wewnętrznie, która deleguje do ASN1_item_verify. Te funkcje stwierdzają autentyczność podpisu danego klucza publicznego, który został przedstawiony. Jednak nie będą sprawdzać czy podany klucz rzeczywiście pasuje do wymienionych w certyfikacie w Subject Public Key Info. Oznacza to, że wartość true jest oczekiwanym wynikiem dla X509Certificate#verify w tym scenariuszu. Ominięcie tego sprawdzenia nie ma znaczącego wpływu na ogólne bezpieczeństwo modelu zaufania X.509.

Sekcja 4.1.1.3 z RFC 5280 wprost stwierdza, że obliczanie podpisu certyfikatu centrum certyfikacji potwierdza prawidłowość informacji zawartych w certyfikacie. Podczas gdy ta zasada jest naruszona w powyższym przykładowym kodzie, nie stanowi to zagrożenia dla bezpieczeństwa. Certyfikat podrobiony lub zmodyfikowany w ten sposób nie może być wykorzystany, chyba że ktoś jest w stanie przekonać do jawnego zaufania certyfikatowi, który narusza tę zasadę.

Potencjalne zagrożenia

Są dwa przypadki do rozważenia:

Ponowne podpisanie certyfikatu głównego

Jako użytkownicy ufamy bezwarunkowo głównym certyfikatom. Nawet gdy nie zawierają poprawnych informacji. Sam stan bycia publicznie akceptowalnym głównym certyfikatem jest tym co utrzymuje go nieskazitelnym. Są to wartości wstępnie skonfigurowane w zaufanych magazynach przeglądarek i systemów operacyjnych. Samo posiadanie ich wyznacza je jako poprawne zaufane odniesienia. Na przykład domyślnie OpenSSL sam nie sprawdza podpisu certyfikatu głównego z podpisem własnym z tych samych powodów dokumentacja X509_V_FLAG_CHECK_SS_SIGNATURE.

Ponownie podpisany główny certyfikat staje się certyfikatem z podpisem własnym. (aczkolwiek z niepoprawnym Subject Public Key Info). Jest to nie groźniejsze niż normalny certyfikat główny z własnym podpisem. w rzeczywistości, każdy może wyprodukować główny certyfikat z podpisem własnym, który może pasować całkowicie do poprawnego głównego certyfikatu - poza podpisem. Ponieważ wierzymy głownym certyfikatom tylko przez ich posiadanie, taki oszukany certyfikat nie ma sensu bez aktywnej zgody klienta do zaufania mu.

Ponowne podpisanie certyfikatu pośredniego lub końcowego

Ponowne podpisanie certyfikatu niebazowego nie narusza bezpieczeństwa modelu zaufania X.509. Podczas gdy zwyczajowo nie posiadamy takiego typu certyfikatów, to zawczasu ich podrobienie może być wykryte podczas procedury walidacji ścieżki. Tutaj każdy podpis niebazowego certyfikatu jest weryfikowany przy użyciu publicznego klucza wydawcy certyfikatu. W pewnym miejscu łańcucha certyfikatu fałszerstwo będzie ostatecznie wykrywane w postaci nieprawidłowej wartości podpisu certyfikatu.

Wnioski

Jako wniosek wierzymy , że X509Certificate#verify działa odpowiednio. Inni niezależnie doszli do takich samych wniosków przez co zakwestionowaliśmy w ten sposób CVE-2014-2734, i zawnioskowaliśmy o jego unieważnienie. Możesz znaleźć pełną analizę oryginalnego dowodu zawierającą komentarze.