ארכיון יומי: 1 אפריל, 2009

QA עצמי

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

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

הבעיה התקיימה בפונקציה register_file היות וכתבתי את הקוד בצורה הזו:

84   int length          = strlen(pathname) +1;
85   memset(file_rec->pathname, 0, FILENAME_MAX);
86   strncpy(file_rec->pathname, pathname, length);

כמו שאפשר לראות בשורה 86, בעוד ש file_rec->pathname הוא בגודל של FILENAME_MAX, , במקום לוודא שהאורך של pathname (פרמטר שאני מקבל בפונקציה) אינו גדול יותר מ FILENAME_MAX אני מניח שמישהו יבדוק את זה כשהוא מזין לי את אורך המחרוזת, ובכך אקבל אורך מחרוזת שהוא לא גדול מ FILENAME_MAX. כמובן שזו הנחה שגוייה, ולכן אם תשתמשו בAPI הזה ללא העתקה של מחרוזת באורך המתאים, יהיה ניתן לגרום לbuffer overflow אצלי בקוד.

לכן תיקנתי את הקוד בצורה הבאה:

84   int length          = strlen(pathname) +1;
85   if (length > FILENAME_MAX) /* Making sure not to have a buffer overflow !!! */
86   {
87     length = FILENAME_MAX;
88   }
89   memset(file_rec->pathname, 0, FILENAME_MAX);
90   strncpy(file_rec->pathname, pathname, length -1);

ועכשיו גם בפונקציה הזו, כאשר לא יבדקו מראש את אורך המחרוזת, לא יהיה ניתן לבצע לי buffer overflow למרות שאם לא תבדקו, עדיין תהיו חשופים להתקפה, אבל לא בגלל הקוד שלי…

חשוב להבהיר שהקוד שלי לכשעצמו לא הכיל buffer overflow היות והשימוש בפונקציה התבצע בצורה הבאה:

206       char path[FILENAME_MAX];
207       memset(&path, 0, FILENAME_MAX);
208       strncpy(path, argv[counter], FILENAME_MAX - 1);
209       if (path_exists(path))
210       {
211         if (! register_file(list, path, FLAGS))

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

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

מי שלא מבין את דלפי…

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

וזה בלי להזכיר בכלל מהיכולות של השפה, אשר מסוגלת לספק את כל מה ש C מסוגלת לספק, אבל בגישה שפויה, ועם הרבה יותר טכנולוגיות שהיא תומכת בהם, כי C נתקעה איפשהו בשנות ה 70 (אפילו C99 ששוחרר לפני 10 שנים לא תרם להלך החשיבה של השפה), בעוד שפסקל עדיין ממשיכה להתפתח ולצמוח.

אפשר לקחת את כח השפות השולטות כיום בשוק למשל: C, C++, ִJava, C#, Python, Ruby אנחנו יכולים לראות של C ו ++C כל הזמן מחפשים דרכים עוקפות ובגלל זה יש לנו את שאר הטנולוגיות שהזכרתי. אחד הדברים הכי בולטים בכל השפות האחרות, זה הניסיון לברוח מעודף הסימנים המורכבים והגישה העודף גמישה (אשר יוצרת רק בעיות) של C ו ++C תוך כדי ניסיון לשמור על תחביר קרוב כמה שניתן ל2 הטכנולוגיות הנפוצות כל כך.

העניין הוא ש פיתו,ןרובי ואפילו ב C# אפשר למצוא הרבה גישות וצורות משותפות לשפה "מתה חייה" בשם פסקל מונחת עצמים. כלומר בשביל לתת כוח תכנות מצד אחד וקלות פיתוח מצד שני, פסקל הוכנסה בהסתר (כמובן שלפיתון ורובי יש גם את הצדדים של Smalltalk אבל אם תסירו אותם, אתם עדיין תגלו כמה דברים מעניינים) ועושה להרבה אנשים חיים טובים ופשוטים יותר.

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

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

דוגמא אחת (מני רבות): http://showmedo.com/videos/video?name=4010010&fromSeriesID=401

אפילו בלזרוס זה יותר פשוט מזה..