CVE-2022-37706-LPE-exploit

## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-MAHERAZZOUZI-CVE-2022-37706-LPE-EXPLOIT
**CVE-2022-37706**  
  
![CVE-2022-37706-poc-zoom](https://assets.kitploit.com/production/public/readmes/37783/dddc4ec99bb220f39f25dee2ea130fdc65ee9d42c219f6710332e8daf04f463c.gif)

Привет, ребята, на этот раз я расскажу о недавнем 0-day, который я нашел в одном из  
основных оконных менеджеров Linux под названием Enlightenment (https://www.enlightenment.org/).  
Этот 0-day мгновенно и очень легко повышает привилегии любого пользователя до root.  
Эксплойт протестирован на Ubuntu 22.04, но должен работать на любом дистрибутиве.  


Прежде всего, Enlightenment — это оконный менеджер, композитор и минимальное рабочее окружение  
для Linux (основная платформа), BSD и любых других совместимых UNIX-систем.  


Я установил этот оконный менеджер, чтобы немного поэкспериментировать с ним. Мне было интересно,  
так как он содержит множество инструментов и выглядит довольно аккуратно, честно говоря.  


После установки пакета с помощью `apt install enlightenment` я изучил  
установленные файлы и каталоги в моей системе: множество модулей и множество вспомогательных  
бинарников, но самое интересное — это:  


root@kitploit:~
    
    
    ➜  enlightenment cd /usr/lib/x86_64-linux-gnu/enlightenment/
    ➜  enlightenment find . -perm -4000                         
    ./utils/enlightenment_ckpasswd
    ./utils/enlightenment_system
    ./utils/enlightenment_sys
    

Он устанавливает несколько SUID-бинарников, и я подумал, смогу ли я использовать один из них  
для повышения привилегий до root. Все бинарники выглядели безопасными и хорошо написанными.  
Бинарник, о котором мы будем говорить, — это enlightenment_sys.  


Как и в любой другой цели, мы выбираем стратегию после предварительной оценки  
(см. мой блог, если еще не: https://pwn-maher.blogspot.com/2020/10/vulnerability-assessment.html).  


Я провел аудит кода по нисходящему подходу.  
И поскольку этот оконный менеджер с открытым исходным кодом, исходный код доступен  
для всех этих бинарников и модулей.  
Поэтому первым делом я выполнил `apt source enlightenment`, чтобы получить весь исходный код,  
и, немного покопавшись, мы можем добраться до кода целевого бинарника.  


Но для отладки бинарника я загрузил его в Ghidra для анализа и получения адресов  
для установки точек останова и всего прочего.  
Символов при первой попытке не нашлось, но они и не нужны, так как бинарник  
оказался относительно небольшим.  
Удивительно, но мне было гораздо приятнее смотреть на декомпилированный псевдокод  
Ghidra, чем напрямую на исходники (избегая макросов и проверок на  
используемую ОС для компиляции определенного блока кода).  


Итак, начнем анализ.  


1- Играем с бинарником.  
Запустим файл, чтобы получить некоторую информацию о нашей цели:  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/fec14572b685ca069a34aca6c6d7eeae30c93eb15341ad6bd15fc4a8f934962c.png)  


Запуск бинарника не дает никакого вывода:  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/56167830f4efde62077f66dc61dd35052caf82e1091191353a849f4b91f954a3.png)  


Аргумент --help дал такой вывод:  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/ad895956ec7f69c47915ada13b9b57ac1d0194a478995581681e3c68a89fef79.png)  
Извините, я использую его, чтобы получить root.  


Далее просто выполним strace и посмотрим, использует ли он какие-либо подозрительные системные вызовы, например  
execve или openat:  
strace ./enlightenment_sys 2>&1 | grep open   
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/8ada0e522eaeb14deb3739844ab5e34c25d9ab60e602ab38cc82a2a9ccb732b3.png)  
Он просто открывает известные библиотеки в местах, к которым у нас нет разрешения на вмешательство.  


strace ./enlightenment_sys 2>&1 | grep exec  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/eeee1f4ee0f0e2a61be3ca8ffe0cddcacc0e959de777ae54a83cc6a5d19d65f0.png)  


2- Давайте реверсим бинарник, а затем эксплуатируем его.  


Я создал новый проект Ghidra и загрузил этот конкретный бинарник.  
Поскольку символы не найдены, мы можем определить функцию main через entry.  
Первый аргумент функции entry — это сама main.  
Я переименовал ее в main для дальнейших ссылок.  
Прокрутив немного вниз, я уже вижу, что используется функция system().  


