פרק 5: מאת עדה במאונטיין ויו, קליפורניה (אוגוסט 2019)
הפרקים הקודמים
Chrome מפוצל לתהליכים. חלק מהם נמצאים בארגז חול (sandbox), ולכן הם מצמצמים את הגישה למערכת ולחשבונות של משתמשים. בתהליך בארגז חול, באגים שמאפשרים הרצה של קוד זדוני הם הרבה פחות חמורים.
בתהליך הדפדפן אין Sandbox, ולכן באג עלול לתת לקוד הזדוני גישה מלאה לכל המכשיר. מה עליכם לעשות אחרת? ומה המצב בתהליכים אחרים?
בכל הקוד יש באגים. בתהליך הדפדפן, הבאגים האלה מאפשרים לקוד זדוני להתקין תוכנה, לגנוב נתונים של משתמשים, לשנות את הגדרות המחשב, לגשת לתוכן של כל הכרטיסיות בדפדפן, לנתוני ההתחברות וכו'.
בתהליכים אחרים, הגישה למערכות ההפעלה מוגבלת באמצעות הגבלות ספציפיות לפלטפורמה. למידע נוסף, ניתן לעיין במדריך ההטמעה של Sandbox של Chrome.
הקפידו להימנע מהשגיאות הנפוצות הבאות:
- אל תנתחו או תפרשו נתונים לא מהימנים באמצעות C++ בתהליך הדפדפן.
- אל תבטחו במקור שהמעבד טוען שהוא מייצג. אפשר להשתמש ב-RenderFrameHost של הדפדפן כדי לאתר את המקור הנוכחי באופן מאובטח.
במקום זאת, כדאי לפעול לפי השיטות המומלצות הבאות:
- אם הקוד מופיע בתהליך הדפדפן, הוא יכול להיות מאוד פרנואידי.
- אימות של כל כתובות ה-IPC בתהליכים אחרים. נניח שכל התהליכים האחרים כבר נמצאים בסיכון ונמצאים בסיכון כדי להטעות אתכם.
- מבצעים את העיבוד באמצעות תהליך של רינדור או כלי עזר או בתהליך אחר בארגז חול. מומלץ להשתמש גם בשפה בטוחה לזיכרון, כמו JavaScript (פתרון של יותר מ-50% באגים באבטחה).
במשך שנים, הפעלנו סטאקים של רשתות (למשל HTTP, DNS, QUIC) בתהליך הדפדפן, והדבר הוביל לכמה נקודות חולשה קריטיות. בפלטפורמות מסוימות יש עכשיו תהליך משלה, שכולל גם ארגז חול.
מקורות נוספים
- כלל שניים של Chromium: לא יותר משני נתונים לא בטוחים, קוד לא בטוח ותהליך לא בטוח.
- אימות של נתוני IPC: מדריך שמסביר איך לוודא שה-IPC מתהליך הרינדור לא מלא ב-Fib ובמצג שווא.