Уязвимост в io_uring позволи на потребител без разрешения да стане root дори в контейнери

наскоро разкрита информация за уязвимостта (CVE-2022-29582) в реализацията на асинхронния I/O интерфейс io_uring, включен в ядрото на Linux от версия 5.1, който позволява на непривилегирован потребител да стане root на системата, дори когато изпълнява експлойт на контейнер.

Струва си да се спомене това споменатата уязвимост е докладвана преди малко повече от 3 месеца (приблизително началото на май тази година), но пълна информация и разкриване бяха публикувани едва наскоро.

По отношение на уязвимостта се споменава, че това възниква при достъп до вече освободен блок памет, се проявява в ядрата на Linux, започвайки с клона 5.10.

Относно уязвимостта CVE-2022-29582

Тази уязвимост позволява достъп до освободената памет в резултат на състояние на състезание при обработка на изчаквания във функцията io_flush_timeouts(), коятоe премахва записа за изчакване от списъка и го анулира, без да проверява създаването и изтриването на таймаута в този момент.

Актуализирано общо описание на io_uring вече е предоставено от други. Те го обясняват хиляди пъти по-добре от нас, така че ние просто ще покрием подсистемата по-обстойно (вижте тази статия за Grapl Security и тази статия за Flatt Security за страхотно въведение).

което е по-важно, полето на операционния код определя какъв тип операция да се извърши. За всеки "opcode", който го изисква, полето fd указва файловия дескриптор, върху който да се изпълни исканият I/O. Почти всички нормални I/O системни повиквания (четене, изпращане и т.н.) имат еквивалентен асинхронен код на операцията. Всяко поле може да поеме различни роли в зависимост от операцията.

След като бъде извлечен от SQ, SQE се преобразува във вътрешно представяне, описано от struct io_kiocb( обратно извикване на вход/изход на ядрото). Тези обекти са известни като заявки.

struct io_kiocb се използва като еквивалент на SQE "готов за стартиране", на който се основава, при което всеки файлов дескриптор се разрешава да структурира file*s, потребителски идентификационни данни са прикачени, личност (в кои ядра ще работят) и т.н. .

След като заявената операция приключи, тя се записва в опашката за завършване (CQ) запис, който съответства на SQE. Такъв запис се нарича запис на опашка за завършване (CQE) и съдържа полета като код на грешка и резултатна стойност. Приложението за потребителско пространство може да запитва CQ за нови записи, за да определи дали изпратените SQE са завършили обработката и какъв е техният резултат.

Споменава се, че има някои сценарии, при които е лесно да се замени обект върху напредъка. Но има две ограничения:

  • LT' трябва да се присвои и инициализира в прозорец на състезание. Тоест след освобождаване на LT, но преди достигане на точка в LT, до която вече няма достъп.
  • LT' може да бъде само друг struct io_kiocb обект. Поради изолацията на купчината, където обектите в купчината са разделени според техния тип, е твърде трудно да ги преназначите като различен тип обект в прозореца на състезанието.

Изследователите са подготвили функционален експлойт което не изисква включването на пространства от имена на потребителски идентификатор (потребителски пространства от имена) за своята работа и може да осигури root достъп до хоста, когато непривилегирован потребител стартира експлойта в изолиран контейнер.

Нашият експлойт е насочен към версия на ядрото 5.10.90, версията, която Google стартира дистанционно по това време. Трябваше да адаптираме нашия експлойт към конкретните спецификации на сървъра (4 ядра Skylake Xeon @ 2.80 Ghz, 16 GiB RAM), но с някои настройки всяка машина, работеща с уязвимо ядро, трябва да може да се използва.

Експлойтът работи и в средата nsjail изолиран в Google COS (Оптимизирана за контейнери OS) дистрибуция, базирана на Chromium OS и използвана в Google Cloud Platform на виртуални машини Compute Engine. Експлойтът е проектиран да работи с клонове на ядрото от 5.10 до 5.12. И накрая, струва си да се спомене, че проблемът е коригиран през април в актуализации 5.10.111, 5.15.34 и 5.17.3.

И накрая, ако се интересувате да научите повече за уязвимостта, можете да се консултирате с направената публикация В следващия линк.


Оставете вашия коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *

*

*

  1. Отговорник за данните: AB Internet Networks 2008 SL
  2. Предназначение на данните: Контрол на СПАМ, управление на коментари.
  3. Легитимация: Вашето съгласие
  4. Съобщаване на данните: Данните няма да бъдат съобщени на трети страни, освен по законово задължение.
  5. Съхранение на данни: База данни, хоствана от Occentus Networks (ЕС)
  6. Права: По всяко време можете да ограничите, възстановите и изтриете информацията си.