ההגנות האלה כנגד "תולעים" גם אינן מושלמות:

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2239&p=2

שומדבר לא מושלם :

הת'רד דיבר על האם x86-64 הגיע מוקדם מדי או לא, ולא על מעבד ספציפי.

לאופטרון הוא לא הגיע מוקדם מדי (בכלל אופטרון זה שם מוצר שנולד כש-AMD הכריזה על מעבדי 64 ביט).

ברגע שיש לך ליבה שיודעת לתמוך בקוד 64 ביט (K8) זה ממש פשוט לשחרר אותה כמעבד לשרתים (Opteron(, לשוק הביתי (A64) או לשוק הביתי אבל רק עם 32 ביט (Semperon).

הבעיה של אינטל היא שהם לא יכלו להוציא ליבת 64 ביט לשרתים לפני שהם הבינו שהם מאבדים את השוק ל- AMD, בגלל שאחרת הם היו פוגעים באיטניום.

במצב שנוצר והעובדות שנקבעו בשטח, הם הבינו שאיבוד נתח השוק אם הם ישארו ללא פתרון X86-64 יהיה גרוע בהרבה מהפגיעה באיטניום, ויאפשר למצב את AMD כחברה מכובדת למעבדי שרתים שגם חברות Fortune 500 קונות שרתים המבוססים על מעבדיה.

ואני חוזר וצועק:

מי שמריץ XP עם SP2 מרוויח כבר היום ממעבדי Athlon 64 בגלל ה- NX וה- DEP שמשתמש בו ב- SP2!

לא ברור לי למה AMD לא מפרסמת אותם בתור "המעבד שחסין לתולעים ברשת".

התרד הזה גם לא דיבר על מה שאת מדבר

התרד הזה מדבר על זה שכאילו הגיעו ה מעבדים מבית אינטל שתומכים ב 64 ביט זה הכל.

ההגנות האלה כנגד "תולעים" גם אינן מושלמות:

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2239&p=2

אתה צודק... לא חשבתי אף פעם על האפשרות הזאת.

ברור שקשה הרבה יותר לבנות buffer overflow exploits תוך הסתמכות על קוד קיים בלבד.

השלב הבא לדעתי:

מיקום אקראי של DLL'ים בזכרון כדי שגם התקפות כאלה יכשלו (כל DLL ניתן לטעינה לכל כתובת שהיא בזכרון הוירטואלי).

כמובן שזה יהיה tec support nightmare אבל זה ענין אחר... (כל מיני באגים שמופעלים רק כשה- DLL יושב בכתובת מסוימת בזכרון וכו').

אני שומע אתם אומרים

x86

למשל:

x86-64

מה זה x86 ?

אני שומע אתם אומרים

x86

למשל:

x86-64

מה זה x86 ?

x86 הוא השם הגנרי לכל המעבדים שנגזרו מה- 8086 המקורי של אינטל ותואמים לו בתוכנה. מכיון שהמעבדים הראשונים נקראו 8086, 80186, 80286, 80386, 80486, או 80x86 קוראים לכל המעבדים הנ"ל (וכל אלו שבאו אחריהם כמו הפנטיום והמעבדים של AMD ואחרים) בשם x86

x86-64 הוא השם שנתנה AMD להרחבות ה- 64 ביט ל- x86. אינטל קראה לאותו דבר בדיוק (שהיא העתיקה מ- AMD) בשם EMT64.

ולגבי הNX, מעניין איך זה מגן (אם בכלל) במקרה של heap overflow. אלו אמנם מסובכים בהרבה, אבל קיימים.

מה שחסר לי בכל הקטע הזה הוא שאני לא מבין למה לא סימנו את הדפים של הStack בתור non-executable בMMU. מישהו מנסה לגשת? יש exception.

מישהו יודע למה היה צריך את הNX?

ולגבי הNX, מעניין איך זה מגן (אם בכלל) במקרה של heap overflow. אלו אמנם מסובכים בהרבה, אבל קיימים.

מה שחסר לי בכל הקטע הזה הוא שאני לא מבין למה לא סימנו את הדפים של הStack בתור non-executable בMMU. מישהו מנסה לגשת? יש exception.

מישהו יודע למה היה צריך את הNX?

זה בדיוק ה- NX!!!

עד עכשיו לא היו ביטים של executable עבור כל דף ב- MMU. אני מניח שבגלל זה זה נקרא non-executable, כדי שערך ה- default שהוא 0 ימשיך להיות "executable" ורק מי שמשתמש בתכונה החדשה ידליק אותו ב- 1.

מה שכן היה עד עכשיו זה ביט executable ברמת הסגמנט, לא ברמת הדף. בכל מקרה בלינוקס וב- OpenBSD כבר היתה תמיכה בעבר במשהו מעין NX תוך שימוש בתכונה הזאת.

http://kerneltrap.org/node.php?id=573

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

http://www.w00w00.org/files/articles/heaptut.txt

אהא!!!

תודה ;D

אתה צודק... לא חשבתי אף פעם על האפשרות הזאת.

ברור שקשה הרבה יותר לבנות buffer overflow exploits תוך הסתמכות על קוד קיים בלבד.

השלב הבא לדעתי:

מיקום אקראי של DLL'ים בזכרון כדי שגם התקפות כאלה יכשלו (כל DLL ניתן לטעינה לכל כתובת שהיא בזכרון הוירטואלי).

כמובן שזה יהיה tec support nightmare אבל זה ענין אחר... (כל מיני באגים שמופעלים רק כשה- DLL יושב בכתובת מסוימת בזכרון וכו').

פתרון מעניין.

מעניין אם ניתן יהיה לעקוף את זה ע"י ניצול של 2 buffer overflows בו זמנית, באחד כותבים את הקוד, השני מבצע.

מה זה "בו זמנית"?

אותו חור אבטחה מותקף משני מקורות שונים?

שני חורי אבטחה?

אותו חור מותקף פעמיים ברצף?

זה לא משנה. ביט ה- NX נקבע מראש, ומה שלא ניתן להרצה, לא ניתן להרצה - נקודה.

ככלל, ישנה שיטה לשימוש ב- NX שנקראת W^X, כלומר write xor execute מה שאומר שכל דף יכול להיות או ניתן לכתיבה, או ניתן להרצה אבל לא שניהם.

כמובן בזמן טעינת קוד ע"י מערכת ההפעלה יש לשנות את האזור המיועד מ- W ל- X.

השיטה לא מגינה בפני ניצול לרעה של קוד קיים ע"י buffer overflow.

התכוונתי לשני חורים המותקפים בו זמנית.

האם ה NX הוא יחסי לתכנית שרצה, או שהמידע נשמר בצורה גלובאלית?

התכוונתי לשני חורים המותקפים בו זמנית.

האם ה NX הוא יחסי לתכנית שרצה, או שהמידע נשמר בצורה גלובאלית?

המידע נשמר בטבלאות ה- MMU .

אני לא מומחה כזה גדול בארכיטקטורת התוכנה של ה- x86. אני מניח שקיימת טבלת MMU לכל process. (ב- x86 טבלאות הדפים הן בעלות 2 רמות למיטב ידיעתי)

בכל מקרה, כאשר קורה task switch, מופעלת הטבלה המתאימה לאותו process.

בשורה התחתונה, הביטים של ה- NX שמורים לכל process בטבלאות שלו, גם אם הן לא פעילות באותו רגע כי רץ process אחר.