Kerentanan eksekusi kode di Mozilla NSS saat memproses sertifikat

Kerentanan kritis (CVE-2021-43527) telah diidentifikasi di kumpulan perpustakaan kriptografi NSS (Layanan Keamanan Jaringan) yang dikembangkan oleh Mozilla, yang dapat menyebabkan eksekusi kode penyerang saat memproses tanda tangan digital DSA atau RSA-PSS yang ditentukan menggunakan Metode pengkodean DER ( Aturan Pengkodean Terhormat). Masalah ini, dengan nama kode BigSig, diselesaikan di NSS 3.73 dan NSS ESR 3.68.1. Pembaruan paket dalam distribusi tersedia untuk Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Belum ada pembaruan yang tersedia untuk Fedora.

Masalah terjadi pada aplikasi yang menggunakan NSS untuk menangani tanda tangan digital CMS, S/MIME, PKCS #7 dan PKCS #12, atau saat memverifikasi sertifikat dalam implementasi TLS, X.509, OCSP dan CRL. Kerentanan dapat muncul di berbagai aplikasi klien dan server yang mendukung TLS, DTLS dan S/MIME, klien email dan penampil PDF yang menggunakan panggilan NSS CERT_VerifyCertificate() untuk memverifikasi tanda tangan digital.

LibreOffice, Evolution dan Evince disebutkan sebagai contoh aplikasi yang rentan. Kemungkinan besar, masalah ini juga dapat memengaruhi proyek seperti Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss untuk server http Apache, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Namun, kerentanan tidak muncul di Firefox, Thunderbird dan Tor Browser, yang menggunakan perpustakaan mozilla::pkix terpisah, juga disertakan dalam NSS, untuk verifikasi. Browser berbasis Chromium (kecuali jika dibuat khusus dengan NSS), yang menggunakan NSS hingga tahun 2015, namun kemudian beralih ke BoringSSL, juga tidak terpengaruh oleh masalah ini.

Kerentanan ini disebabkan oleh kesalahan kode verifikasi sertifikat pada fungsi vfy_CreateContext dari file secvfy.c. Kesalahan terjadi ketika klien membaca sertifikat dari server dan ketika server memproses sertifikat klien. Saat memverifikasi tanda tangan digital berkode DER, NSS menerjemahkan tanda tangan tersebut ke dalam buffer berukuran tetap dan meneruskan buffer tersebut ke modul PKCS #11. Selama pemrosesan lebih lanjut, ukuran tanda tangan DSA dan RSA-PSS salah diperiksa, yang menyebabkan kelebihan buffer yang dialokasikan untuk struktur VFYContextStr jika ukuran tanda tangan digital melebihi 16384 bit (2048 byte dialokasikan untuk buffer, tetapi tidak dicentang tanda tangannya boleh lebih besar) ).

Kode yang mengandung kerentanan dapat ditelusuri kembali ke tahun 2003, namun tidak menimbulkan ancaman sampai refactoring dilakukan pada tahun 2012. Pada tahun 2017, kesalahan yang sama dilakukan saat mengimplementasikan dukungan RSA-PSS. Untuk melakukan serangan, pembuatan kunci tertentu yang intensif sumber daya tidak diperlukan untuk mendapatkan data yang diperlukan, karena overflow terjadi pada tahap sebelum memeriksa kebenaran tanda tangan digital. Bagian data yang melampaui batas ditulis ke area memori yang berisi penunjuk ke fungsi, yang menyederhanakan pembuatan eksploitasi yang berfungsi.

Kerentanan ini ditemukan oleh para peneliti dari Google Project Zero saat bereksperimen dengan metode pengujian fuzzing baru dan merupakan demonstrasi yang baik tentang bagaimana kerentanan sepele dapat tidak terdeteksi untuk waktu yang lama dalam proyek terkenal yang telah diuji secara luas:

  • Kode NSS dikelola oleh tim keamanan berpengalaman menggunakan teknik pengujian dan analisis kesalahan yang canggih. Ada beberapa program yang memberikan imbalan signifikan dalam mengidentifikasi kerentanan di NSS.
  • NSS adalah salah satu proyek pertama yang bergabung dengan inisiatif oss-fuzz Google dan juga diuji dalam sistem pengujian fuzz berbasis libFuzzer milik Mozilla.
  • Kode perpustakaan telah diperiksa berkali-kali di berbagai penganalisis statis, termasuk dipantau oleh layanan Coverity sejak tahun 2008.
  • Hingga tahun 2015, NSS digunakan di Google Chrome dan diverifikasi secara independen oleh tim Google secara independen dari Mozilla (sejak tahun 2015, Chrome beralih ke BoringSSL, tetapi dukungan untuk port berbasis NSS tetap ada).

Masalah utama yang menyebabkan masalah tidak terdeteksi untuk waktu yang lama:

  • Pustaka modular NSS dan pengujian fuzzing dilakukan tidak secara keseluruhan, tetapi pada tingkat komponen individual. Misalnya, kode untuk mendekode DER dan memproses sertifikat diperiksa secara terpisah - selama fuzzing, sertifikat dapat diperoleh yang akan mengarah pada manifestasi kerentanan yang dimaksud, tetapi pemeriksaannya tidak mencapai kode verifikasi dan masalahnya tidak mengungkapkan dirinya sendiri.
  • Selama pengujian fuzzing, batasan ketat ditetapkan pada ukuran keluaran (10000 byte) tanpa adanya batasan serupa di NSS (banyak struktur dalam mode normal dapat berukuran lebih dari 10000 byte, sehingga diperlukan lebih banyak data masukan untuk mengidentifikasi masalah) . Untuk verifikasi penuh, batasnya seharusnya 224-1 byte (16 MB), yang sesuai dengan ukuran sertifikat maksimum yang diperbolehkan di TLS.
  • Kesalahpahaman tentang cakupan kode pengujian fuzz. Kode yang rentan telah diuji secara aktif, tetapi menggunakan fuzzer yang tidak dapat menghasilkan data masukan yang diperlukan. Misalnya, fuzzer tls_server_target menggunakan serangkaian sertifikat siap pakai yang telah ditentukan sebelumnya, yang membatasi pemeriksaan kode verifikasi sertifikat hanya pada pesan TLS dan perubahan status protokol.

Sumber: opennet.ru

Tambah komentar