اکثر سرورهای روی سیاره در برابر این نقص اجرای کد میان‌افزار آسیب‌پذیر هستند

این آسیب‌پذیری با رتبه‌بندی 9.5 از 10، در TianoCore EDK II قرار دارد، یک پایگاه کد منبع باز که سازندگان سخت‌افزار و ارائه‌دهندگان ابر از آن برای ایجاد میان‌افزار UEFI استفاده می‌کنند که در طول دنباله راه‌اندازی اجرا می‌شود. سال گذشته، یکی از نمایندگان انجمن UEFI EDK2 را "راه حل برجسته / اجرای مشخصات UEFI" نامید. تقریبا همه تأمین‌کنندگان UEFI (گاهی اوقات هنوز IBV یا فروشنده‌های مستقل بایوس نامیده می‌شوند)، از جمله AMI، Insyde، و Phoenix، به طور گسترده از کد مرجع استفاده می‌کنند.

Project Mu، چنگال سخت شده EDK2 مایکروسافت، از کد حاوی مؤلفه آسیب‌پذیر نیز استفاده کرد. این آسیب‌پذیری که به‌عنوان CVE-2026-97631 ردیابی می‌شود، یک نقص خرابی حافظه در یک مؤلفه ICMP است که مهاجمان می‌توانند از آن برای اجرای کدهای مخربی که قبل از اجرای سیستم‌عامل و سیستم‌عامل‌ها اجرا می‌شود، استفاده کنند، مانند Secure Boot، که زنجیره‌ای از اعتماد را برای همه کدها، از جمله Trusted Platform Module (Trusted Platform Boot) (در طول BootT) اجرا می‌کند.

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

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

خبر این آسیب‌پذیری شش روز پس از افشای نادرست دیگری منتشر می‌شود، این آسیب‌پذیری شامل یک آسیب‌پذیری حیاتی اجرای کد در زبان برنامه‌نویسی PHP است. اچ‌دی مور، خالق Metasploit و مدیر ارشد تحقیقاتی شرکت امنیتی Dragos، گفت: «این آسیب‌پذیری در تجزیه‌کننده ICMP پشته شبکه EDK2 از نظر نحوه تأثیرگذاری بر زنجیره اعتماد و اکوسیستم گسترده‌تر جالب است.

"یک مهاجم که قصد به خطر انداختن یک نقطه پایانی یا سرور نزدیک را دارد، می‌تواند از این باگ برای ربودن جریان برنامه در نقطه‌ای استفاده کند که فرآیند بوت هنوز به اجزای حساس مانند TPM نقطه پایانی دسترسی دارد. این می‌تواند برای شکستن رمزگذاری دیسک برای مواردی که مهاجم دسترسی کوتاه‌مدت به شبکه دارد (و در سناریوی سرقت حتی ساده‌تر است) استفاده کند. CVE-2026-97631 یک سرریز بافر 16 ساله در درایور PXE-Base Code (NetworkPkg/UefiPxeBcDxe) است که مسئول اجازه دادن به سرورها، تجهیزات ذخیره سازی و سایر دستگاه ها برای بوت شدن با استفاده از کد دانلود شده از یک شبکه محلی است.

در طول این فرآیند - که به عنوان بوت محیط پیش از اجرا شناخته می شود - راننده از شنونده شبکه برای نظارت بر خطاهای ICMP استفاده می کند. از آنجایی که درایور محدودیت کپی حافظه 504 بایت را اعمال نمی کند، بازنویسی داده های مجاور، یک خودی مخرب یا هکری که دسترسی سطح پایین به یک شبکه محلی را به دست آورده است می تواند یک پیام خطایی ارسال کند که کدی را بیش از این محدودیت اضافه می کند. سپس ماژول IUEFI که روی CPU اجرا می شود خراب می شود. همانطور که مشاوره رسمی می گوید:

در طول راه‌اندازی شبکه، درایور کد پایه PXE (NetworkPkg/UefiPxeBcDxe) یک درخواست دریافت را برای پیام‌های خطای ICMP باز نگه می‌دارد و هر پیام دریافتی را در فیلد ثابت 504 بایتی Mode.IcmpError ساختار بافت خصوصی خود کپی می‌کند. کنترل کرانه‌های حلقه کپی در هر دو کنترل‌کننده IPv4 و IPv6 نادرست است (PxeBcIcmpErrorDpcHandle و PxeBcIcmp6ErrorDpcHandle): برای پیامی بیشتر از 504 بایت، همچنان بایت‌ها را در فیلد کپی می‌کند، و نشانگر مقصد را به ازای نوشتن با طول مولتی‌فره پیغام پیش می‌برد. بایت های کنترل شده توسط مهاجم p

