ข่าวเกี่ยวกับ การระบุจุดอ่อนที่สำคัญ (อยู่ในรายการแล้วภายใต้ CVE-2021-43527) en ชุดของห้องสมุดเข้ารหัส เอ็นเอส (บริการรักษาความปลอดภัยเครือข่าย) จาก Mozilla ที่อาจนำไปสู่การเรียกใช้โค้ดที่เป็นอันตราย เมื่อประมวลผลลายเซ็นดิจิทัล DSA หรือ RSA-PSS ที่ระบุโดยใช้ DER (กฎการเข้ารหัสที่โดดเด่น)
ปัญหา ปรากฏในแอปพลิเคชันที่ใช้ NSS เพื่อจัดการลายเซ็นดิจิทัล CMS, S / MIME, PKCS # 7 และ PKCS # 12, หรือเมื่อตรวจสอบใบรับรองในการปรับใช้ TLS, X.509, OCSP และ CRL ช่องโหว่อาจเกิดขึ้นในไคลเอนต์และแอปพลิเคชันเซิร์ฟเวอร์ต่างๆ ที่รองรับ TLS, DTLS และ S / MIME ไคลเอนต์อีเมล และโปรแกรมดู PDF ที่ใช้การเรียก NSS CERT_VerifyCertificate () เพื่อยืนยันลายเซ็นดิจิทัล
LibreOffice, Evolution และ Evince ถูกกล่าวถึงเป็นตัวอย่างของแอปพลิเคชันที่มีช่องโหว่. ปัญหาอาจส่งผลต่อโครงการต่างๆ เช่น Pidgin, Apache OpenOffice, Suricata, Curl และอื่นๆ
ในเวลาเดียวกัน ช่องโหว่ไม่ปรากฏใน Firefox, Thunderbird และ Tor Browserซึ่งใช้ mozilla :: pkix library แยกต่างหากสำหรับการตรวจสอบ ซึ่งเป็นส่วนหนึ่งของ NSS ด้วย ดิ เบราว์เซอร์ที่ใช้ Chrome (เว้นแต่จะคอมไพล์ด้วย NSS โดยเฉพาะ) ซึ่งใช้ NSS จนถึงปี 2015 แต่แล้วส่งต่อไปยัง BoringSSL พวกเขาไม่ได้รับผลกระทบจากปัญหา
ช่องโหว่นี้เกิดจากจุดบกพร่องในรหัสยืนยันใบรับรองใน vfy_CreateContext ฟังก์ชันของไฟล์ secvfy.c ข้อผิดพลาดปรากฏขึ้นทั้งเมื่อไคลเอ็นต์อ่านใบรับรองจากเซิร์ฟเวอร์ เช่นเดียวกับเมื่อเซิร์ฟเวอร์ประมวลผลใบรับรองของไคลเอ็นต์
เมื่อตรวจสอบลายเซ็นดิจิทัลที่เข้ารหัส DER แล้ว NSS จะถอดรหัสลายเซ็นลงในบัฟเฟอร์ขนาดคงที่และส่งผ่านบัฟเฟอร์นี้ไปยังโมดูล PKCS # 11 ระหว่างการประมวลผลภายหลังสำหรับลายเซ็น DSA และ RSA-PSS ขนาดจะถูกตรวจสอบอย่างไม่ถูกต้อง ส่งผลให้ ซึ่งนำไปสู่การล้นของบัฟเฟอร์ที่จัดสรรสำหรับโครงสร้าง VFYContextStr หากขนาดของลายเซ็นดิจิทัลเกิน 16384 บิต (จัดสรร 2048 ไบต์สำหรับบัฟเฟอร์ แต่ไม่มีการตรวจสอบว่าลายเซ็นสามารถมีขนาดใหญ่ขึ้นได้)
รหัสที่มีช่องโหว่นี้มีอายุย้อนไปถึงปี 2003แต่ก็ไม่ใช่ภัยคุกคามจนกว่าจะมีการจัดโครงสร้างใหม่ในปี 2012 ในปี 2017 เกิดข้อผิดพลาดเดียวกันเมื่อใช้งานการรองรับ RSA-PSS ในการดำเนินการโจมตี ไม่จำเป็นต้องสร้างคีย์บางคีย์ที่ใช้ทรัพยากรมากเพื่อให้ได้ข้อมูลที่จำเป็น เนื่องจากการโอเวอร์โฟลว์เกิดขึ้นในขั้นตอนก่อนการตรวจสอบความถูกต้องของลายเซ็นดิจิทัล ส่วนนอกขอบเขตของข้อมูลจะถูกเขียนลงในพื้นที่หน่วยความจำที่มีพอยน์เตอร์ของฟังก์ชัน ทำให้ง่ายต่อการสร้างช่องโหว่ในการทำงาน
ช่องโหว่ถูกระบุโดยนักวิจัย Google Project Zero ระหว่างการทดลองด้วยวิธีการทดสอบที่คลุมเครือแบบใหม่ และเป็นการสาธิตที่ดีว่าช่องโหว่เล็กๆ น้อยๆ นั้นสามารถตรวจไม่พบมาเป็นเวลานานได้อย่างไรในโปรเจ็กต์ที่เป็นที่รู้จักซึ่งได้รับการทดสอบอย่างดี
ส่วน ปัญหาหลักที่ปัญหาไม่ได้สังเกต เป็นเวลานาน:
- ไลบรารีไดรฟ์ NSS และการทดสอบการฟัซซิ่งไม่ได้ดำเนินการอย่างครบถ้วน แต่ในระดับส่วนประกอบแต่ละส่วน
- ตัวอย่างเช่น รหัสสำหรับถอดรหัส DER และใบรับรองกระบวนการได้รับการตรวจสอบแยกกัน ในระหว่างการฟัซซิ่ง ใบรับรองสามารถได้รับอย่างดี นำไปสู่การแสดงจุดอ่อนที่เป็นปัญหา แต่การตรวจสอบไม่ถึงรหัสยืนยันและปัญหาไม่เปิดเผย
- ในระหว่างการทดสอบ fuzzing ได้กำหนดขีดจำกัดที่เข้มงวดบนขนาดของเอาต์พุต (10,000 ไบต์) โดยไม่มีข้อจำกัดดังกล่าวใน NSS (โครงสร้างจำนวนมากในโหมดปกติอาจมีขนาดใหญ่กว่า 10,000 ไบต์ ดังนั้นเพื่อระบุปัญหา จึงจำเป็นต้องมีข้อมูลอินพุตเพิ่มเติม ). สำหรับการตรวจสอบแบบเต็ม ขีดจำกัดควรเป็น 2 24 -1 ไบต์ (16 MB) ซึ่งสอดคล้องกับขนาดสูงสุดของใบรับรองที่อนุญาตใน TLS
- ความเข้าใจผิดเกี่ยวกับการครอบคลุมโค้ดโดยการทดสอบที่คลุมเครือ รหัสที่มีช่องโหว่ได้รับการทดสอบอย่างแข็งขัน แต่ใช้ฟิวเซอร์ซึ่งไม่สามารถสร้างข้อมูลอินพุตที่ต้องการได้ ตัวอย่างเช่น fuzzer tls_server_target ใช้ชุดใบรับรองสำเร็จรูปที่กำหนดไว้ล่วงหน้า ซึ่งจำกัดการตรวจสอบรหัสการตรวจสอบใบรับรองไว้เฉพาะข้อความ TLS และการเปลี่ยนแปลงสถานะของโปรโตคอล
ในที่สุด เป็นมูลค่าการกล่าวขวัญว่าปัญหาชื่อรหัส BigSig ได้รับการแก้ไขแล้วใน NSS 3.73 และ NSS ESR 3.68.1 และการอัปเดตโซลูชันในรูปแบบแพ็คเกจได้รับการเผยแพร่แล้วในรุ่นต่างๆ ได้แก่ Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD เป็นต้น
หากต้องการทราบข้อมูลเพิ่มเติมสามารถปรึกษาได้ ลิงค์ต่อไปนี้