החדשות על זיהוי פגיעות קריטית (כבר רשום תחת CVE-2021-43527) en מערך הספריות ההצפנה NSS (שירותי אבטחת רשת) מ-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, בין היתר.
יחד עם זאת, הפגיעות לא מופיעה בפיירפוקס, Thunderbird ובדפדפן Tor, המשתמשות בספריית 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 ובדיקות ה-Fzzing לא בוצעו בשלמותן, אלא ברמת הרכיב הפרטני.
- לדוגמה, הקוד לפענוח DER ועיבוד תעודות אומת בנפרד; במהלך הטירוף, בהחלט ניתן היה לקבל אישור המוביל לביטוי הפגיעות הנדונה, אך האימות שלה לא הגיע לקוד האימות והבעיה לא נחשפה.
- במהלך בדיקות ה-Fzzing, נקבעו מגבלות קפדניות על גודל הפלט (10,000 בתים) בהיעדר מגבלות כאלה ב-NSS (מבנים רבים במצב רגיל יכולים להיות גדולים מ-10,000 בתים, לכן, כדי לזהות בעיות, נדרשים יותר נתוני קלט ). לאימות מלאה, המגבלה הייתה צריכה להיות 2 24 -1 בתים (16 מגה-בייט), התואמת לגודל המרבי של אישור המותר ב-TLS.
- תפיסה מוטעית לגבי כיסוי קוד על ידי טשטוש בדיקות. הקוד הפגיע נבדק באופן פעיל, אך באמצעות fuzers, אשר לא הצליחו ליצור את נתוני הקלט הנדרשים. לדוגמה, fuzzer tls_server_target השתמש בקבוצה מוגדרת מראש של אישורים מחוץ לקופסה, שהגבילו את האימות של קוד אימות האישור להודעות TLS ושינויי מצב פרוטוקול בלבד.
לבסוף, ראוי להזכיר כי הבעיה עם שם הקוד BigSig תוקנה ב-NSS 3.73 ו-NSS ESR 3.68.1 והעדכונים של הפתרון בצורת חבילה כבר שוחררו בהפצות השונות: Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD וכו'.
אם אתה רוצה לדעת יותר על זה, אתה יכול להתייעץ הקישור הבא.