در سمت میدان هیچ چیز قبلی در مسیر دریافت، طول پیام را محدود نمی کند.

خطای مخرب را می توان از طریق یک یونیکست ساده که از هر فاصله شبکه به آدرس IP دستگاه مورد نظر ارسال می شود، تا زمانی که در طول توالی بوت PXE ارسال شود، تحویل داده شود. یک مهاجم می تواند با هنگ کردن دنباله بوت، انکار سرویس را ارائه دهد. هنگامی که مهاجم بداند ساخت سیستم عامل هدف چیست، می تواند یک "رویداد تقلبی" ایجاد کند که کد مخرب را روی CPU در محیط سیستم عامل UEFI خود اجرا می کند. کد در حلقه 0 اجرا می‌شود، که ممتازترین سطح اجرای CPU است.

از آنجایی که اکسپلویت‌ها فرآیندهای تأیید را دور می‌زنند تا از نظر رمزنگاری به سرورهای راه دور ثابت کنند که سخت‌افزار امن است، فرصتی کلیدی برای افزایش امتیازات محدود ارائه می‌دهند. یک روز دیگر برای همیشه CVE-2026-97631 به لیست طولانی از آسیب پذیری های قبلا کشف شده در UEFI یا کدهایی می پیوندد که از نزدیک با آن کار می کنند. شدیدترین آنها، LogoFail، از تصاویر لوگوی موجود در UEFI تقریبا هر سخت افزاری ناشی می شود.

رندر کردن اشکالات به مهاجمان این امکان را می‌دهد تا زنجیره اعتمادی که UEFI اعمال می‌کند را زیر سوال ببرند و قبل از بارگیری سیستم‌عامل یا اجرای Secure Boot به نصب اجزای مخرب ادامه دهند. PixieFail یک آسیب پذیری مشابه CVE-2026-97631 بود. این نیز نتیجه نقص بوت PXE معیوب در EDK2 بود. پس از کشف این آسیب‌پذیری، محققان پروژه‌های فازی متعددی را آغاز کردند که برای آشکار کردن سایر نقص‌های حیاتی در کتابخانه کد منبع باز طراحی شده بودند. به نظر می رسد این تلاش ها برای یافتن این آخرین نقص شکست خورده است. سایر نقص های اخیرا کشف شده UEFI عبارتند از:

PKFail، یک شکست زنجیره تامین ناشی از کلیدهای پلتفرم آزمایشی غیر تولیدی، عمومی برای بیش از یک دهه قبل از کشف، در صدها مدل دستگاه استفاده می‌شود. BootHole; بوت کیت؛ و بلک لوتوس.

مانند CVE-2026-97631، بهره برداری یا استفاده از این محموله ها جذاب است زیرا به مهاجمان اجازه می دهد تا ماشین ها را در مراحل اولیه بوت، قبل از بارگیری TPM و سایر سیستم های دفاعی آلوده کنند، بنابراین می توانند حداکثر آسیب را وارد کنند. با توجه به فراگیر بودن CVE-2026-97631، مور گفت که احتمالا این یک باگ «ابدی» است که در سیستم‌های پشتیبانی پایانی زنده خواهد ماند. اخطارها و محدودیت های مهمی برای بهره برداری از این آسیب پذیری اخیر وجود دارد. همانطور که اشاره شد، سطحی از کنترل بر روی یک شبکه محلی یک پیش نیاز است.

این احتمالا بهره‌برداری را برای خودی‌ها یا مهاجمان محدود می‌کند، مانند دولت‌های ملی یا اپراتورهای باج‌افزار، که می‌توانند دسترسی سطح پایین را در داخل شبکه به دست آورند و به دنبال راهی برای ارتقای حقوق سیستم هستند. هنوز هیچ مدرکی مبنی بر اینکه CVE-2026-97631 یک نقطه ورود اولیه به شبکه را فراهم می کند وجود ندارد. موانع دیگری برای رفع وجود دارد. برای بهره‌برداری از خود آسیب‌پذیری، مهاجم باید آدرس‌های خاصی را در سیستم هدف حدس بزند، بنابراین این چیزی نیست که بتوانید یک اکسپلویت را در هر هدفی پرتاب کنید و RCE را در طیف متنوعی از دستگاه‌ها دریافت کنید، اما باید به راحتی تنظیم شود.

