یک باگ جدید و جدی توی glibc دیده شده. یک باگ خیلی جدی. کتابخونه سی گنو یا همون glibc یکی از بخش‌های بسیار مهم اکثر توزیع های لینوکس است. حالا یک باگ توی این کتابخونه هزاران برنامه لینوکس رو تهدید می کنه. این باگ نسبتا شبیه باگ سال گذشته GHOST است (CVE-2015-0235) که اجازه می داد از راه دور کدهایی روی ماشین اجرا بشه.
باگ فعلی (CVE-2015-7547) یک باگ سرریز استک (stack based buffer overflow) است در بخش کلاینت دی ان اس glibc که وظیفه تبدیل کردن آدرس های قابل فهم برای آدم ها (مثلا jadi.net) به آی پی رو داره.
کلیت ماجرا
این مشکل وقتی دیده می شه که یک دستگاه دارای باگ سعی کنه به یک DNS سرور بدطینت ریکوئست بزنه و نتایج رو توی حافظه بذاره (تابع getaddrinfo). چیزی که دی ان اس سرور بدخواه بدجنس بر می گردونه ممکنه حاوی کدی باشه که کار مخربی می کنه و نشستنش توی حافظه – در سطرح تئوری – باعث اجراش خواهد شد. البته در عمل این اتفاق تقریبا غیر ممکنه چون انواع مکانیزمهای امنیتی جلوی اونو خواهند گرفت (شامل ASLR). حالت بعدی اینه که حمله کننده به شکل مرد میانی درخواست های دی ان اس رو خودش بر می گردونه و بینشون کدهای نامناسب درج می کنه.
چه کسانی مبتلا هستن
تقریبا هر سیستم لینوکس جدید با این مشکل مواجه خواهد بود. این باگ از جی لیب سی ۲.۹ به بعد ظاهر شده و در نتیجه هر برنامه ای که با استفاده از توابع glibc به شبکه دسترسی پیدا می کنه ریسک داره. نمونه ها؟ اس اس اچ، سودو و کرل. لیست کامل می خواین؟ تقریبا غیر ممکنه. بهتره تصور کنین اکثر برنامه های مرتبط با شبکه و حتی زبون های پایتون، پی اچ پی، روبی، … و البته برنامه‌های بیت کوین.
مشکل دقیقا کجاست
محققین گوگل می گن که بخشی از glibc که به دی ان اس ریکوئست می زنه مشکل داره. این مساله به جی لیب سی تذکر داده شده و اصلاح شده و همه باید آپدیت کنیم… حداقل در طول هفته آینده دائما آپدیت کنیم. مهندسین گوگل می گن:
جی لیب سی ۲۰۴۸ بایت برای استک الوک می کنه تا جواب دی ان اس از _nss_dns_gethostbyname4_r رو توش ذخیره کنه. جلوتر در تابع send_dg و send_vc اگر جواب بزرگتر از ۲۰۴۸ بایت باشه، بافر جدیدی درست می شه و پوینترها آپدیت می‌شن. در شرایط خاص ناهماهنگی بین بافر استک و تخصیص دهی جدید هیپ پیش می یاد و نتیجه این می شه که بافر استک برای ذخیره کردن جواب دی ان اس استفاده می شه، حتی در مواقعی که جواب بزرگتر از اندازه این بافر باشه. این مساله موجب اورفلوی بافر استک می شه.
(فارسی گفتن اینها عجیب می شه. متن اصلی اینجاست).
اثبات شده
سه شنبه مهندس گوگل فرمین سرنا یک اکسپلویت برای اثبات این مساله منتشر کرد. با استفاده از این اثبات مفهوم می شه چک کرد که آیا برنامه های ما در مقابل این مشکل صدمه پذیر هستن یا نه (هستن!).
اصلاح
مهندسین گوگل با همراهی ردهت یک پچ برای حل مشکل ارائه کردن. اما مساله اینه که حالا تک تک توزیع‌ها باید glibc خودشون رو آپدیت کنن و هر برنامه ای که استاتیک این کتابخونه رو لینک کرده، باید خودش رو آپدیت کنه. مثل همیشه در دنیای لینوکس وقتی مشکلات دیده بشن سریعا حل می شن و من و شما فقط کافیه آپدیت کنیم. پس در روزهای آینده حواستون به آپدیت ها باشه منتظر آپدیت های زیاد باشین. همچنین اگر از سروری محافظت می کنین که به اینترنت وصل نیست، دردسرهای نسبتا زیادی منتظر شما خواهد بود چون آپدیت کردن این سیستم‌ها معمولا دردسره و در مواردی شاید نتونین به سادگی فقط glibc رو آپدیت کنین.
آیا من و شما در خطریم؟
در حالت معقول نه. کامپیوترهای ما به دی ان اس سرورهای بدجنس وصل نمی شن و اگر از لینوکس هایی به روز استفاده کنیم مشکل همین الان هم تا حدی برطرف شده و فقط در روزهای آینده باید آپدیت‌ها رو جدی بگیریم همچنین اندرویدها به جای glibc از بیونیک استفاده می کنن که این مشکل رو نداره و اکثر لینوکس های درونکار( امبدد؟ ) هم مشکلی نداره چون اکثرا uclibc هستن.
نکته باقیمانده
به سادگی در کامنت ها مطرح کنین و سعی می کنم در سطح سواد و وقت جواب بدم و بقیه رو هم می سپریم به دوستان باسوادتر در کامنت ها (:
