Модел на заплахи и особености при оценката на уязвимостите в ядрото на Linux

Линус Торвальдс е приел документ в ядрото, който регламентира процеса на обработка на грешки, свързани със сигурността, определяйки модела на заплахите и обяснявайки какви грешки в ядрото се тълкуват като уязвимости, както и действията около грешките, открити с помощта на 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) позволява на неп privelegировани потребители да създават свои изолирани среди, от които не може да се влияе на глобалното пространство, например, да се променя времето, да се зареждат модули и да се монтират блокови устройства.
• Отладъчни интерфейси (/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