|   
                  
                  پروسسورهای امن 
                  
                  پاشنه آشیل 
                  
                  شاید تا کنون نام
                  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 
                  است. به نظر نمی رسد اینگونه باشد هر چند باید  منتظر نتایج عملی 
                  این تکنولوژی باشیم اما از همین اکنون میتوان پیش بینی کرد که 
                  هکرها هم راههای جدیدی خواهند یافت. بهر حال این نکته را باید 
                  یادآوری کنیم که تا به امروز مهمترین تکنیک مورد استفاده هکرها 
                  سرریز بافر بوده ست. با توجه به این نکته روزهای سختی برای آنها 
                  در پیش است.   |