פגיעות חדשה התגלתה ב- Systemd

נמצאה פגיעות ב- systemd שתוארה כבר ב- (CVE-2019-6454), מה מאפשר לגרום לתהליך אתחול הבקרה (PID1) לחסום בעת שליחת הודעה בעלת מבנה מיוחד למשתמש שאינו מורשה באמצעות ה- D-Bus.

ل מפתחי Red Hat גם אינם שוללים את האפשרות להשתמש בפגיעות כדי לארגן ביצוע קוד עם הרשאות שורש., אך האפשרות הסופית להתקפה כזו טרם נקבעה.

אודות systemd

למי שלא מכיר את Systemd אני יכול להגיד לך את זה זוהי מערכת אתחול לינוקס ומנהל שירות הכוללת תכונות כגון הפעלה של דמון לפי דרישה, תחזוקה אוטומטית ונקודות הרכבה, תמיכה בתמונת מצב ומעקב אחר תהליכים באמצעות קבוצות בקרה של לינוקס.

SystemD מספק שד רישום וכלים וכלי עזר אחרים שיעזרו במשימות ניהול מערכת נפוצות. Lennart Poettering ו- Kay Sievers כתבו את SystemD, בהשראת MacOS launchd ו- Upstart, במטרה ליצור מערכת מודרנית ודינמית.

בפרט, systemd מספק יכולות מקבילות אגרסיביות ולוגיקה של בקרת שירות מבוססת תלות, מה שמאפשר לשירותים להתחיל במקביל ולהוביל לזמני הפעלה מהירים יותר. שני היבטים אלה היו קיימים ב- Upstart, אך שופרו על ידי systemd.

Systemd היא מערכת האתחול המוגדרת כברירת מחדל להפצות לינוקס עיקריות, אך הוא תואם לאחור לתסריטי ההפעלה של SysV.

SysVinit היא מערכת אתחול המקדימה את המערכת ומשתמשת בגישה פשוטה להפעלת השירות. Systemd לא רק מנהלת אתחול המערכת, אלא גם מספקת חלופות לכלי עזר ידועים אחרים כגון cron ו- syslog.

אודות הפגיעות החדשה של המערכת

על ידי מניפולציה על גודל ההודעה שנשלחה באמצעות D-Bus, תוקף יכול להעביר את המצביע מעבר לגבולות הזיכרון שהוקצו למחסנית, עוקף את ההגנה על "stack stack-page", המבוסס על החלפת דף זיכרון בקצה המכנה חריג (תקלה בעמוד).

ההתקפה המוצלחת מודגמת באובונטו 18.10 עם systemd 239 וב- CentOS 7.6 עם systemd 219.

כדרך לעקיפת הבעיה, ניתן להשתמש בקומפילציה ב- GCC עם האפשרות "-fstack-clash-protection", המשמשת כברירת מחדל בפדורה 28 ו -29.

יש לציין כי בשנת 2014 מחבר ספריית המערכת MUSL ציין בין הבעיות האדריכליות העיקריות שהייתה למטפל PID1 באינפלציה מוגזמת והטיל ספק בהיתכנות הטמעת ממשק API לבקר PID1 ברמת קישור לאוטובוס, מכיוון שהוא מהווה וקטור רציני עבור תוקף ויכול להשפיע לרעה על מהימנות המערכת כולה

לדברי חוקר אבטחה ש גילה פגיעות, שינוי מצביע מחסנית אפשרי רק עבור דפי זיכרון שאינם בשימוש (לא מוקצה), שאינו מאפשר לארגן ביצוע קוד בהקשר לתהליך PID1, אך מאפשר לתוקף ליזום את נעילת PID1 עם מעבר עוקב של ליבת לינוקס למצב "פאניקה" (במקרה של בקר PID כישלון אחד, המערכת כולה תלויה).

ב- systemd מותקן מטפל באותות שמנסה לתפוס את התקלות בתהליך PID1 (תקלה בפילוח) ומתחיל את מעטפת ההתאוששות.

אך מכיוון שבמהלך ההתקפה מתבצעת שיחה לדפי זיכרון שאינם משוכפלים (לא מוקצים), הגרעין אינו יכול להתקשר למטפל האותות הזה ופשוט מסיים את התהליך עם PID 1, מה שבתורו אי אפשר להמשיך לעבוד ולהיכנס את המצב "בהלה", ולכן נדרש הפעלה מחדש של המערכת.

יש כבר פיתרון לבעיה

כמו כל בעיית אבטחה שכבר תוארה ודיווחה, לא ניתן לבצע את פרסומה עד לפתרון הבעיה עדכוני תיקון פגיעות עבור SUSE / openSUSE, Fedora כבר שוחררו, גם עבור אובונטו ובחלקם עבור דביאן (מתיחת דביאן בלבד).
למרות שהבעיה נותרה ללא תיקון ב- RHEL.