הרגשה מוגנת/ספקטר

Surma

סקירה

ב-3 בינואר, Project Zero חשפה נקודות חולשה במעבדים מודרניים, שניתן להשתמש בהן כדי לקרוא זיכרון שרירותי (במקרה הגרוע ביותר), כולל זיכרון שלא שייך לתהליך הזה. נקודות החולשה האלה קיבלו את השמות Spectre ו-Meltdown. מה Chrome עושה כדי לשמור על אבטחת האינטרנט, ומה צריכים מפתחי האינטרנט לעשות בשביל האתרים שלהם?

אמ;לק

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

אם אתם מפתחי אתרים, צוות Chrome ממליץ לכם:

• אם אפשר, כדאי למנוע מקובצי cookie להיכנס לזיכרון של תהליך כלי הרינדור על ידי שימוש במאפיינים של קובצי ה-cookie SameSite ו-HTTPOnly, ולהימנע מקריאה של קובצי Cookie מ-document.cookie.
• כדי להפיק את המירב מחסימת קריאה ממקורות שונים אצל משתמשים שהפעילו את התכונה 'בידוד של אתר', צריך לוודא שסוגי ה-MIME נכונים ולציין כותרת X-Content-Type-Options: nosniff לכל כתובת URL עם תוכן רגיש או ספציפי למשתמש.
• מפעילים את Site Isolation ומדווחים לצוות Chrome אם הוא גורם לבעיות באתר.

אם רוצים לדעת למה השלבים האלה עוזרים, המשיכו לקרוא.

הסיכון

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

גם Meltdown וגם Spectre עשויים לאפשר לתהליך לקרוא זיכרון שהוא לא אמור לקרוא. לפעמים, מספר מסמכים מאתרים שונים יכולים בסופו של דבר לשתף תהליך ב-Chrome. מצב כזה יכול לקרות כשאחד מהם פותח את הקובץ השני באמצעות window.open, או <a href="..." target="_blank"> או iframes. אם אתר מכיל נתונים ספציפיים למשתמש, יש סיכוי שאתר אחר יוכל להשתמש בנקודות החולשה החדשות האלה כדי לקרוא את נתוני המשתמש.

מיטיגציות

יש מאמצים רבים שצוות המהנדסים של Chrome ו-V8 מבצע כדי לצמצם את האיום הזה.

בידוד של אתר

אפשר לצמצם משמעותית את ההשפעה של ניצול מוצלח של Spectre אם מונעים ממידע אישי רגיש לשתף תהליך עם קוד שנשלט על ידי תוקף. צוות Chrome עובד על תכונה שנקראת "Site Isolation":

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

התכונה 'בידוד של אתרים' עדיין לא הופעלה כברירת מחדל כי יש כמה בעיות ידועות, וצוות Chrome מעוניין לבצע כמה שיותר בדיקות שטח. אם אתם מפתחי אתרים, כדאי להפעיל את התכונה 'בידוד של אתר' ולבדוק אם האתר פועל כמו שצריך. כדי להביע הסכמה, צריך להפעיל את chrome://flags#enable-site-per-process. אם נתקלתם באתר שלא פועל, תוכלו לדווח לנו על באג ולציין שהפעלתם את התכונה 'בידוד של אתר'.

חסימת מסמכים בין אתרים

הערה: אחרי פרסום המסמך, שינינו את השם של חסימת המסמכים באתרים שונים לחסימת קריאה בין מקורות. שני המונחים האלה מתייחסים לאותו עיקרון.

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

אתרים יכולים לבקש שני סוגי נתונים משרת: 'מסמכים' ו'משאבים'. כאן, מסמכים הם HTML, XML, JSON וקובצי טקסט. אתר יכול לקבל מסמכים מהדומיין שלו או מדומיינים אחרים עם כותרות CORS מאפשרות. משאבים כוללים דברים כמו תמונות, JavaScript, CSS וגופנים. אפשר לכלול משאבים מכל אתר.

מדיניות חסימת המסמכים באתרים שונים מונעת מתהליך לקבל "מסמכים" ממקורות אחרים אם:

1. הם בעלי סוג HTML, XML, JSON או טקסט/MIME פשוט, וגם
2. יש להם כותרת תגובה X-Content-Type-Options: nosniff של HTTP, או ניתוח תוכן מהיר ("sniffing") שמאשר שהסוג נכון
3. CORS לא מאפשר באופן מפורש גישה למסמך

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

לדוגמה: נניח שתוקף יוצר תג <img> שכולל קובץ JSON עם מידע אישי רגיש, כמו <img src="https://yourbank.com/balance.json">. בלי 'בידוד של אתר', התוכן של קובץ ה-JSON יגיע לזיכרון של תהליך הרינדור, ואז כלי הרינדור יזהה שפורמט התמונה לא תקין והוא לא יעבד תמונה. עם זאת, ב'ספקטר' יש עכשיו דרך לקרוא באופן פוטנציאלי את מקטע הזיכרון הזה. חסימת מסמכים בין אתרים תמנע מהתוכן של הקובץ הזה להיכנס לזיכרון של התהליך שבו פועל כלי הרינדור, כי סוג ה-MIME חסום על ידי חסימת מסמכים בין אתרים.

