70% מבעיות האבטחה ב-Chromium נגרמות משגיאות זיכרון

מפתחי פרויקט Chromium מְנוּתָח 912 פגיעויות בסיכון גבוה וקריטיות שזוהו במהדורות יציבות של Chrome מאז 2015, והגיעו למסקנה ש-70% מהן נגרמו על ידי חוסר אבטחה בזיכרון (שגיאות בעת עבודה עם מצביעים בקוד C/C++). מחצית מהבעיות הללו (36.1%) נגרמות מגישה למאגר לאחר שחרור הזיכרון המשויך אליו (שימוש-אחרי-חופשי).

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

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

כדי לשפר עוד יותר את האבטחה של בסיס הקוד, הושק פרויקט למניעת הופעת שגיאות זיכרון בבסיס הקוד. ישנן שלוש גישות עיקריות: יצירת ספריות C++ עם פונקציות להפעלה בטוחה של הזיכרון והרחבת היקף אוסף האשפה, תוך שימוש במנגנוני הגנה על חומרה MTE (Memory Tagging Extension) ורכיבי כתיבה בשפות המבטיחות עבודה בטוחה עם זיכרון (Java, Kotlin, JavaScript, Rust, Swift).

צפוי שהעבודה תתמקד בשני תחומים:

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

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

מקור: OpenNet.ru