• مشکی
  • سفید
  • سبز
  • آبی
  • قرمز
  • نارنجی
  • بنفش
  • طلایی
  • تعداد بازديد :
  • 2249
  • شنبه 1383/3/2
  • تاريخ :

پروسسورهای امن

پاشنه آشیل

شاید تا كنون نامBuffer Overflowیا سرریز بافر را  شنیده باشید. بعنوان یك متخصص امنیت شبكه این نام قاعدتا كابوس همیشگی شما بوده است. اگر این نام را نشنیده اید اجازه دهید تا به شكل دیگری مساله را معرفی كنیم: بعنوان یك مدیر شبكه یا كارشناس كامپیوتر بدترین خاطره ماههای گذشته خود را مرور كنید...Blaster!

یك كرم كامپیوتری كه برای آلوده كردن تمامی كامپیوترهای سازمان شما تنها به چند ثاینه وقت و یك ارتباط معمولی با اینترنت نیاز داشت و البته یكعدد سیستم عامل ویندوز. طبق معمول پس از شیوع یك كرم اینترنتی با آلودگی بالا همه به دنبال مقصرین اصلی میگردند. میكروسافت در طی تنها چند ماه بارها مجبور به انتشارPatchهای جدید شد و البته بیش از هر زمان دیگری اعتبارش به چالش كشیده شد. اما آیا  واقعا مقصر اصلی میكروسافت بود؟

تاریخچه

شروع این ماجرا مربوط به سالها پیش است. طراحان زبان برنامه نویسیC و سپسC++ ظاهرا بیش از حد لازم دمكرات بودند. باید قبول كرد كه اغلب اوقات كمكی محافظه كاری اگر چاشنی كار شود نتیجه بهتر خواهد بود! در حالی كه اغلب زبانهای برنامه نویسی به شكلی برنامه نویس را در تخصیص و یا كاربری حافظه محدود میكنند این زبان دست برنامه نویس را تا حد امكان باز گذاشته تا جایی كه برنامه نویس میتواند یك رشته صد بایتی را در یك حافظه ده بایتی كپی كند. همین ویژگی باعث شد تا برنامه نویسانC كمتر حساسیتی در زمینه چك كردن طول رشته هایی كه در یك بافر كپی میشوند از خود نشان دهند. نتیجه همه اینها بوجود آمدن یك سرگرمی بسیار پر طرفدار برای هكرها بود. با چند كلك فنی میتوان به جای رشته ورودی یك رشته طولانی حاوی كد یكBack Door را وارد كرد و نتیجه؟ افتادن كنترل كامل كامپیوتر مورد نظر در دست هكر.

اصل ماجرا به همین سادگیاست و در واقع پایه فنی بسیاری از كرمهای اینترنتی و بسیاری از خرابكاری ها همین خطاست.Blaster هم بر اساس وجود یك چنین خطایی در یكی از سرویسهایRPC ویندوز عمل میكرد. اما اگر مشكل به این سادگیاست چرا تا كنون برای حل آن اقدامی نشده است؟ خواهید گفت دستكم میشد به برنامه نویسان پیشنهاد كرد كه لطفا در هنگام نوشتن برنامه طول رشته های ورودی را حتما با طول بافر چك كنید. بسیار پیشنهاد خوبیاست اما دو مشكل بزرگ برای عملی كردن آن وجود دارد. اول اینكه برنامه نویسانC اصلا از این پیشنهاد شما خوششان نخواهد آمد. آنها همیشه كارهای مهمتری از چك كردن طول رشته ها دارند! و دومین نكته اینكه حجم بسیار عظیمی از كدهایی را كه قبلا نوشته شده نمیتوان دوباره تغییر داد. این مشكل دوم دقیقا چیزیاست كه میكروسافت با آن روبروست : كد ویندوز بنا به برخی روایتها ملغمه عجیب و غریبیاست كه هنوز حتی یادگارهایی از كد داس نیز در آن موجود است.

راه حلهایی برای آینده

واقعیت اینست كه تا كنون یك دوجین راه حل برای حل این مشكل پیشنهاد شده است و بسیاری از تكنولوژیهای جدید یكی از اولین ویژگیهای خود را حل این مشكل عنوان میكنند. جاوا و.NET دو مثال خوب برای این قضیه هستند. این دو زبان (اجازه دهید با كمی اغماض.NET را زبان بنامیم هر چند اینگونه نیست) مكانیزمهایسخت گیرانه ای برای مدیریت حافظه دارند و عملا كنترل كامل حافظه برنامه را از دست برنامه نویس خارج میكنند.

اما همانگونه كه حدس میزنید این دو نیز همان اشكالهای قبلی را دارند: تغییر تمام كدهای موجود و تبدیل آنها به كدهای جاوا و یا.NET عملی نیست. اینها مشكل را فقط در آینده دور حل كرده اند اما اكنون چاره چیست؟

تغییر دیدگاه

اخیرا شركتAMD پروسسورهایی را روانه بازار كرده است كه مهمترین ویژگی آنها اینست : مقاومت در برابر حمله سرریز بافر. این اولین بار نیست كه برای مشكلات  نرم افزاری راه حلهای سخت افزاری پیشنهاد میشود. در واقع به نظر میرسد مشكل دارد در جایی حل میشود كه اساسا انتظار آن نمیرفت: در پایین ترین سطح سیستم: پروسسور.

همانگونه كه پیشتر دیدیم این حمله تنها زمانی امكان پذیر میشود كه هكر بتواند بهشی از كد را وارد داده كند و به اجرای آن بپدازد. هر برنامه در هنگام اجرا از بخشهای مختلفی در حافظه تشكیل میشود كه مهمترین بخشهای آن عبارتند از دو بخش كد و داده. تا كنون این دو بخش از دید پردازنده ها یكسان بودند و پردازنده تفاوتی بین آنها نمیگذاشت . این تنها نرم افزارها بودند كه این تفاوت را درك میكردند. اما ازین پس پردازنده هایAMD سریAthlon 64 (برای كامپیوترهای شخصی) و سریOpteron (برای سرورها) این تفاوت را خواهند فهمید. به محض اینكه هكر سعی كند یك قطعه كد را در قسمت مربوط به داده برنامه اجرا كند پردازنده جلوی آنرا خواهد گرفت و یك پیغام خطا برای سیستم عامل ارسال خواهد كرد و سیستم عامل برنامه عامل خطا را خواهد بست.

دقت كنید كه كاركرد نهایی این تكنیك وابسته به همكاری كامل سیستم عامل و پردازنده است . به همین دلیل مدیرانAMD عملكرد نهایی این تكنیك را در نسخه آیندهXP وعده داده اند. البتهIntel نیز برای اینكه از قافله عقب نماند خبر از همكاری با میكروسافت برای حل این مشكل داده است. سری آیندهItanium از شركت اینتل خصلتی مشابهAthlon هایAMD خواهد داشت.

افق

آیا این به معنی پایان داستانBlasterیاSlammer است. به نظر نمی رسد اینگونه باشد هر چند باید  منتظر نتایج عملی این تكنولوژی باشیم اما از همین اكنون میتوان پیش بینی كرد كه هكرها هم راههای جدیدی خواهند یافت. بهر حال این نكته را باید یادآوری كنیم كه تا به امروز مهمترین تكنیك مورد استفاده هكرها سرریز بافر بوده ست. با توجه به این نكته روزهای سختی برای آنها در پیش است.

برگرفته از سایت www.ircert.com

UserName