نقص ۱۵ ساله «گوست‌لاک» چگونه دسترسی روت و فرار از کانتینر را در لینوکس فراهم می‌کند؟

به مدت پانزده سال، یک نقص خاموش در اعماق هسته سیستم عامل لینوکس پنهان بود و منتظر فعال شدن می‌ماند. این آسیب‌پذیری که توسط محققان امنیتی کشف‌کننده آن «گوست‌لاک» (GhostLock) نامیده شده، یکی از مهم‌ترین تهدیدات علیه زیرساخت‌های رایانش ابری در سال‌های اخیر به شمار می‌رود. این باگ که امتیاز شدت تقریباً حداکثری ۹.۹ از ۱۰ را به خود اختصاص داده است، به مهاجمی با حداقل امتیازات اجازه می‌دهد تا کنترل کامل یک دستگاه را به دست گیرد و مهم‌تر از آن، از کانتینرهای نرم‌افزاری ایزوله خارج شود.

این کشف، واکنش گسترده و هماهنگی را در سراسر بخش فناوری برانگیخته است. از آنجایی که لینوکس زیربنای تقریباً ۸۰ درصد از کل سرورهای ابری عمومی است، پیامدهای یک فرار قابل اعتماد از کانتینر بسیار جدی است. در محیط‌های ابری مدرن، چندین مشتری در یک سرور فیزیکی مشترک هستند که تنها توسط مرزهای مجازی از هم جدا شده‌اند. گوست‌لاک یک کلید نظری برای دور زدن این مرزها فراهم می‌کند و یک رخنه محلی را به یک سازش سیستمی تبدیل می‌سازد.[3]

برای درک نحوه عملکرد گوست‌لاک، باید به چگونگی مدیریت دسترسی به فایل‌ها توسط هسته لینوکس نگاه کرد. هنگامی که چندین برنامه به طور همزمان تلاش می‌کنند یک فایل را بخوانند یا بنویسند، هسته از مکانیسمی به نام «قفل‌گذاری فایل» برای جلوگیری از خرابی داده‌ها استفاده می‌کند. گوست‌لاک از یک وضعیت رقابتی بسیار خاص در این مکانیسم، به ویژه در زیرسیستم `fs/locks.c`، سوء استفاده می‌کند. با غرق کردن هسته در درخواست‌های قفل همزمان، مهاجم می‌تواند مدیریت حافظه سیستم را دچار سردرگمی کند.

این سردرگمی سناریوی «استفاده پس از آزادسازی» (Use-After-Free) را ایجاد می‌کند. هسته به طور تصادفی بلوکی از حافظه را آزاد می‌کند که هنوز تصور می‌کند برای قفل‌گذاری فایل در حال استفاده است. سپس مهاجم به سرعت همان فضای حافظه را با دستورالعمل‌های مخرب خود دوباره تخصیص می‌دهد. هنگامی که هسته متعاقباً تلاش می‌کند قفل فایل اصلی را اجرا کند، در عوض کد مهاجم را با بالاترین امتیازات سیستمی ممکن – یعنی دسترسی روت – اجرا می‌کند.

در حالی که به دست آوردن دسترسی روت در یک دستگاه محلی خطرناک است، تهدید واقعی گوست‌لاک در توانایی آن برای تسهیل فرار از کانتینر نهفته است. کانتینرها، که توسط پلتفرم‌هایی مانند داکر و کوبرنتیس محبوب شده‌اند، برای سندباکس کردن برنامه‌ها و محدود کردن آنچه می‌توانند ببینند و انجام دهند، طراحی شده‌اند.

با این حال، از آنجایی که کانتینرها در هسته لینوکس زیرین سیستم میزبان مشترک هستند، یک بهره‌برداری در سطح هسته مانند گوست‌لاک به مهاجم اجازه می‌دهد تا به طور کامل سندباکس را دور بزند و وارد سیستم عامل میزبان شود.[1][3]

این آسیب‌پذیری در سال ۲۰۱۱ طی یک بهینه‌سازی روتین کد سیستم فایل معرفی شد. برای بیش از یک دهه، این نقص در معرض دید پنهان ماند و از ممیزی‌های امنیتی متعددی جان سالم به در برد.

این نقص تنها ماه گذشته توسط تیمی از محققان دانشگاهی با استفاده از تکنیک‌های پیشرفته «فازینگ» – تست نرم‌افزاری خودکار که حجم زیادی از داده‌های تصادفی را به سمت یک برنامه پرتاب می‌کند تا آن را مجبور به از کار افتادن کند – کشف شد. محققان پس از درک شدت باگ، فرآیند افشای محرمانه را آغاز کردند.[1]

