Линус Торвальдс приеха документ в ядрото, който регламентира процеса на обработка на грешки, свързани със сигурността, определя модел на заплахи, пояснява кои грешки в ядрото се трактоват като уязвимости и разглежда действията с грешки, открити с помощта на AI. Документът е подготвен от Вили Тарро (Willy Tarreau), автор на HAProxy и дългогодишен разработчик на Linux ядрото, който е отговарял за поддръжката на няколко стабилни клона на ядрото. За основа са използвани споразуменията, постигнати в хода на обсъждането на наскоро откритите критични уязвимости в ядрото (1, 2, 3, 4), разкрити преди публикуването на поправките и за които, благодарение на AI, веднага е било възможно да се създадат работещи експлойти.
Основната част от свързаните с безопасността грешки трябва да се обработва публично, за да се привлече максимално широка аудитория и да се намери оптимално решение. В отделен частен списък за разпространение предлагат да се изпращат само спешни съобщения за уязвимости, лесно експлоатируеми, представляващи заплаха за много потребители и позволяващи получаване на разширени привилегии или възможности.
Уязвимостите, открити с помощта на AI-асистенти, винаги се предлагат да бъдат обсъждани публично, тъй като подобни проблеми често се откриват едновременно от няколко изследователи. При това не трябва да се разкрива експлоит в отчета — достатъчно е да се спомене, че той е наличен, и да се предаде в частен порядък в отговор на запитване от поддръжката.
Отделно се описват правилата за предаване на отчети, създадени с помощта на AI-асистенти. Тези отчети се изпращат в голямо количество и благодарение на тях понякога се откриват грешки в слабо прегледани части от кода, но поддръжката често ги игнорира заради ниското качество и неточностите. Основните изисквания към отчетите, създадени с участието на AI, са:
- Краткост, без излишества и с посочване на същността и важните детайли в самото начало.
- Само чист текст без Markdown тагове и декорации.
- Разбиране на модела на заплахи и указание на проверяваните факти (например, „грешката позволява на всеки потребител да получи CAP_NET_ADMIN“), а не теоретични размишления и догадки за последствията от уязвимостта.
- Преди да изпратите отчета, уверете се, че е тестван задълбочено експлоита, създаден чрез AI, и че проблемът може да бъде възпроизведен.
- Ангажиране на AI за разработване и тестване на корекции на идентифициран проблем.
Според статистиката на поддръжката, повечето отчети за грешки, изпратени като поправки на уязвимости, не са действителни и трябва да се обработват по същия начин като обикновените грешки. За разграничаване на уязвимостите и обикновените грешки е описана модел на заплахите на ядрото на Linux. Сред възможностите и гаранциите, нарушението на които може да се счита за уязвимост:
- Изолация на ниво потребители: достъп до файловете само за собственика, паметта на процеса е недостъпна за другите потребители, ptrace е забранен за чужди процеси, изолация на IPC и мрежови комуникации.
- Защита на базата на capabilities: без CAP_SYS_ADMIN не може да се промени конфигурацията на ядрото, паметта, състоянието на системата; без CAP_NET_ADMIN не може да се променят мрежовите настройки или да се прихваща трафик; без CAP_SYS_PTRACE не може да се проследяват процесите на други потребители.
- Пространството на имена на идентификаторите на потребителите (CONFIG_USER_NS) позволява на непривилегированите потребители да създават свои изолирани среди, от които не може да се влияе на глобалното пространство на имена, например, да променят времето, да зареждат модули или да монтират блочни устройства.
- Отладъчните интерфейси (/proc/kmsg, perf, debugfs), чрез които може да се получи достъп до конфиденциална информация, са достъпни само след явно предоставяне на достъп от администратора.
Възможности, които не се считат за уязвимости:
- Използване на остарели версии на ядрото.
- Сглобяване с активиране на опции за разработчици или снижаващи сигурността (например, CONFIG_NOMMU).
- Определяне на небезопасни настройки sysctl, опции на командния ред, права за достъп в FS, capabilities или отваряне на достъп до привилегировани интерфейси за непривилегировани потребители (например, достъп за запис в procfs и debugfs).
- Проблеми в функции, предназначени само за разработка и отстраняване на грешки в ядрото, като LOCKDEP, KASAN и FAULT_INJECTION, които не са предназначени за включване в работни конфигурации.
- Проблеми с драйвери, модули и подсистеми, присъстващи в секция STAGING или обозначени като експериментални, небезопасни или неработещи.
- Използване на външни модули на ядрото или неофициални клонове на ядрото.
- Изискване за излишни привилегии, като необходимост от извършване на действия с права root или от потребител с права CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO и CAP_SYS_MODULE.
- Теоретични атаки, изискващи лабораторни условия, милиарди опити, емуляция или модификация на оборудване, несъразмерни разходи и нереалистични конфигурации (например, системи с десетки хиляди ядра CPU).
- Заобикаляне на защитни механизми (например, ASLR) без демонстрация на експлойт. Липса на проверки на аргументи и кодове на грешки без явни последствия.
- Случайни изтичания на информация, неконтролирани от атакуващите, като остатъчни данни в съобщения за грешки и изтичания на адреси/указатели на паметта на ядрото без пряка възможност за експлоатация.
- Грешки при монтиране на повредени дискови образи, ако драйверът не е заявен като годен за употреба с ненадеждни носители. Проблеми с дискови образи, открити и отстранени чрез стартиране на утилита fsck.
- Атаки, изискващи физически достъп до оборудването, модификация на оборудването или свързване на хардуерни устройства, като платки за атака на DMA и логически анализатори, ако системата не е специално конфигурирана за защита от подобни атаки (IOMMU).
- Регресии с функционалността и производителността, отстраняеми чрез настройка на права и лимити.
Източник: opennet.ru
