Комментарии 51
Был 11 лет и никому дела не было… как работало, так и будет работать. Да и область бага как бы ограниченная.
но вполне себе опасный момент
Таких опасных моментов вагон и маленькая тележка.
Веб серверу — насрать.
Файлопомойке — насрать.
Игровым серверам/серверам стримминга — насрать.
Вообще всему вебсегменту, где зверьки в клетках и не могут запускать программы вне белого списка — насрать.
Проболема носит чисто ДОМАШНИЙ характер, то есть та система, где админ юзер сидит и все ставит и ставит и ставит в систему рандомное говно.
Ей богу развели панику.
Веб серверу — насрать.
Файлопомойке — насрать.
Игровым серверам/серверам стримминга — насрать.
Вообще всему вебсегменту, где зверьки в клетках и не могут запускать программы вне белого списка — насрать.
Проболема носит чисто ДОМАШНИЙ характер, то есть та система, где админ юзер сидит и все ставит и ставит и ставит в систему рандомное говно.
Ей богу развели панику.
Ничего себе ограниченная область! Если можно изменить файл, доступный только root — это всё, компьютер уже не Ваш. Такую штуку обернуть в скрипт, обфусцировать, и впаривать в виде решения какой-то распространённой проблемы под линуксом — и спокойно можно поиметь кучу домашних компов под линуксом в своё распоряжение. Остаётся придумать, как заставить пользователя сделать файл исполняемым (без этого он не запустится).
Интересно, поможет ли от этого флаг -i (immutable)? Ведь с этим флагом даже рут не может редактировать файл, пока не снимет атрибут. Правда, на raiserfs нет поддержки его (разок попалось).
Интересно, поможет ли от этого флаг -i (immutable)? Ведь с этим флагом даже рут не может редактировать файл, пока не снимет атрибут. Правда, на raiserfs нет поддержки его (разок попалось).
> Остаётся придумать, как заставить пользователя сделать файл исполняемым (без этого он не запустится).
curl | sh
Я серьёзно, многие сайты предлагают так устанавливать софт.
curl | sh
Я серьёзно, многие сайты предлагают так устанавливать софт.
Атрибут immutable не канает:
$ cat foo
I do it every day!
$ lsattr foo
----i----------- foo
$ ./dirtyc0w foo «I do what I want!»
mmap 14922000
madvise 0
procselfmem 1700000000
$ cat foo
I do what I want!!!
$ cat foo
I do it every day!
$ lsattr foo
----i----------- foo
$ ./dirtyc0w foo «I do what I want!»
mmap 14922000
madvise 0
procselfmem 1700000000
$ cat foo
I do what I want!!!
С другой стороны, владельцы разнообразных залоченных устройств возрадовались возможности наконец-то их рутануть.
Тот случай, когда баг принесет пользу :)
На Xperia XA (Linux 3.18.22, 64 битный, SELinux включен) не сработало — телефон перезагрузился, результат выполнения отрицательный. Скомпилировал эксплоит C4Droid`ом, создал файл с правами 0404, натравил бинарник в терминале adb, но телефон ушел в ребут, а содержимое файла осталось прежним. Сразу скажу, что рут права есть на телефоне, но мне было интересно попробовать. Если кто знающий увидит в моих действиях ошибку — подскажите
Linux Mint 17.3 — PoC сработал.
При компиляции пришлось немного поколдовать (я ни разу не разбираюсь в C).
Тут я просто убрал printf под комментарий, как не самый важный функционал.
Скомпилировал вот так: gcc -pthread dirtyc0w.c -o dirtyc0w
После запуска PoC завис, однако файл был успешно перезаписан.
При компиляции пришлось немного поколдовать (я ни разу не разбираюсь в C).
dirtyc0w.c:96:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘void *’ [-Wformat=]
printf("mmap %x\n\n",map);Тут я просто убрал printf под комментарий, как не самый важный функционал.
$ gcc -lpthread dirtyc0w.c -o dirtyc0w /tmp/ccJWttLa.o: In function `main': dirtyc0w.c:(.text+0x1c3): undefined reference to `pthread_create'
Скомпилировал вот так: gcc -pthread dirtyc0w.c -o dirtyc0w
После запуска PoC завис, однако файл был успешно перезаписан.
Директива у printf должна быть p, а не x. Опять кто-то перепутал указатель и число.
- printf("mmap %x\n\n",map);
+ printf("mmap %p\n\n",map);
Про printf просто предупреждение, можно игнорировать. Ошибка в -lpthread — его надо либо убрать в конец, либо заменить на -pthread.
Сработало в убунте 16.04
Сработало в убунте 16.04
В debian 8.4 — без проблем: gcc -lpthread dirtyc0w.c -o dirtyc0w
Обычно флага линкера -lpthread недостаточно для корректной компиляции. -pthread не только линкует libpthread, он ещё и выставляет макрос _REENTRANT, который используется в заголовках libc и меняет поведение стандартной библиотеки (переменная errno становится thread_local переменной, к примеру).
Т.е. программа скомпилируется, но может работать неправильно.
В Debian 8.5 аналогично не вызвало проблем. И тоже сработало, так же зависло, но перезаписало.
НЛО прилетело и опубликовало эту надпись здесь
Методом пристального взгляда.
Это со стороны они не очевидны.
Но если знаешь как работают эти механизмы, то начинаешь анализировать и всячески ковырять опасные участки. Да, это не «раз два и готово», работа часто нудная. Для этого пишут различные тулзы автоматизирующие этот процес. Тут все зависит от того, на сколько ты хорошо знаешь как работает этот участок. Ну и еще немного везения)
Но если знаешь как работают эти механизмы, то начинаешь анализировать и всячески ковырять опасные участки. Да, это не «раз два и готово», работа часто нудная. Для этого пишут различные тулзы автоматизирующие этот процес. Тут все зависит от того, на сколько ты хорошо знаешь как работает этот участок. Ну и еще немного везения)
НЛО прилетело и опубликовало эту надпись здесь
Интересно, в Windows 10 проблема присутствует?
А откуда?
Там не ядро линуха, а wine наоборот. Прослойка которая системные вызовы приложений транслирует.
Там не ядро линуха, а wine наоборот. Прослойка которая системные вызовы приложений транслирует.
Серьёзно? А можно пруф-линк в студию?
Не написано там, что ядро линукс внедряют. А всего лишь подсистему линукс в виндоус.
Там написано:
Так что никакого «wine наоборот», как указали здесь выше. Поэтому и запросил пруф.
На слайде указано, что речь идет именно о полноценной подсистеме Linux, а не о псевдо-эмуляции или виртуальных машинах. Да, Linux становится частью Windows 10 и так же как POSIX и OS/2 будет работать в пользовательском режиме с реализацией семантики системных вызовов на уровне ядра.
Так что никакого «wine наоборот», как указали здесь выше. Поэтому и запросил пруф.
А чем UML отличается от «wine наоборот»? Тем что линукс открыт и не приходится переписывать тонну кода и угадывать недокументированные API?
Я немного слукавил, wine работает в пространстве пользователя и работает поверх системных вызовов, а в десятке транслятор это модуль самого ядра.
Так что формально я не прав.
Так что формально я не прав.
Реализован собственный драйвер, реализующий часть системных вызовов, используемых приложениями. Также реализован ряд концепций, необходимых для совместимости с POSIX: VFS с инодами и правами, pipe, и т.п. А также ряд новых потенциальных уязвимостей. При желании можно поизучать содержимое lxss.sys / lxcore.sys и/или почитать подробные логи использования подсистемы (инструкции есть в https://github.com/Microsoft/BashOnWindows/blob/master/CONTRIBUTING.md)
Пруф: BlackHat 2016, ALEX IONESCU (Co-author of Windows Internals 5th and 6th Editions), доклад "THE LINUX KERNEL HIDDEN INSIDE WINDOWS 10"
https://github.com/ionescu007/lxss/blob/master/The%20Linux%20kernel%20hidden%20inside%20windows%2010.pdf
WSL COMPONENT OVERVIEW: Pico Provider driver (LXSS.SYS / LXCORE.SYS) which provides the kernel-mode implementation of a Linux-compatible Kernel ABI and API… implements a virtual file system (VFS) interface, including a device inode
LXCORE.SYS is the large (800KB) kernel-mode Ring 0 driver which implements all the functionality that a Linux application inside of a Pico process will see
• In some cases, functionality is implemented from scratch (such as pipes)
• In other cases, functionality is wrapped on top of an existing NT kernel mechanism or subsystem (scheduling)
• In yet other cases, functionality is heavily built on top of an existing NT kernel primitive, with some from-scratch functionality
SYSTEM CALLS… 216 implemented as of the release build…
VFS / FILE SYSTEM Implements a “VolFs” system, which is the Linux-facing file system with support for UNIX rights, etc.
Provides emulation/wrapping/actual implementation for various virtual file system concepts:
• ProcFs mostly works (calls kernel query APIs as needed) or just already has the data
• TmpFs also exists and implements various devices, including the Binder (key Android IPC from the BeOS days)
• SysFs is there, etc…
В https://github.com/ionescu007/lxss есть различные экспериментальные утилиты по работе с WSL.
Еще линк от авторов WSL и сотрудников MS — https://github.com/benhillis — https://github.com/Microsoft/BashOnWindows/issues/178#issuecomment-249443216
Lxcore.sys is a clean room implementation of the Linux kernel ABI. It contains no code from the Linux kernel and we have a policy that our developers cannot even look at any of the kernel source.
https://github.com/bitcrazed — http://bitcrazed.com/about/ — https://github.com/Microsoft/BashOnWindows/issues/107#issuecomment-209147763
The Windows Subsystem for Linux (WSL) doesn't modify or derive any GPL code: It runs native, unmodified ELF binaries by loading them into a lightweight process created by the Windows Kernel, binding the ELF binary's imports to our syscall implementation and then executing as normal. Bash.exe is a simple Windows app that binds a console (i.e. terminal) window to a process that loads and runs the native /bin/bash from the Ubuntu… It was named Bash.exe as a convenience since, in end-user testing, most users expected bash to
Посты от разработчиков WSL про системные вызовы и подсистемы и их трансляцию в запросы к NT ядру — https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/ https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-calls/
Статические анализаторы кода, видимо, не особо помогают в выявлении таких ошибок?
Статические — нет. Вот динамические (типа ASAN/TSAN) — могут поймать… а могут и не поймать, там нет детерминизма, увы.
На самом деле статический анализатор кода может указать на подобную уязвимость. Не понятно как давно эксплуатируется баг, думаю можно самостоятельно устроить проверку каким-нибудь Coverity
А из OpenVZ контейнера с помощью этой Dirty COW можно выскочить?
Несет ли опасность уязвимость для веб-серверов, или для этого необходимо иметь возможность запустить исполняемый файл на машине?
Есть инструкция для непрограммистов, как пофиксить это уязвимость?
Прошли почти сутки, а патча для RHEL 6 всё ещё нет. Для RHEL 7 и Ubuntu 16.04 прилетели какие-то обновления ядра.
в интернетах пишут, что на RHEL 6 уязвимость не работает, хотя формально и есть.
В коде эксплоита такой комментарий:
> The in the wild exploit we are aware of doesn't work on Red Hat
> Enterprise Linux 5 and 6 out of the box because on one side of
> the race it writes to /proc/self/mem, but /proc/self/mem is not
> writable on Red Hat Enterprise Linux 5 and 6.
> The in the wild exploit we are aware of doesn't work on Red Hat
> Enterprise Linux 5 and 6 out of the box because on one side of
> the race it writes to /proc/self/mem, but /proc/self/mem is not
> writable on Red Hat Enterprise Linux 5 and 6.
Стоит отметить, что этот комментарий относится к конкретной реализации сплоита. Вот тут можно найти несколько вариантов, в том числе тот, который не используется /proc/self/mem.
«Исходники в свободном доступе же! Над ними долго и упорно работает столько народу, что там попросту не может быть сколь-нибудь серьёзных уязвимостей — это же не дырявая венда»
Почему-то вспомнилось. К чему бы это…
Почему-то вспомнилось. К чему бы это…
Судя по всему, вот патч:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
Одно хорошо — на Linux машинах, на которые гарантированно логинятся только не-злоумышленники (например, на личных и домашних ПК), эту уязвимость можно эксплуатировать только если спровоцировать пользователя запустить левый бинарник/скрипт, от чего, надеюсь, большинство отучено.
(Я, правда, не учитываю системные аккаунты вида apache, ftp и т.д.)
(Я, правда, не учитываю системные аккаунты вида apache, ftp и т.д.)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В ядре Linux обнаружена опасная 0-day уязвимость Dirty COW (CVE-2016-5195)