این محرمانگی به توزیع‌های اصلی لینوکس و ارائه‌دهندگان خدمات ابری یک مزیت حیاتی داد. شرکت‌هایی مانند Red Hat و Canonical (سازنده اوبونتو) به صورت مخفیانه برای توسعه و آزمایش وصله‌ها کار کردند. به طور همزمان، ارائه‌دهندگان بزرگ زیرساخت ابری، از جمله خدمات وب آمازون (AWS)، اقدامات کاهشی در سطح هایپروایزر را برای محافظت از خدمات مدیریت شده خود قبل از عمومی شدن آسیب‌پذیری اعمال کردند و اطمینان حاصل کردند که ماشین‌های میزبان زیرین از فعالیت‌های مخرب کانتینر محافظت می‌شوند.[2]

با وجود این اقدامات پیشگیرانه، اکنون بار وصله‌گذاری میلیون‌ها سرور خودمدیریتی بر دوش تیم‌های فناوری اطلاعات سازمانی افتاده است. وصله‌گذاری آسیب‌پذیری هسته به طور سنتی نیازمند راه‌اندازی مجدد سیستم است، که برای خدماتی که به آپتایم ۲۴/۷ نیاز دارند، یک کابوس لجستیکی است. در نتیجه، بسیاری از سازمان‌ها به فناوری‌های وصله‌گذاری زنده روی آورده‌اند که اصلاحیه را مستقیماً به حافظه هسته در حال اجرا تزریق می‌کنند و نیازی به راه‌اندازی مجدد ندارند، و زمان لازم برای پنجره‌های نگهداری برنامه‌ریزی شده را فراهم می‌کنند.[2]

در حال حاضر، هیچ مدرکی مبنی بر اینکه گوست‌لاک توسط بازیگران مخرب در فضای عمومی مورد بهره‌برداری قرار گرفته باشد، وجود ندارد. با این حال، ظرف چند ساعت پس از افشای عمومی، کد بهره‌برداری اثبات مفهوم در انجمن‌های امنیتی شروع به گردش کرد.

این امر یک ساعت شنی را برای مدیران سیستم به کار انداخته است. تاریخ نشان می‌دهد که باندهای باج‌افزاری و هکرهای تحت حمایت دولت به سرعت چنین بهره‌برداری‌های با ارزشی را در جعبه ابزار خود ادغام می‌کنند و اغلب ظرف چند روز پس از انتشار، اینترنت را برای یافتن سیستم‌های وصله‌نشده اسکن می‌کنند.

حادثه گوست‌لاک بحث دیرینه‌ای را در جامعه مهندسی نرم‌افزار در مورد ایمنی حافظه دوباره شعله‌ور کرده است. از آنجایی که هسته لینوکس با زبان C نوشته شده است – زبانی که توسعه‌دهندگان را ملزم به مدیریت دستی حافظه می‌کند – ذاتاً مستعد باگ‌های Use-After-Free و وضعیت‌های رقابتی است. این آسیب‌پذیری مهمات قدرتمندی را برای طرفدارانی فراهم می‌کند که برای بازنویسی زیرسیستم‌های حیاتی هسته در Rust، یک زبان مدرن که ایمنی حافظه را به صورت طراحی تضمین می‌کند، فشار می‌آورند.[1]

همچنین این حادثه نظریه «چشمان زیاد» در نرم‌افزار متن‌باز را به چالش می‌کشد، که فرض می‌کند عمومی کردن کد منبع تضمین می‌کند که باگ‌ها به سرعت پیدا و رفع می‌شوند. همانطور که گوست‌لاک نشان می‌دهد، وضعیت‌های رقابتی بسیار پیچیده و عمیقاً پنهان می‌توانند برای بیش از یک دهه از بررسی انسانی فرار کنند. کارشناسان امنیتی استدلال می‌کنند که اکوسیستم نیاز کمتری به بررسی دستی کد و سرمایه‌گذاری بیشتری در زیرساخت‌های فازینگ خودکار و مستمر دارد که توسط غول‌های فناوری که از لینوکس سود می‌برند، تأمین مالی شود.[1][3]

در حال حاضر، تمرکز فوری بر روی اصلاح و ترمیم باقی مانده است. جامعه امنیت سایبری برای ارائه راهنمایی‌های واضح و عملی بسیج شده است و ابزارهای اسکن را برای کمک به سازمان‌ها در شناسایی نسخه‌های آسیب‌پذیر هسته در سراسر ناوگان خود منتشر کرده است. در حالی که گوست‌لاک نشان‌دهنده یک شکست معماری جدی است، پاسخ هماهنگ و در سطح صنعت، انعطاف‌پذیری و بلوغ دستگاه امنیتی متن‌باز مدرن را برجسته می‌کند.

در نهایت، گوست‌لاک به عنوان یک مطالعه موردی درسی هم در مورد شکنندگی زیرساخت‌های مشترک و هم در مورد مکانیسم‌های افشای آسیب‌پذیری مدرن عمل خواهد کرد. با درک مکانیسم دقیق این نقص، متخصصان فناوری اطلاعات بهتر مجهز می‌شوند تا نه تنها وصله فعلی را اعمال کنند، بلکه محیط‌های ابری مقاوم‌تر و با دفاع عمیق‌تری را طراحی کنند که بتوانند در برابر روز صفر هسته‌ای اجتناب‌ناپذیر بعدی مقاومت کنند.[3]