עדכון Chrome האחרון של גוגל יצא, והפעם החברה לא קמצן את דבריו על אחד משני תיקוני האבטחה שהוא כולל:
גוגל מודעת לכך שניצול עבור CVE-2023-3079 קיים בטבע.
אין מילים של שתי דרגות של הפרדה, כפי שראינו לעתים קרובות מגוגל בעבר, כדי לומר שהחברה "מודעת לדיווחים" על ניצול.
הפעם, זה "אנחנו מודעים לזה לגמרי בעצמנו", שמתורגם ביתר שאת ל"אנו יודעים שרוכלים מנצלים זאת לרעה בזמן שאנו מדברים", בהתחשב בכך שדוח הבאג הגיע ישירות מקבוצת המחקר האיומים של גוגל.
כרגיל, זה מרמז שגוגל חקרה התקפה פעילה (בין אם נגד גוגל עצמה, או נגד ארגון חיצוני כלשהו, אנחנו לא יודעים) שבה כרום נפגע על ידי חור אבטחה שלא היה ידוע קודם לכן.
הבאג מתואר בפשטות כך: סוג בלבול ב-V8. (מובן שגוגל לא אומרת יותר מזה בשלב זה.)
כפי שהסברנו בעבר, א בלבול מסוג באג קורה כאשר אתה מספק לתוכנית גוש של נתונים שהיא אמורה לנתח, לאמת, לעבד ולפעול על פיו בדרך אחת...
...אבל מאוחר יותר אתה מצליח להערים על התוכנית לפרש את הנתונים בצורה שונה, לא מורשית, לא מאומתת ועלולה להיות מסוכנת.
הסבירו סכנות בלבול סוג
תאר לעצמך שאתה כותב תוכנית ב-C. (לא משנה אם אתה יודע C או לא, אתה יכול פשוט לעקוב אחריו בכל מקרה).
ב-C, אתה בדרך כלל מצהיר על משתנים בנפרד, ובכך לא רק שומרת זיכרון במקום שבו ניתן לאחסן אותם, אלא גם מאותת לתוכנית כיצד אמורים להשתמש במשתנים האלה.
לדוגמה:
long long int JulianDayNumber; חתום char* CustomerName;
הצהרת המשתנה הראשונה שומרת 64 סיביות לאחסון ערך שלם ישן רגיל המייצג את מספר היום האסטרומונומי. (למקרה שאתה תוהה, אחר הצהריים זה JDN 23157 - הימים היוליאניים מתחילים בצהריים, לא בחצות, מכיוון שאסטרונומים עובדים לעתים קרובות בלילה, כאשר חצות היא אמצע יום העבודה שלהם.)
השני שומרת 64 סיביות לאחסון כתובת זיכרון שבה ניתן למצוא את מחרוזת הטקסט של שם הלקוח.
כפי שאתה יכול לדמיין, מוטב שלא לערבב בין שני הערכים הללו, מכיוון שמספר הגיוני, ובטוח, לשימוש כמספר יום, כגון 23157, יהיה כמעט בטוח לא בטוח לשימוש ככתובת זיכרון.
כפי שניתן לראות מ-dump זיכרון זה של תוכנית Windows פועלת, כתובת הזיכרון הנמוכה ביותר שהוקצתה לשימוש מתחילה ב- 0x00370000, שהוא 3,604,480 בעשרוניות, גדול בהרבה מכל מספר יום הגיוני.
כתובות הזיכרון בפועל בשימוש על ידי Windows משתנות באופן אקראי לאורך זמן, כדי להפוך את פריסת הזיכרון שלך לקשה יותר עבור נוכלים לנחש, כך שאם היית מריץ את אותה תוכנית, תקבל ערכים, אבל הם בכל זאת יהיו דומים:
וגם (למרות שזה מחוץ לתחתית התמונה למעלה) כתובות הזיכרון של קטע נתוני המשתמש בזמן ריצה כאשר תוכנית זו רצה מ 0x01130000 ל 0x01134FFF, המייצג את טווח התאריכים הלא סביר של 22 ביולי 44631 עד 16 באוגוסט 44687.
ואכן, אם תנסה לערבב את שני המשתנים האלה, המהדר צריך לנסות להזהיר אותך, למשל כך:
JulianDayNumber = CustomerName; CustomerName = JulianDayNumber; אזהרה: הקצאה הופכת מספר שלם מצביע ללא קאסט אזהרה: הקצאה הופכת מצביע ממספר שלם בלי קאסט
עכשיו, אם אי פעם תכנתת ב-C, תדע שלצורך הנוחות, אתה יכול להצהיר על משתנים עם מספר פרשנויות שונות באמצעות union מילת מפתח, כמו זו:
union { long long int JulianDayNumer; חתום char* CustomerName; } נתונים;
כעת אתה יכול להתייחס בדיוק לאותו משתנה בזיכרון בשתי דרכים שונות.
אם אתה כותב data.JulianDayNumber, אתה מפרש בצורה קסומה את הנתונים המאוחסנים כמספר שלם, אבל כותב data.CustomerName אומר למהדר שאתה מפנה לכתובת זיכרון, למרות שאתה ניגש לאותם נתונים מאוחסנים.
מה שאתה עושה, פחות או יותר, הוא להודות בפני המהדר שלפעמים אתה מתייחס לנתונים שיש לך כתאריך, ולפעמים כאל כתובת זיכרון, וזה אתה לוקח אחריות לזכור איזו פרשנות חלה באיזה רגע בקוד.
ייתכן שתחליט לקבל משתנה שני, המכונה a tag (בדרך כלל מספר שלם) כדי ללכת יחד עם שלך union כדי לעקוב אחר איזה סוג של נתונים אתה עובד עכשיו, למשל:
struct { int tag; union { long long int JulianDayNumer; חתום char* CustomerName; } נתונים; } ערך;
אולי תחליט מתי value.tag מוגדר 0, הנתונים עדיין לא אתחולו לשימוש, 1 אומר שאתה שומרת תאריך, 2 פירושו שזו כתובת זיכרון, וכל דבר אחר מציין שגיאה.
טוב, עדיף שלא תיתן לאף אחד אחר להתעסק עם זה value.tag הגדרה, או שהתוכנית שלך עלולה להתנהג בצורה לא נכונה באופן דרמטי.
דוגמה מדאיגה יותר עשויה להיות משהו כזה:
struct { int tag; // 1 = hash, 2 = function pointers union { unsigned Char hash[16]; // או לאחסן מבנה hash אקראי { void* openfunc; // או שני חללים מאומתים בקפידה* closefunc; // מצביעי קוד לביצוע מאוחר יותר } validate; } } ערך;
כעת, אנו מעמיסים יתר על המידה את אותו בלוק זיכרון, כך שלפעמים נוכל להשתמש בו כדי לאחסן גיבוב של 16 בתים, ולפעמים כדי לאחסן שני מצביעים של 8 בתים לפונקציות שהתוכנית שלנו תתקשר אליהן מאוחר יותר.
ברור מתי value.tag == 1, נשמח לאפשר לתוכנה שלנו לאחסן כל מחרוזת של 16 בתים בכלל בזיכרון שהוקצה לאיחוד, מכיוון ש-hashs הם פסאודורנדומליים, כך שכל אוסף של בתים סביר באותה מידה.
אבל כש value.tag == 2, הקוד שלנו צריך להיות זהיר במיוחד כדי לא לאפשר למשתמש לספק כתובות פונקציה לא מאומתות, לא מהימנות ולא ידועות לביצוע מאוחר יותר.
עכשיו תאר לעצמך שאתה יכול לשלוח ערך לקוד הזה בזמן שהתג היה מוגדר ל-1, כך שהוא לא נבדק ואושר...
...אבל מאוחר יותר, רגע לפני שהתוכנית באמת השתמשה בערך המאוחסן, הצלחת להערים על הקוד לשנות את התג ל-2.
לאחר מכן, הקוד יקבל את כתובות הפונקציה הלא מאומתות שלך כ"מוכרות וכבר מאומתות בטוחות" (למרות שהן לא היו), וישגר באמון את הפעלת התוכנית למיקום נוכל בזיכרון שבחרת מראש בעורמה.
וזה מה שקורה בבאג מסוג בלבול, אם כי באמצעות דוגמה מתוכננת ומפושטת,
זיכרון שיהיה בטוח לצרוך לו אם היה מטופל בדרך אחת נמסר בזדון לתוכנית לעיבוד בדרך חלופית, לא בטוחה.
מה לעשות?
ודא שיש לך את הגרסה העדכנית ביותר של Chrome או Chromium.
אתה רוצה כרום 114.0.5735.106 או מאוחר יותר ב-Mac ולינוקס, ו 114.0.5735.110 או מאוחר יותר ב-Windows.
Microsoft Edge, המבוססת על Chromium, מושפעת גם היא מהבאג הזה.
מיקרוסופט עשתה עד כה [2023-06-06T16:25:00Z] ציין כי
מיקרוסופט מודעת למעללים האחרונים הקיימים בטבע. אנו עובדים באופן פעיל על שחרור תיקון אבטחה.
Edge נמצא כעת בגרסה 114.0.1823.37, אז כל דבר ממוספר מאוחר יותר מזה צריך לכלול את תיקוני CVE-2023-3079 של מיקרוסופט.
כדי לבדוק את הגרסה שלך ולאלץ עדכון אם יש אחד שעדיין לא קיבלת:
- Google Chrome. תפריט שלוש נקודות (⋮) > עֶזרָה > על Chrome.
- מיקרוסופט אדג. הגדרות ועוד (...) > עזרה ומשוב > על Microsoft Edge.
בבקשה.
- הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
- PlatoAiStream. Web3 Data Intelligence. הידע מוגבר. גישה כאן.
- הטבעת העתיד עם אדריאן אשלי. גישה כאן.
- קנה ומכירה של מניות בחברות PRE-IPO עם PREIPO®. גישה כאן.
- מקור: https://nakedsecurity.sophos.com/2023/06/06/chrome-zero-day-this-exploit-is-in-the-wild-so-check-your-version-now/