Glibc شامل اصلاحی برای آسیب‌پذیری memcpy است که توسط توسعه‌دهندگان سیستم عامل Aurora OS تهیه شده است

توسعه دهندگان سیستم عامل موبایل Aurora (چنگال سیستم عامل Sailfish که توسط شرکت Open Mobile Platform توسعه یافته است) داستانی افشاگرانه در مورد حذف به اشتراک گذاشتند. آسیب پذیری بحرانی (CVE-2020-6096) در Glibc که فقط در پلتفرم ARMv7 ظاهر می شود. اطلاعات مربوط به این آسیب‌پذیری در ماه مه فاش شد، اما تا روزهای اخیر، با وجود آسیب‌پذیری‌ها، اصلاحاتی در دسترس نبود. اختصاص داده سطح بالایی از خطر است و یک نمونه اولیه از یک اکسپلویت وجود دارد که به شما امکان می دهد هنگام پردازش داده های فرمت شده به روش خاصی در توابع memcpy() و memmove() اجرای کد را سازماندهی کنید. رفع بسته برای دبیان и اوبونتو هنوز منتشر نشده اند و این آسیب پذیری تقریباً دو ماه از لحظه افشای عمومی و پنج ماه از لحظه اطلاع به توسعه دهندگان Glibc رفع نشده باقی می ماند.

این آسیب‌پذیری خود را در پیاده‌سازی memcpy() و memmove() در زبان اسمبلی برای ARMv7 نشان داد و ناشی از پردازش نادرست مقادیر منفی پارامتری است که اندازه منطقه کپی شده را تعیین می‌کند. مشکلات توسعه وصله زمانی شروع شد که شرکت ها سوس и ردهت اعلام کرد که پلتفرم‌های آنها تحت تأثیر این مشکل قرار نگرفته است، زیرا آنها برای سیستم‌های ARMv32 7 بیتی نمی‌سازند و در ایجاد یک اصلاح شرکت نکرده‌اند. به نظر می رسد توسعه دهندگان بسیاری از توزیع های جاسازی شده به تیم Glibc متکی بوده اند، و همچنین به طور فعال در آماده سازی رفع مشکل شرکت نکرده اند.

گزینه پچ برای جلوگیری از این مشکل، هواوی تقریباً بلافاصله پیشنهاد کرد که سعی کند دستورالعمل‌های مونتاژی که با عملوندهای امضا شده (bge و blt) کار می‌کنند را با آنالوگ‌های بدون علامت (blo و bhs) جایگزین کند. نگهبانان Glibc مجموعه‌ای از آزمایش‌ها را برای بررسی شرایط خطای مختلف ایجاد کردند، پس از آن مشخص شد که وصله هواوی مناسب نیست و همه ترکیب‌های ممکن از داده‌های ورودی را پردازش نمی‌کند.

از آنجایی که سیستم عامل Aurora یک ساخت 32 بیتی برای ARM دارد، توسعه دهندگان آن تصمیم گرفتند این آسیب پذیری را خودشان ببندند و راه حلی را به جامعه ارائه دهند. مشکل این بود که نوشتن یک پیاده سازی کارآمد به زبان اسمبلی برای تابع و در نظر گرفتن گزینه های مختلف برای آرگومان های ورودی ضروری بود. پیاده سازی با استفاده از دستورالعمل های بدون امضا بازنویسی شده است. پچ معلوم شد که کوچک است، اما مشکل اصلی حفظ سرعت اجرا و جلوگیری از کاهش عملکرد توابع memcpy و memmove، در حالی که سازگاری با تمام ترکیب‌های مقادیر ورودی را حفظ می‌کند.

در ابتدای ماه ژوئن، دو نسخه از اصلاح آماده شد، که چارچوب آزمایشی نگهدارنده‌های Glibc و مجموعه آزمایشی داخلی Aurora را پشت سر گذاشت. در 3 ژوئن یکی از گزینه ها انتخاب شد و ارسال شد به لیست پستی Glibc. یک هفته بعد
بود پیشنهادی یکی دیگر از وصله‌های مشابه در رویکرد، که مشکلی را در پیاده‌سازی multiarch که هوآوی قبلاً سعی کرده بود آن را برطرف کند، اصلاح کرد. آزمایش یک ماه طول کشید و ثبت قانونی به دلیل اهمیت پچ
اصلاحات 8 جولای پذیرفته شدند به شعبه اصلی نسخه آینده glibc 2.32. پیاده سازی شامل دو وصله - است первый برای اجرای multiarch از memcpy برای ARMv7 و دوم برای پیاده سازی زبان اسمبلی عمومی memcpy() و memmove() برای ARM.

این مشکل میلیون‌ها دستگاه ARMv7 را تحت تأثیر لینوکس قرار می‌دهد و بدون به‌روزرسانی مناسب، مالکان هنگام اتصال آنها به شبکه در معرض خطر قرار می‌گیرند (سرویس‌ها و برنامه‌های قابل دسترسی شبکه که داده‌های ورودی را بدون محدودیت اندازه می‌پذیرند می‌توانند مورد حمله قرار گیرند). به عنوان مثال، اکسپلویت تهیه شده توسط محققانی که آسیب پذیری را شناسایی کرده اند، نشان می دهد که چگونه می توان با ارسال یک درخواست GET بسیار بزرگ، به سرور HTTP تعبیه شده در سیستم اطلاعات خودرو حمله کرد و به سیستم دسترسی ریشه داشت.

منبع: opennet.ru