TheMarker יוצא הבוקר עם הכותרת “כשל אבטחה חמור התגלה בלינוקס”. אני לא בטוח מה עומד להיות הקישור המדוייק, אבל יכול להיות שזה (אתר שנקרא nfc. אני לא יודע אם הוא או הטוש הזוהר הם המקור).
אני חושב שהכותרת של המאמר שעליו מתבססת הטענה הרבה הרבה הרבה יותר סבירה. היא אומרת “חולשה במנגנון המספרים האקראיים של לינוקס”. תיאור מדוייק ולא מתלהם של הבעיה.
הסבר:
אין דבר כזה “אלגוריתם לייצור מספרים אקראיים”. אלגוריתם, מעצם הגדרתו, הוא משהו דטרמיניסטי. אם הזנתם את אותם קלטים, בהגדרה תקבלו את אותם תוצרים. למרבה הצער, לפעמים יש צורך במספרים אקראיים ממש. הצורך הקל ביותר לציון הוא לצורך ייצור מפתחות הצפנה.
מה עושים? משתמשים ב”מקורות אקראיות”. מדידה של מליוניות שניה של תזמוני לחיצה על מקשים, פעילות דיסק, וכו’. הקרנל של לינוקס עושה את זה כל הזמן, ומייצר מאגר של נתונים אקראיים. תוכנית שרצה בלינוקס יכולה לבקש לקבל את המאגר הזה, ולהשתמש בו.
ומה קורה אם המאגר נגמר?
בלינוקס יש שתי אופציות. הראשונה היא לחכות עד שיגיע עוד מידע אקראי. השניה היא להשתמש בפונקציות “כמעט אקראיות” (Pseudo random number generators) כדי לקבל רצף של מספרים.
ההתקפה שמצאו החוקרים מתארת שתי בעיות מרכזיות. הראשונה היא שניתן לדעת על מספר מספרים אחרונים שהמערכת סיפקה מה הם היו. השניה היא שאפשר לתת חיזוי עתידי של מספרים שיינתנו מה הם יהיו. חשוב לציין שבשני המקרים מדובר בשתי הנחות לא פשוטות:
– שלתוקף יש גישה למבנה הפנימי של הליבה.
– שלא נוספו מספרים אקראיים אמיתייים במהלך הניבוי (אחורה או קדימה).
לפני שאני ממשיך בניתוח, חשוב לי להבהיר. חלק גדול מהבעיות שמצאו החוקרים הן בעיות אמיתיות שחשוב (ואפשר, ולא מסובך) לתקן.
עכשיו לכותרת הבומבסטית:
יש בעולם המחשבים שני תחומים שאזורי עבודתם דומים. כתוצאה מכך, לפעמים יש אנשים שטועים לחשוב שמדובר באותו התחום. השגיאה הזו כל כך נפוצה שלפעמים האנשים טועים לחשוב שמדובר באותו התחום, למרות שהם עצמם שייכים לאחד התחומים האלו.
התחומים הם הצפנה (קריפטוגרפיה) ואבטחת מידע.
בן אדם שלא יודע את גבולות הידע שלו עצמו עלול לחשוב שהוא מוסמך לתת אבחנות בעולם השני, והתוצאה היא כותרות מטעות כמו זו של המאמר בטוש הזוהר.
אני, למשל, איש אבטחת מידע. זהו תחום שבו השקעתי בללמוד את הגורמים, התוצאות, נהלי עבודה, האנשים הפועלים, ואני מרשה לעצמי להגדיר את עצמי כ”מומחה” בתחום. למרות שלמדתי קריפטוגרפיה, אני מבין את המושגים הבסיסים, יודע את הצורה, פחות או יותר, שהעולם הזה מתנהג, רחוק היום עד שאני ארשה לעצמי להגדיר את עצמי כמומחה קריפטוגרפיה. פיתוח או ניתוח של אלגוריתמי הצפנה נמצא הרחק מתחום הידע שלי, ואין לי שום יומרות בנידון.
כותבי המאמר, על פי מה שאני יכול לנתח (וכן, קראתי גם את המאמר עצמו, לא רק את הדיווח בעיתון) הם אנשי קריפטוגרפיה. הניתוח שלהם של אלגוריתם המספרים הפסודו אקראיים של לינוקס ראוי להערכה, והחולשות שהם מצאו בו הן אמיתיות, וראוי שיתוקנו. חלקים נרחבים מהניתוחים האנליטיים במאמר היו מעבר לידע שלי בקריפטוגרפיה כדי לעקוב במדוייק. אני גם יכול להבין את החומרה שהם מייחסים לחולשות האלו. מבחינת איש קריפטוגרפיה, אין גרוע (כמעט) ממספרים אקראיים שאינם אקראיים.
אבל בכל מה שקשור לאבטחת מידע, אני חושש שאין לי הרבה הערכה לכותבי המאמר. בכל מקום שהם ניסו, במהלך המאמר, להשליך על העולם האמיתי את החולשות, ולמצוא שימושים פרקטיים שתוקף יכול להשתמש בהם כדי לנסות לתקוף את המערכת, התוצאה היתה בינונית במקרה הטוב.
הסיבה היא שיחידת המספרים האקראיים היא רק רכיב אחד מתוך המכלול שמרכיב את המערכת, גם כשמדובר במערכת שמשתמשת במנגנונים קריפטוגרפיים. אני אתן דוגמאות:
הדוגמא הכי בולטת שאני יכול לחשוב עליה היא הטענה שבהנחה שלא מגיעה אנטרופיה חדשה, התוקף יכול לדעת מה עומדים להיות המספרים האקראיים הבאים שיינתנו. גם אם נתעלם לשניה מהעובדה שאם פרצנו למערכת אנחנו יכולים לדאוג שנדע מה הם, הרי שבעיה זו היא מובנית בצורה שהמערכת מוגדרת, ולא ניתנת לפתרון. כל מי שמשתמש במנגנון שלא חוסם אם אין לו אנטרופיה חייב להיות מודע לה, ועל כן היא לא נחשבת לבעיית אבטחת מידע.
כדי להבהיר למה אני מתכוון, בואו ננסה להפעיל את ההתקפה הזו בסיטואציה אמיתית. rsyncrypto משתמש במנגנון המתואר כדי לייצר מפתח נפרד לכל קובץ שהוא מצפין. בואו נניח שמייד אחרי שסיימתי להצפין את הקבצים שלי תוקף חודר למערכת, ומעוניין לפענח אותם. אבל rsyncrypto שומר גם את מפתחות ההצפנה על הדיסק כשהוא עובד. במילים אחרות, לתוקף יש פשוט גישה למפתחות שהוא צריך.
בואו נניח שמפתחות ההצפנה לא נשמרים (והיו כבר בקשות למוד פעולה כזה של התוכנה, כך שזו לא הנחה מופרכת). כל מה שהתוקף צריך לעשות הוא להפעיל את ההתקפה שמתוארת במאמר כדי להוציא את רשימת המספרים האקראיים האחרונים שהמערכת נתנה, ומהם הוא יודע מה המפתחות שמצפינים את הקבצים. נכון?
לא נכון.
הקבצים נשמרים לדיסק. פעולת השמירה לדיסק מייצרת השהיות שלא ניתנות לחיזוי, כיוון שהן תלויות בגורמים מכניים. ההשהיות האלו משוקללות כמקור למידע אקראי באלגוריתם הייצור של המספרים האקראיים. ההתקפה הניחה שלא נוספים מספרים כאלו. בקיצור, על אף כל ההנחות המקלות לתוקף, הוא לא יכול להפעיל את ההתקפה.
אני מאמין ששיקולים כאלו יעצרו אתכם כמעט בכל נתיב שתבחרו לנסות להפעיל את ההתקפה, כולל רוב ההתקפות שמתוארות במפורש במאמר.
לסיכום:
בעיה שצריך לפתור? כן.
בעית אבטחה חמורה? לא.
שחר
הערה חשובה:
חלק מהציטוטים שראיתי גורמים לזה להשמע כאילו שאני מזלזל בכותבי המאמר או בתוכנו. רציתי להבהיר שאין זה המצב. הכשל הקריפטוגרפי הוא אמיתי וחמור, ואני מלא הערכה לכותבי המאמר על שהצליחו לנווט בסבך האלגוריתמיקה של מנגנון המספרים האקראיים של לינוקס ולמצוא נתיב שמוביל לפרצה.
מה שאמרתי זה שההשלכות הפרקטיות של הפרצה קטנות ממה שכותבי המאמר מנסים לשוות להן, ועל כן היה ראוי ל-TheMarker להשתמש בכותרת פחות סנסציונית.
ש.
שחר אפשר גם לשלוח trackback לידיעות בלינמגזין, למקרה שלא שמת לב (במקום לשים קישור כפי שעשית).
http://linmagazine.co.il/hacking/themarker/linux-haifa-bug-21879#comment-13495
אם אין לך כלי שמזהה אוטומטית, הכתובת בתחתית הפוסט לפני התגובות:
http://linmagazine.co.il/trackback/21879
אורי
עד כמה שידעתי מגעת, לא ניתן לשלוח trackback מתוך ישרא לאתר חיצוני, אלא אם אתה עובד בעריכה "משוכללת למחצה". זו האחרונה לא עובדת על שום דבר למעט אינטרנט אקספלורר, כך שאני לא מסוגל לשלוח טראקבאקים החוצה.
במילים אחרות – זה לא שאני סנוב 🙂
שחר
לא חשדתי 😉
אם כבר העלית את הנושא של מומחים לאבטחת מידע.
יש סיכוי שמתישהו תכתוב משהו על איך נכנסים לתחום? (בעיקר מכיוון דברים שחשוב לדעת, תחומים שכדאי ללמוד, ולא איך להשיג עבודה).
כן, הם שכחו להזכיר שכדי לנצל את ה"בעיה המדהימה שרק הם יכלו לחשוב עליה" אתה צריך קודם כל לפרוץ לשרת.
אם כבר פרצת לשרת יש דרכים יותר טובות לנצל אותו, לא?
לא בדיוק.
ההגדרה של Forward reference security היא מערכת שעמידה מפני מישהו שלא יודע את הסוד שלך כרגע, אבל עלול לגלות אותו בעתיד.
לדוגמא, הצורה שבה SSL עובד, כברירת מחדל, אומרת שאם הקלטת תקשורת מוצפנת שלי עם אתר מאובטח, ובשלב מאוחר יותר פרצת לשרת וגנבת את המפתח הפרטי שלו, אתה יכול לפענח בדיעבד את התקשורת שלי. זו דוגמא למצב שבו אין Forward reference security, וזו נחשבת חולשה של SSL שהגרסא העדכנית ביותר פותרת (אלא שאף אחד לא תומך בה).
מה שהמאמר טוען זה שאם פרצת לשרת אתה יכול לפענח לא רק פעולות עתידיות, אלא גם פעולות שקרו בעבר. זו לא טענה קלה, ואסור לזלזל בה.
כמו שאמרתי, לדעתי צפויות לך, כמעט תמיד, בעיות פרקטיות בניצול הפירצה, אבל זה לא אומר שהפרצה חסרת משמעות.
שחר
מה שאני אומר הוא שאם כבר הצלחת להגיע אל השרת, תוכל לעשות דברים קלים יותר כדי לנצל אותו או את המשתמשים בו.
אני לא אומר שאין כאן בעיה כי זה לא יהיה נכון, אבל הבעיה שהם מציגים לדעתי לא כל כך קריטית כמו שניסו להציג אותה.
טוב, זה כמו שעוד לא נבראה הכספת שאי אפשר לפרוץ לתוכה, אם מישהו מתעקש, נראה לי שאפשר לפרוץ לכל מקום ולכל דבר.
לגבי SSL ואבטחה-קדימה: לא בדיוק. אפשר להשתמש בSSL בכמה דרכים, חלקן תומכות באבטחה-קדימה (למשל, DH בשימוש הרגיל שלו) וחלקן לא (למשל RSA, כנ"ל), וRSA הוא לא בהכרח יותר "ברירת מחדל" מאשר DH. ברירת המחדל של Firefox ושל Internet Explorer היא RSA, באמת, אבל ברירת המחדל של דפדפנים מבוססי-OpenSSL כמו Lynx היא DH, ואם תתחבר איתם לApache, למשל, תהיה לך אבטחה-קדימה. ויש עוד שיטות.
אגב, אני לא חושב שאבטחה-קדימה ברשת זה כזה שוס. אם מישהו פורץ לך לאתר וגונב את המפתח הפרטי שלך, הסבירות שיש לו סליק של מידע ששידרת קודם ושהוא טרח להקליט ולשמור למרות שהוא לא יכל לפתוח אותו לפני שהוא פרץ אליך היא די זעומה, ולעומת זאת, אם הוא כבר גנב לך את המפתח, הוא ממילא יכול לגנוב גם את כל שאר המידע על האתר, מראש ובדיעבד, כך שבפועל אין יתרון אבטחתי. מצד שני, אבטחה-קדימה מונעת ממך (למשל) לנתח את תעבורת הרשת המוצפנת עם אביזרי רשת ואבטחה שהתקנת בהם עותק של המפתח הפרטי שלך (גילוי נאות: זה מה שאני עושה לפרנסתי אצל המעסיק שלי).
אני אומר: אם אתה משתמש בהצפנה, פשוט שמור על המפתח שלך, ועל השרת. זה קו-ההגנה הא
תודה על הסקירה. מומחה קריפטו אני לא, וגם אין לי יומרות, אבל אני נוטה לקבל את הטענה שכאשר אתה כבר מחזיק סולמית על שרת לא-שלך, מצבך בהחלט טוב (בתלות בפרספקטיבה, כמובן). נקודה נוספת שהם מתארים היא הפגיעות היחסית גדולה יותר של התקני embeded, כמו נתבים מבוססי לינוקס, ודומיהם. מכונות אלו נדיר שכוללות דיסק קשיח, ולכן לפחות האלמנט הזה פחות צפוי. מצד שני, גם מכונות שכאלו לא נוטות להיפרץ תכופות, וגם אם כן, הכלים הזמינים עליהן כל כך מוגבלים, שלא סביר שתוכל לעשות משהו לטובת קצירת המידע שאתה כל כך רוצה.
עדיין, ראוי שהעניין הזה יתוקן, ובמהרה.
אני אישית קראתי רק את המאמר המקורי (עם הבנתי הבסיסית בנושא, הבנתי פחות או יותר את הבעיה), וכתבה קצרה באנגלית, ולא הייתי מודע להד התקשורתי שכרגיל מנסים להדביק לזה. כל הכבוד על היוזמה להבהיר את הדברים, למרות שזה ממילא תחום עיסוקך 🙂
ואתה לא יכול שלא לדחוף איזה פרסומת סמויה לכל פוסט, הא, שחר? 🙂
האמת היא שאפילו לא חשבתי שיש שם פרסומת סמויה. מדרך הטבע, כל דבר שנאמר בבלוג הזה נאמר מפי, ועל כן אתה יכול לטעון שכל הבלוג הוא פרסומת…
ועוד להגנתי אני אציין שאם היית מגיע אלי עם בקשה לעבודה בתחום אבטחת המידע, סביר להניח שהייתי אומר לך שאני לא מסוגל לקבל אותה. למרבה הצער, במצבי, כמות שעות העבודה שאני, אישית (בניגוד ללינגנו) יכול לתת נמוכה משמעותית.
שחר
לקרוא ישר אח"כ את זה,
http://israblog.nana.co.il/blogread.asp?blog=9542&blogcode=3916981
ובכן, משעשע היא מילה מתאימה.
היי,
אני מחפש מומחים לעבודה בתחום secure coding.
התשמשתי בשירותי חברות ההשמה למציאתם, אבל נאדה,
יש דרך עדיפה להגיע לחבר’ה האלה?
אני לא יודע. מעולם לא ניסיתי לגייס.
אם אתה מחפש עבודות מקומיות שיועצים חיצוניים יכולים לעשות, תרגיש חופשי לפנות אלי במייל. אם אתה מחפש מישהו במשרה מלאה, אני חושש שאני לא יודע איך לעזור לך.
שחר
חוששתני שאני צריך מישהו למשרה מלאה. אתה יכל לתת כיוון לפורומים וכאלה? מה לגבי חברים שלך?
כמו שאמרתי, אני חושש שאני לא יכול לעזור לך.
שחר