לפי מדדי משתמשים, יש הרבה קובצי JavaScript ו-CSS שמגיעים עם סוגי MIME של text/html או text/plain. כדי למנוע חסימה של משאבים שסומנו בטעות כמסמכים, Chrome מנסה לסרוק את התגובה כדי לוודא שסוג ה-MIME נכון. הסינון הזה שגוי, לכן אם אתם בטוחים שהגדרתם את כותרות Content-Type הנכונות באתר שלכם, צוות Chrome ממליץ להוסיף את הכותרת X-Content-Type-Options: nosniff לכל התשובות.

אם אתם רוצים לנסות לחסום מסמכים באתרים שונים, מביעים הסכמה לשימוש ב'בידוד של אתר' כמו שמתואר למעלה.

SameSite קובצי cookie

נחזור לדוגמה שלמעלה: <img src="https://yourbank.com/balance.json">. הפעולה הזו פועלת רק אם באתר yourbank.com מאוחסן קובץ Cookie שמתחבר למשתמש באופן אוטומטי. קובצי Cookie בדרך כלל נשלחים לכל הבקשות לאתר שמגדיר את קובץ ה-Cookie, גם אם הבקשה נשלחת על ידי צד שלישי באמצעות תג <img>. קובצי cookie מסוג SameSite הם מאפיין חדש שמציין שצריך לצרף קובץ cookie רק לבקשה שמגיעה מאותו אתר, ולכן השם הזה. לצערנו, בזמן הכתיבה אפשר להשתמש במאפיין הזה רק ב-Chrome וב-Firefox 58 ואילך.

HTTPOnly וגם document.cookie

אם קובצי ה-cookie של האתר שלכם משמשים רק בצד השרת ולא ב-JavaScript של הלקוח, יש דרכים למנוע את הכניסה של נתוני קובץ ה-cookie לתהליך הרינדור. אפשר להגדיר את מאפיין קובץ ה-cookie HTTPOnly, שמונע במפורש גישה לקובץ ה-cookie דרך סקריפט בצד הלקוח בדפדפנים נתמכים, כמו Chrome. אם אי אפשר להגדיר את HTTPOnly, אפשר להגביל את החשיפה של טעינת נתונים של קובצי cookie לתהליך העיבוד על ידי קריאה של הנתונים document.cookie אלא אם זה הכרחי.

פתיחת קישורים חיצוניים באמצעות rel="noopener"

כשמקשרים לדף אחר באמצעות target="_blank", לדף הפתוח יש גישה לאובייקט window, הוא יכול לנווט את הדף לכתובת URL אחרת ובלי 'בידוד של אתר' יהיה באותו תהליך כמו הדף שלכם. כדי להגן טוב יותר על הדף, קישורים לדפים חיצוניים שנפתחים בחלון חדש צריכים תמיד לציין rel="noopener".

טיימרים ברזולוציה גבוהה

כדי לנצל את Meltdown או Spectre, תוקף צריך למדוד כמה זמן לוקח לקרוא ערך מסוים מהזיכרון. כדי לעשות זאת, צריך טיימר אמין ומדויק.

אחד ממשקי ה-API שפלטפורמת האינטרנט מציעה הוא performance.now(), והוא מדויק ל-5 מיקרו-שניות. כדי לצמצם את הסיכון, כל הדפדפנים המובילים הסירו את הרזולוציה של performance.now() כדי שיהיה קשה יותר לבצע את ההתקפות.

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

V8

כדי לנצל את ספקטר, צריך ליצור רצף ספציפי של הוראות לגבי המעבד (CPU). צוות V8 הטמיע מיטיגציות עם הוכחות ידועות להתקפות, ועובד על שינויים ב-TurboFan, המהדר (compiler) לביצוע אופטימיזציה, שבזכותו הקוד שנוצר יהיה בטוח גם כשההתקפות האלה מופעלות. עם זאת, שינויים כאלה של יצירת הקוד עלולים לגרור פגיעה בביצועים.

שמירה על הבטיחות באינטרנט

יש הרבה חוסר ודאות לגבי התגליות של 'ספקטר' ו-Meltdown וההשלכות שלהן. אני מקווה שהמאמר הזה נועד להבהיר מה עושים צוותי Chrome ו-V8 כדי לשמור על הבטיחות של פלטפורמת האינטרנט, ואיך מפתחי אתרים יכולים לעזור באמצעות תכונות האבטחה הקיימות. אם יש לכם שאלות, תוכלו לפנות אליי ב-Twitter.