28-01-2006, 15:33
|
 |
|
|
חבר מתאריך: 12.03.03
הודעות: 2,176
|
|
|
הנה הסבר קצר שכתבתי
אני מקווה שהוא מדויק, תבדקו ותתקנו אותי בהתאם.
התקפת Teardrop
תיאור: בעיית חפיפת מקטעים בפרוטוקול IP.
מערכות בסיכון: Windows NT 4.0 with SP3 / Windows 95 / Linux up to 2.0.32
תאריך גילוי: 13/11/1997
הבעיה נובעת מכך שמודול ה-IP של המערכות הנ"ל מתבססות על ההנחה שחבילות IP שעברו חלוקה, התחלקו ללא חפיפת מידע. כלומר מיד אחרי שמקטע אחד נגמר מתחיל המקטע הבא.
במקרים נורמליים אכן זהו המצב, או כך לפחות הוא צריך להיות. הבעיה מתחילה כאשר החלוקה התבצעה באופן בו ישנם מקטעים חופפים.
נתאר מקרה קצר בו מגיעה חבילה שחולקה למקטעים בצורה נורמלית. תחילה מגיע המקטע הראשון שמתחיל מהבית הראשון בחבילה, ונניח שאורוכו הוא N בתים (שחייב להיות כפולה של 8). המקטע השני במקרה נורמלי יתחיל בבית ה-(N+1) של החבילה. לאחר שכל מקטעי החבילה הגיעו, יש לשלוף מהם את החלק שמהווה את המידע הנחוץ למשתמש ולהעביר אותו למשתמש כחבילה אחת.
כל מקטע שמגיע מכיל שדה שנקרא Offset, שעל-פיו מחליטים היכן בחבילה מתחיל אותו מקטע. במקטע הראשון השדה הזה יהיה שווה ל-0, במקטע השני השדה הזה יהיה N/8 (כי הרי אורך המקטע הקודם חייב להיות בכפולות של 8), וכך הלאה עד המקטע האחרון.
לביצוע פעולת ההרכבה המודול עושה העתקת זיכרון מכל המקטעים (ע"פ הסדר) לתוך חוצץ אחד, ונשמר מצביע מיוחד השומר את המקום בחוצץ שעד אליו הספקנו למלא בתים מהמקטעים (offset). עבור כל מקטע לפני העתקתו נעשה שימוש בעוד מצביע (end) שמסמן את המיקוםבחוצץ שעד אליו נעתיק בתים מהמקטע הנוכחי, והמודול מציב בו את אורך המקטע שאנו רוצים להעתיק + שדה ההיסט שנלקח מאותו מקטע (cur_offset). כלומר כבר לפני פעולת ההעתקה end אמור להצביע לסוף המקטע שאנו עומדים להעתיק (בתוך החוצץ כמובן).
כעת פעולת ההעתקה מתבצעת, מספר הבתים שיועתקו מחושב כך: end - offset, שיתן לנו את אורך המקטע שאנו מעוניינים להעתיק. והמקטע יועתק למיקום offset בחוצץ (מיד אחרי המקטע הקודם). ככה הדברים מתבצעים עד שמועתקת כל החבילה מהמקטעים.
[התמונה הבאה מגיעה מקישור שלא מתחיל ב https ולכן לא הוטמעה בדף כדי לשמור על https תקין: http://www.camtp.uni-mb.si/books/Internet-Book/IP_TeardropAttackCorrect.jpg]
עד כאן הכל טוב ויפה, ועכשיו ניגע בבעיה האמיתית שאותה יוצרת מתקפת Teardrop, לצורך העיניין נסבך קצת את המקרה הקודם. נניח שהמקטע הראשון הוא באורך X, אורכו של המקטע השני קטן מ-X ומתחיל בהיסט נמוך מספיק כדי שהמקטע הראשון יכלול בתוכו את כל המקטע השני. נבהיר זאת ע"י דוגמא: המקטע הראשון הוא באורך 80, המקטע השני הוא באורך 32, ומסומן שהוא מתחיל כבר בהיסט 8, ולא בהיסט 80 כמו שמצופה. כלומר המקטע השני מכיל רק את המידע מהבית ה-8 עד הבית ה-40 בחבילה, ואילו המקטע הראשון מכיל את המידע מהבית הראשון עד הבית ה-80, כך שהמקטע השני נכנס כולו בתוך המקטע הראשון. נראה מה קורה כאשר ננסה להעתיק את המקטעים האלו לחוצץ.
[התמונה הבאה מגיעה מקישור שלא מתחיל ב https ולכן לא הוטמעה בדף כדי לשמור על https תקין: http://www.camtp.uni-mb.si/books/Internet-Book/IP_TeardropAttackIncorrect.jpg]
תחילה יועתק המקטע הראשון באורך 80 ללא כל בעיה, המצביע offset יאותחל ל-80. כעת לפני העתקת המקטע השני נשים ב-end את האורך 32 + cur_offset , כלומר 40. כעת נעבור לביצוע פעולת ההעתקה שתעתיק מהמקטע לחוצץ קטע זיכרון באורך: end - offset = 40 - 80 , ופונקצית ההעתקה תנסה להעתיק קטע זיכרון באורך 40- , פונקצית ההעתקה לא מבינה שמדובר כאן בטעות והיא תהפוך את המספר השלילי הזה למספר חיובי גדול מאד, ופונקצית ההעתקה במקרה כזה תגרום לקריסה של מודול ה-IP ואולי אף לקריסה של כל המערכת (תלוי במערכת ההפעלה, במודול עצמו, ובכמות הזיכרון של המחשב).
כאשר רוצים ליצור מתקפת Teardrop, שולחים חבילת מידע שמקוטעת באופן כזה שישנה חפיפה מלאה בין שני מקטעים, ובכך בעצם גורמים למודול ה-IP לקרוס, ובמערכות Windows NT 4.0 / 95 מערכת ההפעלה כולה קורסת, ומוצגת הודעת השגיאה STOP 0x0000000A or 0x00000019 .
לבעלי המערכות הנמצאות בסיכון ניתן למצוא תיקון לבאג באתר מיקרוסופט, עבור מערכות WinNT 4.0 ניתן להתקין את SP4 הכוללת את התיקון.
במערכות לינוקס הבאג תוקן בגרסאות שאחרי 2.0.32, בגירסאות לינוקס של BSD הבאג לא נמצא.
מקורות:
http://support.microsoft.com/kb/q179129/
http://www.camtp.uni-mb.si/books/Internet-Book/
http://www.windowsitpro.com/Article.../9216/9216.html
|
ראשי
צ'אט
)
מצב כלאיים
