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

پاشنه آشيل

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