יום: 19 במרץ 2005

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

הבעיה הראשונה הינה התקפת Land על חלונות XP. זוהי התקפה בת לפחות חמש שנים, סביר להניח שיותר. התשובה של מיקרוסופט? “זו לא בעיית אבטחה, כי המחשב לא קורס, ואחרי שההתקפה מסתיימת המחשב ממשיך לעבוד כרגיל. תשימו firewall”. מה? איך תריץ שרת אם ה-firewall שלו חוסם את כל הפורטים?

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

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

ולפני שאוהדי הלינוקס מבין קוראי מוציאים את הדגלים, מסתבר שבלינוקס יש בעיות דומות. לא באותה רמה – הפעם מדובר על מישהו שצריך להיות בעל חשבון רשום על המכונה. עדיין, התקפה שאני לראשונה שמעתי עליה ב-1991 (כן, כן, לפני כמעט 14 שנה) עדיין עובדת על רוב ההפצות המודרניות של לינוקס. לא על דביאן.

בניגוד למקרה המיקרוסופטי, לא מדובר פה בבאג בקרנל. מדובר פה בניהול משאבים נכון. אנשי דביאן (גם FreeBSD ו-OpenBSD) כיוונו את המערכות להיות חסינות לבעיה הזו כברירת מחדל. אנשי RedHat, Gentoo ו-Mandrake לא חשבו על ההתקפה הזו כאשר כיוונו את המערכות להתקנה. היא פשוט ישנה מידי.

רק כדי להסביר, fork הינה פקודה שמייצרת תהליך חדש במערכת ע”י שכפול התהליך הנוכחי. fork bomb הינה תוכנית קטנה אשר מייצרת תהליכים בלולאה. למעשה, מדובר בתוכנית הפשוטה הבאה:

#include <sys/types.h>
#include 

int main()
{
  while(1)
    fork();
}

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

אני רק אציין במאמר מוסגר שבעוד שמכונת הדביאן שלי מגבילה אותי ל-4096 תהליכים כאשר אני מתחבר בצורה טקסטואלית, אני לא מוגבל כאשר אני מתחבר בצורה גרפית או דרך SSH. עוד לא בדקתי את היכולת להריץ fork bomb. אני אדווח אחרי שאני אשמור את הנתונים שלי.

צריך להרים פרוייקט של “רשימת קניות” של בדיקות שצריך לעשות על מערכת לפני שמכריזים עליה כשירה לעבודה.

שחר

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

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

למרבה השמחה, האיחוד האירופאי לא ממש מתלהב מהרעיון. מה שמשמח אותי במיוחד זה ההבנה של הבעיה האמיתית עם מה שמיקרוסופט מציעים. האיחוד מדבר על ארבעה מכשולים עם מדיניות הרישוי הנוכחית של מיקרוסופט:
1. חברות שרצו גישה לתיעוד התקשו לקבל אותה.
2. חברות שרצו לקנות גישה לפרוטוקולים מסויימים נאלצו לשלם על גישה גם לפרוטוקולים שבהם הן לא מעונינות.
3. מפתחים של מוצרי קוד פתוח אשר מתחרים במיקרוסופט לא יכולים לקבל גישה לפרוטוקולים
4. רמת המחירים אינה מוצדקת.

על פי ג’ונתן טוד, דובר הגוף המפקח, מספר 4 הוא המשמעותי ביותר.

לדעתי, מיקרוסופט עומדת להתפשר על 1, 2 ו-4. פשוט, התפשרות על הנקודות האילו עשויה, מבחינתם, להסיר את הגוף האירופאי מהגב שלהם, בלי לייצר תחרות מצד הגוף שהכי מסכן את המונופול שלהם – מוצרי הקוד הפתוח. הם לא עומדים להתפשר על 3 בקלות.

בעתיד הקרוב אנחנו נתחיל לשמוע טיעונים בסגנון של:
“האיחוד האירופאי דורש מאיתנו לוותר על הקניין הרוחני שלנו”
“לא ניתן לגבות כספים…”
וכו. לא צריך לקחת את הטיעונים האילו יותר מידי ברצינות. הבעיה האמיתית של מיקרוסופט עם מספר 3 היא שמספר 3 באמת באמת יעשה צעדים משמעותיים לפתרון אותה ההתנהגות שגרמה למיקרוסופט להמצא אשמה בדין פלילי. במילים אחרות, מיקרוסופט לא עומדת להסכים לפתוח את הפרוטוקולים שלה בפני פרוייקטי קוד פתוח בגלל שזה הצעד הכי חשוב לפתרון הבעיה.

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

שחר