פגיעות של ביצוע קוד ב-Mozilla NSS בעת עיבוד אישורים

זוהתה פגיעות קריטית (CVE-2021-43527) ב-NSS (שירותי אבטחת רשת) של ספריות קריפטוגרפיות שפותחו על ידי Mozilla, שיכולה להוביל לביצוע קוד תוקף בעת עיבוד חתימות דיגיטליות DSA או RSA-PSS שצוינו באמצעות שיטת קידוד DER (חוקי קידוד מובחנים). הבעיה, בשם הקוד BigSig, נפתרה ב-NSS 3.73 ו-NSS ESR 3.68.1. עדכוני חבילות בהפצות זמינים עבור Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. אין עדכונים זמינים עבור פדורה עדיין.

הבעיה מתרחשת ביישומים המשתמשים ב-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, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss עבור שרת Apache http, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. עם זאת, הפגיעות אינה מופיעה ב-Firefox, Thunderbird ו- Tor Browser, המשתמשים בספריית mozilla::pkix נפרדת, הכלולה גם היא ב-NSS, לצורך אימות. דפדפנים מבוססי כרום (אלא אם כן הם בנויים ספציפית עם 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 מתוחזק על ידי צוות אבטחה מנוסה תוך שימוש בטכניקות מתקדמות של בדיקות וניתוח שגיאות. קיימות מספר תוכניות לתגמול משמעותי עבור זיהוי נקודות תורפה ב-NSS.
• NSS היה אחד הפרויקטים הראשונים שהצטרפו ליוזמת oss-fuzz של גוגל וגם נבדק במערכת בדיקות fuzz המבוססת על libFuzzer של מוזילה.
• קוד הספרייה נבדק פעמים רבות במנתחים סטטיים שונים, כולל מעקב על ידי שירות Coverity מאז 2008.
• עד 2015, נעשה שימוש ב-NSS ב-Google Chrome והוא אומת באופן עצמאי על ידי צוות גוגל ללא תלות במוזילה (מאז 2015, Chrome עבר ל-BoringSSL, אך נותרה תמיכה ביציאה מבוססת NSS).

הבעיות העיקריות שבגללן הבעיה לא זוהתה במשך זמן רב:

• הספרייה המודולרית של NSS ובדיקות ה-Fzzing בוצעו לא כמכלול, אלא ברמה של רכיבים בודדים. למשל, הקוד לפיענוח DER ועיבוד תעודות נבדק בנפרד - במהלך ה-fuzzing ניתן היה לקבל תעודה שתוביל לביטוי של הפגיעות המדוברת, אך בדיקתו לא הגיעה לקוד האימות והבעיה לא הגיעה. לחשוף את עצמו.
• במהלך בדיקות מטושטשות, הוגדרו הגבלות קפדניות על גודל הפלט (10000 בתים) בהיעדר הגבלות דומות ב-NSS (מבנים רבים במצב רגיל יכולים להיות בגודל של יותר מ-10000 בתים, ולכן נדרשו יותר נתוני קלט כדי לזהות בעיות) . לאימות מלאה, המגבלה הייתה צריכה להיות 224-1 בתים (16 מגה-בייט), התואמת את גודל האישור המרבי המותר ב-TLS.
• תפיסה מוטעית לגבי כיסוי קוד בדיקות מטושטש. הקוד הפגיע נבדק באופן פעיל, אך באמצעות fuzzers שלא הצליחו לייצר את נתוני הקלט הדרושים. לדוגמה, fuzzer tls_server_target השתמש בקבוצה מוגדרת מראש של אישורים מוכנים, שהגבילו את בדיקת קוד אימות האישור להודעות TLS ושינויי מצב פרוטוקול בלבד.

מקור: OpenNet.ru