Вчера бе публикувана информация за уязвимост в ядрото на Linux и който вече е каталогизиран като CVE-2021-3609. Тази уязвимост позволява на локален потребител да повиши своите привилегии в системата поради състезателно състояние при изпълнението на протокола CAN BCM и проявено във версии 2.6.25 до 5.13-rc6 на ядрото на Linux.
Решението се възползва защото Протоколът CAN BCM ви позволява да регистрирате свой собствен мениджър на съобщения на областната мрежа на контролера (CAN) и го свържете към определен мрежов контакт. Когато пристигне входящо съобщение, се извиква функцията bcm_rx_handler () нападателят може да се възползва от състезателно състояние и да принуди мрежовия сокет да се затвори, докато изпълнява bcm_rx_handler ().
Проблемът идва, когато гнездото е затворено и функцията се извиква bcm_release (), в който се освобождава памет, разпределена за структури bcm_op и bcm_sock, които продължават да се използват в манипулатора bcm_rx_handler () който все още работи, като по този начин възниква ситуация, която води до достъп до вече освободен блок памет (use-after-free).
Това е съобщение за наскоро докладваната грешка (CVE-2021-3609) в мрежовия протокол CAN BCM в ядрото на Linux, варираща от версия 2.6.25 до основната линия 5.13-rc6.
Уязвимостта е състезателно условие в net / can / bcm.c, което позволява ескалация на привилегиите да се изкорени. Първоначално проблемът беше докладван от syzbot и Норберт Слусарек се оказа експлоатативен.
Атаката се свежда до отваряне на два CAN BCM сокета и обвързването им с интерфейса vcan. В първия конектор се обаждате sendmsg () с индикатора RX_SETUP за да конфигурирате контролера за входящи CAN съобщения и на втория конектор се обаждате sendmsg () за да изпратите съобщение до първия съединител.
След пристигане на съобщението, извикването bcm_rx_handler () се задейства и нападателят използва точния момент и затваря първия сокет, което води до стартирането на bcm_release () и пускането на структурите bcm_op и bcm_sock, въпреки че работата на bcm_rx_handler () все още не е завършен.
Чрез манипулиране на съдържанието на bcm_sock, нападателят може да замени показалеца към функцията sk-> sk_data_ready (sk), да пренасочи изпълнението и, използвайки техники за ориентирано към връщане програмиране (ROP), да замени параметъра modprobe_path и да накара кода му да работи като root .
Когато използва техниката ROP, нападателят не се опитва да постави своя код в памет на, но оперира парчетата от машинни инструкции вече са налични в заредени библиотеки, завършващи с контролен оператор за връщане (като правило това са краят на функциите на библиотеката).
Разрешенията, необходими за извършване на атака, могат да бъдат получени от непривилегирован потребител в контейнери, създадени в системи с активирани пространства от имена на потребители. Например потребителските пространства от имена са включени по подразбиране в Ubuntu и Fedora, но не са активирани в Debian и RHEL.
Опитът ми за експлойт се концентрира върху ядра с версия> = 5.4-rc1 от commit bf74aa86e111. Не съм изследвал експлоатацията на ядра, по-стари от 5.4-rc1, използвайки tasklets, но експлоатацията на по-стари ядра изглежда също осъществима.
Споменава се, че изследователят, който идентифицира уязвимостта, успя да подготви експлойт за придобиване на root права на системи с ядра от версия 5.4 и по-нови, включително възможността за успешна атака срещу Ubuntu 20.04.02 LTS.
Работата на експлоита се свежда до изграждане на верига от повиквания към подобни блокове („джаджи“), за да се получи необходимата функционалност. Атаката изисква достъп за създаване на CAN сокети и конфигуриран мрежов интерфейс vcan.
Накрая споменава се, че проблемът продължава да съществува за повечето дистрибуции, но е въпрос на дни, преди да бъдат освободени съответните кръпки.
Ако се интересувате да научите повече за това, можете да се консултирате следната връзка.