جسی مایکل، محقق اصلی شرکت امنیتی سفت‌افزار Eclypsium، به Ars گفت: مدل/نسخه/پیکربندی هدف ch زیرا آدرس‌ها بر اساس آن‌ها تغییر خواهند کرد. برخلاف برخی از آسیب‌پذیری‌های پرمخاطب قبلی مانند BootHole، Black Lotus، و Baton Drop، این آسیب‌پذیری را می‌توان با یک اصلاح کد اساسی برطرف کرد، که مستلزم استقرار به‌روزرسانی BIOS/UEFI است، اما آنها نیازی به ابطال، pk/kek/db/dbx یا به‌روزرسانی‌های مدیریت کلیدهای Secure و Secure برای به‌روزرسانی‌هایی مانند OS ندارند. بوت در خود بوت لودر دور می زند." CVE-2026-97631

بر روی کاربران خانگی و اداری کوچک یا هر کاربر دیگری که دستگاه خود را صرفا از درایو دیسک بوت می کند، تأثیر می گذارد. در عوض، فقط برای سازمان‌هایی اعمال می‌شود که ماشین‌هایی دارند که از شبکه‌های محلی یا احتمالا از منابع متصل به اینترنت بوت می‌شوند. حتی پس از آن، سفت‌افزار هدف باید بر خلاف پیاده‌سازی مرجع متفاوت، بر EDK2 تکیه کند و از عملکرد PXE (که به طور پیش‌فرض روشن است) استفاده کند. اینتل در ایمیلی اعلام کرد که هیچ یک از «محصولات تجاری آن که در حال حاضر تحت پشتیبانی امنیتی هستند» تحت تأثیر قرار نگرفته است.

این شرکت افزود: «اینتل عملکرد EDK2 آسیب‌دیده را در کد مرجع خود لحاظ نمی‌کند، اگرچه ممکن است توسط یک فروشنده برد OEM یا سازنده سیستم یکپارچه شده باشد». این به مشتریان توصیه کرد که برای راهنمایی های خاص با سازنده سیستم خود مشورت کنند. با این حال، کد مرجع اینتل در دسترس عموم، به EDK2 اشاره می کند.

علاوه بر این، TianoCore گفته است که هر کیت توسعه UEFI ارائه شده توسط اینتل «یک پیاده‌سازی کاملا تأیید شده برای یک تجدیدنظر خاص از منبع EDK II است». بسیاری از اسناد دیگر اینتل به EDK2 نیز اشاره دارند. در همین حال، Arm به لیستی از سؤالات پاسخ داد: "CVE-2026-97631 مستقیما برای سبد محصولات Arm's قابل اجرا نیست." مانند اینتل، سفت‌افزاری که این شرکت در دسترس قرار می‌دهد نیز به‌شدت از EDK2 قرض می‌گیرد.

TianoCore همچنین اتکای Arm به EDK2 را مستند کرده است. در حالی که ممکن است برخی از پلتفرم‌ها فاقد کد EDK2 باشند، برای کاربران همه سرورها محتاطانه است که بررسی کنند آیا CVE-2026-97631 روی آنها تأثیر می‌گذارد یا خیر. سوالات ارسال شده به AMD، Phoenix Technologies، AMI، مایکروسافت و آمازون - احتمالا برخی از بزرگترین سازمان های دیگر تحت تأثیر قرار گرفته اند - وقتی این پست منتشر شد، بی پاسخ ماند. بدون پاسخ دقیق به سؤالات مربوط به استفاده از EDK2 توسط سازمان‌هایی مانند این، نمی‌توان گفت که چه دستگاه‌ها یا چگونه تحت تأثیر قرار می‌گیرند و این سازمان‌ها یا کاربران آن‌ها، در صورت وجود، چه اقداماتی باید انجام دهند.

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

پیکربندی‌های میان‌افزار همیشه باید ویژگی‌های امنیتی مانند TPM و Secure Boot را در صورت امکان فعال کنند، اگرچه این دفاع‌ها در برابر این تهدید خاص محافظت نمی‌کنند. همچنین نظارت بر گزارش‌ها برای نشانه‌هایی از تلاش‌های بهره‌برداری، ایده خوبی است. این داستان در اصل در Ars Technica ظاهر شد.