Exploit for OSDS_Paper_CVE-2016-5195

## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-THEO543-OSDS_PAPER_CVE-2016-5195
# CVE-2016-5195 ("Грязная корова")

Этот репозиторий содержит мою статью и слайды презентации по CVE-2016-5195, уязвимости повышения привилегий в Linux, написанные для курса «Операционные системы: проектирование и безопасность» на факультете математики и информатики Бухарестского университета.

## Исправление

В своей статье **я утверждал, что можно использовать Dirty COW для скрытного бэкдоринга бинарников** без немедленного повышения привилегий до root, чтобы затруднить обнаружение.

**На самом деле это неверно** , потому что при попытке обратной записи изменённой страницы ядро обнаруживает, что страница грязная (чем она не должна быть), и впадает в панику, что приводит к краху системы.

Чтобы избежать этого, **необходимо немедленно повысить привилегии до root и отключить автоматическую обратную запись** с помощью команды `echo 0 > /proc/sys/vm/dirty_writeback_centisecs`. Моя концептуальная реализация этого не делает, поэтому при тестировании в виртуальной машине она быстро падает после успешного изменения /etc/passwd (которое не сохраняется на диск).

https://www.exploit-db.com/exploits/40847 — пример кода эксплойта, который перезаписывает /etc/passwd, а затем отключает обратную запись, чтобы предотвратить крах.

Другие методы включают модификацию vDSO (https://github.com/scumjr/dirtycow-vdso) вместо страницы, отображаемой на файл, что затрагивает все процессы в системе и не вызывает краха, а также имеет другие преимущества, например, позволяет выйти из контейнеров и не подвержено ограничениям SELinux, которые могут помешать даже открытию /etc/passwd в режиме только для чтения для атаки.

Хотя вы действительно можете установить бэкдор в систему после повышения привилегий до root (как и при любом другом методе повышения привилегий), это потребует обычных операций с файловой системой и может быть обнаружено системами обнаружения вторжений, тогда как если бы обратная запись работала так, как я изначально думал, она могла бы обойти мониторинг операций записи, поскольку ядро просто записало бы страницу обратно без вызова системного вызова write, но на самом деле вместо этого происходит паника.