Как pwner, я провожу дни за решением задач, чтобы вызвать эту конкретную функцию x)  
Я реверсил бинарник в поисках ошибки повреждения памяти или проблем с кучей,  
но на самом деле это оказалась странная инъекция команд.  
Бинарник принимает все меры предосторожности перед запуском system, но, к сожалению,  
мы всегда можем внедрить туда наш ввод.  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/d064ca5512049d46ce3c83f3e272964e30609ca9b7f3ab7807844a22c9d24837.png)  


Хорошо, теперь давайте пройдемся по бинарнику сверху вниз до нашей функции system, пытаясь  
внедрить туда наш ввод.  


Сначала бинарник просто проверяет, является ли первый аргумент --help или -h, и выводит то  
сообщение, которое мы видели ранее.  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/e4b1a64f89c60b895357af79172c2ae5b67a2e0e77893b75d7f7fce271f5170b.png)  


Во-вторых, он повышает свои привилегии до root.  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/051237c2c47c65c3b4097637b0dca2f4bd36e2aa34deac26f1fdd35f6066b895.png)  


Затем он сбрасывает почти все переменные окружения (меры безопасности), чтобы  
не вызвать другой нецелевой бинарник.  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/f2b51670f076e04d8d785304c04fdae671f4c6944d26e0ed0f8dc988f14c8f8a.png)  


Итак, если первый аргумент, который мы ввели, — это "mount", он войдет в эту ветку, проверит некоторые  
флаги, которые будут установлены в стеке.  


Далее он проверяет, начинается ли следующий параметр после mount с UUID= — мы не хотим туда  
попадать, поэтому мы передали "/dev/../tmp/;/tmp/exploit".  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/5cdf566aa096e0637ad12a76795c78c82bba696e410900c375a1a02d7a33f376.png)  
Таким образом мы проходим проверку в строке 410. Проверку strncmp.  
Потому что если он не начинается с /dev/, бинарник завершится.  
Затем происходит вызов stat64 для этого файла. Обратите внимание, что мы можем  
создать папку с именем ";" и это вызовет инъекцию команды.  
На данный момент эксплойт уже создал этот файл /dev/../tmp/;/tmp/exploit,  
но это не тот эксплойт, который будет вызван.  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/7ed53d02ec4a09e9a8a25f6181215bf8944a12ff25a05b3684790b155126781f.png)  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/7adb572897044c1cebe04ab2f922495212cbe1be80a82c6502a7aa2b9cfd5da1.png)  


Теперь мы приближаемся к system().  
Теперь p (указатель) обновляется до последнего аргумента, переданного нашему SUID-бинарнику:  
/tmp///net.  


Зачем передавать /tmp///net, если можно передать /tmp/net?  
Мы обойдем эту проверку:  
`if (((next_next == (char *)0x0) || (next_next[1] == '\0')) || ((long)next_next - (long)p != 6))`  
Нам нужно было, чтобы /tmp/net существовал, а /tmp/// имел длину 6.  


Теперь последний stat64 проверит существование "/dev/net"  
__snprintf_chk(cmd,0x1000,1,0x1000,"/dev%s",next_next);  
И он найдет его, так что мы проходим последнюю проверку.  


Теперь он проверит наличие некоторых файлов, но это уже неважно  
на данном этапе, потому что всё готово и мы близки к запуску произвольной  
команды.  


Теперь eina_strbuf_new() просто инициализирует команду, которая будет передана  
system. Проблема в том, что мы ввели её как:  


/bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), "/dev/../tmp/;/tmp/exploit" /tmp///net  


Но бинарник вызывает eina_strbuf_append_printf() несколько раз и получает  
/bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), /dev/../tmp/;/tmp/exploit /tmp///net  
Обратите внимание, что двойные кавычки удалены, и мы сможем вызвать /tmp/exploit  
от имени root.  
![Screenshot](https://assets.kitploit.com/production/public/readmes/37783/0abd481baf7a53305da4e50fe122b80341f228413fa72c359201ed215a9b5af9.png)  


Бинарник сделал всё возможное, чтобы смягчить любое нецелевое поведение, но, как обычно,  
всё можно взломать. Я не ожидал, что смогу эксплуатировать это с помощью такой логической ошибки.  
Я хочу, чтобы следующая CVE была связана с повреждением памяти, ведущим к LPE до root.  


Твиттер-раскрытие: https://twitter.com/maherazz2/status/1569665311707734023