Một lỗ hổng nghiêm trọng (CVE-2021-43527) đã được xác định trong bộ thư viện mật mã NSS (Dịch vụ bảo mật mạng) do Mozilla phát triển. Lỗ hổng này có thể dẫn đến việc thực thi mã kẻ tấn công khi xử lý chữ ký số DSA hoặc RSA-PSS được chỉ định bằng cách sử dụng Phương pháp mã hóa DER (Quy tắc mã hóa phân biệt). Sự cố có tên mã BigSig được giải quyết trong NSS 3.73 và NSS ESR 3.68.1. Các bản cập nhật gói trong các bản phân phối có sẵn cho Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Chưa có bản cập nhật nào cho Fedora.
Sự cố xảy ra trong các ứng dụng sử dụng NSS để xử lý chữ ký số CMS, S/MIME, PKCS #7 và PKCS #12 hoặc khi xác minh chứng chỉ trong quá trình triển khai TLS, X.509, OCSP và CRL. Lỗ hổng này có thể xuất hiện trong nhiều ứng dụng máy khách và máy chủ khác nhau hỗ trợ TLS, DTLS và S/MIME, ứng dụng email và trình xem PDF sử dụng lệnh gọi NSS CERT_VerifyCertificate() để xác minh chữ ký số.
LibreOffice, Evolution và Evince được đề cập như những ví dụ về các ứng dụng dễ bị tấn công. Có khả năng, sự cố này cũng có thể ảnh hưởng đến các dự án như Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certification System, mod_nss cho máy chủ Apache http, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Tuy nhiên, lỗ hổng này không xuất hiện trong Firefox, Thunderbird và Tor Browser, vốn sử dụng thư viện mozilla::pkix riêng biệt, cũng có trong NSS, để xác minh. Các trình duyệt dựa trên Chrome (trừ khi chúng được xây dựng riêng với NSS), sử dụng NSS cho đến năm 2015 nhưng sau đó chuyển sang BoringSSL, cũng không bị ảnh hưởng bởi sự cố.
Lỗ hổng này xảy ra do lỗi trong mã xác minh chứng chỉ trong hàm vfy_CreateContext từ tệp secvfy.c. Lỗi xảy ra cả khi máy khách đọc chứng chỉ từ máy chủ và khi máy chủ xử lý chứng chỉ máy khách. Khi xác minh chữ ký số được mã hóa DER, NSS giải mã chữ ký thành bộ đệm có kích thước cố định và chuyển bộ đệm đến mô-đun PKCS #11. Trong quá trình xử lý tiếp theo, kích thước được kiểm tra không chính xác đối với chữ ký DSA và RSA-PSS, dẫn đến tràn bộ đệm được phân bổ cho cấu trúc VFYContextStr nếu kích thước của chữ ký số vượt quá 16384 bit (2048 byte được phân bổ cho bộ đệm, nhưng không kiểm tra xem chữ ký có thể lớn hơn không) ).
Mã chứa lỗ hổng có thể được truy nguyên từ năm 2003, nhưng nó không gây ra mối đe dọa nào cho đến khi quá trình tái cấu trúc được thực hiện vào năm 2012. Năm 2017, sai lầm tương tự cũng xảy ra khi triển khai hỗ trợ RSA-PSS. Để thực hiện một cuộc tấn công, không cần phải tạo một số khóa nhất định để có được dữ liệu cần thiết vì tình trạng tràn xảy ra ở giai đoạn trước khi kiểm tra tính chính xác của chữ ký số. Phần dữ liệu vượt ra ngoài ranh giới được ghi vào vùng bộ nhớ chứa các con trỏ tới các hàm, giúp đơn giản hóa việc tạo các hoạt động khai thác.
Lỗ hổng này được các nhà nghiên cứu từ Google Project Zero phát hiện khi đang thử nghiệm các phương pháp thử nghiệm làm mờ mới và là một minh chứng rõ ràng về việc các lỗ hổng tầm thường có thể không bị phát hiện trong một thời gian dài trong một dự án nổi tiếng được thử nghiệm rộng rãi:
- Mã NSS được duy trì bởi một nhóm bảo mật giàu kinh nghiệm bằng cách sử dụng các kỹ thuật phân tích lỗi và kiểm tra hiện đại. Có một số chương trình trả thưởng đáng kể cho việc xác định các lỗ hổng trong NSS.
- NSS là một trong những dự án đầu tiên tham gia sáng kiến oss-fuzz của Google và cũng đã được thử nghiệm trong hệ thống thử nghiệm fuzz dựa trên libFuzzer của Mozilla.
- Mã thư viện đã được kiểm tra nhiều lần trong nhiều máy phân tích tĩnh khác nhau, bao gồm cả việc được dịch vụ Coverity giám sát từ năm 2008.
- Cho đến năm 2015, NSS đã được sử dụng trong Google Chrome và được nhóm Google xác minh độc lập với Mozilla (từ năm 2015, Chrome đã chuyển sang BoringSSL, nhưng vẫn hỗ trợ cổng dựa trên NSS).
Các vấn đề chính do đó vấn đề vẫn không được phát hiện trong một thời gian dài:
- Thư viện mô-đun NSS và thử nghiệm làm mờ không được thực hiện một cách tổng thể mà ở cấp độ các thành phần riêng lẻ. Ví dụ: mã để giải mã DER và chứng chỉ xử lý đã được kiểm tra riêng - trong quá trình làm mờ, một chứng chỉ có thể đã nhận được dẫn đến biểu hiện của lỗ hổng được đề cập, nhưng việc kiểm tra của nó không đạt được mã xác minh và sự cố không xảy ra. bộc lộ chính nó.
- Trong quá trình thử nghiệm làm mờ, các hạn chế nghiêm ngặt đã được đặt đối với kích thước đầu ra (10000 byte) trong trường hợp không có các hạn chế tương tự trong NSS (nhiều cấu trúc ở chế độ bình thường có thể có kích thước hơn 10000 byte, do đó cần nhiều dữ liệu đầu vào hơn để xác định vấn đề) . Để xác minh đầy đủ, giới hạn phải là 224-1 byte (16 MB), tương ứng với kích thước chứng chỉ tối đa được phép trong TLS.
- Quan niệm sai lầm về phạm vi bảo hiểm mã kiểm tra fuzz. Mã dễ bị tấn công đã được tích cực thử nghiệm nhưng sử dụng bộ làm mờ nên không thể tạo ra dữ liệu đầu vào cần thiết. Ví dụ: fuzzer tls_server_target đã sử dụng một bộ chứng chỉ được tạo sẵn được xác định trước, giới hạn việc kiểm tra mã xác minh chứng chỉ chỉ ở các thông báo TLS và các thay đổi trạng thái giao thức.
Nguồn: opennet.ru