Comments 60
Дожили. Самые обычные текстовые файлы могут причинить вред компьютеру. Так скоро «Войну и мир» читать будет опасно — червивая окажется :-\
В связи с этим есть вопрос: а насколько WebDAV вообще популярен сейчас?
Я сам людям несколько раз делал WebDAV доступ к документам, в т.ч. через интернет, но это было настолько эпизодически…
Я сам людям несколько раз делал WebDAV доступ к документам, в т.ч. через интернет, но это было настолько эпизодически…
То же самое можно сделать и без WebDAV. Главное чтобы DLL лежала в одном каталоге с txt. Например, прислать пользователю zip архив с этими двумя файлами.
UFO just landed and posted this here
Это уже баян, вообще-то. Уязвимость в Windows связана с дефолтными путями поиска библиотек. Если приложение загружает библиотеку lib1.dll не указывая полный путь, то Windows ищет библиотеку сначала в текущем каталоге, потом в каталоге программы, в каталоге Windows и так далее. Так как текущий каталог стоит первым, то в нём можно создать библиотеку с нужным именем и программа её загрузит если будет искать без полного пути.
В Linux с настройками по умолчанию уязвимости нет, но можно в переменную LD_LIBRARY_PATH включить текущий каталог и тогда она появится.
Такие уязвимости были найдены мной в Firefox, OpenOffice.org и Oracle Java, но они проявляются только в случае особой настройки системы. У этих приложений стартовые скрипты настраивают LD_LIBRARY_PATH, но делают это недостаточно аккуратно и не учитывают все возможные случаи (они не добавляют текущий каталог намеренно). Если переменная LD_LIBRARY_PATH была пустой (именно пустой, а не неопределённой — не дефолтный и вообще очень редкий и странный случай настройки), то благодаря особому случаю обработки пустых записей после модификации в LD_LIBRARY_PATH появляется текущий каталог.
CVE-2010-3182 www.mozilla.org/security/announce/2010/mfsa2010-71.html
CVE-2010-3689 www.openoffice.org/security/cves/CVE-2010-3689.html
CVE-2010-4450 www.oracle.com/technetwork/topics/security/javacpufeb2011-304611.html
В Linux с настройками по умолчанию уязвимости нет, но можно в переменную LD_LIBRARY_PATH включить текущий каталог и тогда она появится.
Такие уязвимости были найдены мной в Firefox, OpenOffice.org и Oracle Java, но они проявляются только в случае особой настройки системы. У этих приложений стартовые скрипты настраивают LD_LIBRARY_PATH, но делают это недостаточно аккуратно и не учитывают все возможные случаи (они не добавляют текущий каталог намеренно). Если переменная LD_LIBRARY_PATH была пустой (именно пустой, а не неопределённой — не дефолтный и вообще очень редкий и странный случай настройки), то благодаря особому случаю обработки пустых записей после модификации в LD_LIBRARY_PATH появляется текущий каталог.
CVE-2010-3182 www.mozilla.org/security/announce/2010/mfsa2010-71.html
CVE-2010-3689 www.openoffice.org/security/cves/CVE-2010-3689.html
CVE-2010-4450 www.oracle.com/technetwork/topics/security/javacpufeb2011-304611.html
В отличие от Windows, в мире Linux стандартный софт в репозиториях собирается с полными путями к библиотекам — так работает autotools ("./configure"). Это очень неудобно при кросс-компиляции, но спасает от подобных дыр. Таким образом, уязвим только 3rd party софт, и только в случае явного запуска из целевого каталога. (Возможно, бинарник в $HOME тоже сработает, я не уверен.) Это уж совсем маловероятный вариант событий.
$ ldd `which ls` linux-gate.so.1 => (0xb7809000) libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0x4212d000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb77ec000) libacl.so.1 => /lib/i386-linux-gnu/libacl.so.1 (0x4101f000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb76a6000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb76a2000) /lib/ld-linux.so.2 (0xb780a000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7689000) libattr.so.1 => /lib/i386-linux-gnu/libattr.so.1 (0x4111b000)
В Linux как раз наоборот, все пути относительные. А полные пути (через rpath) очень редкий случай. ldd показывает где именно найдена запрошенная библиотека.
$ pwd
/tmp/1
$ ls
librt.so.1
$ LD_LIBRARY_PATH="." ldd /bin/ls
linux-vdso.so.1 => (0x00007fffaa1f5000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fc764d5a000)
librt.so.1 => ./librt.so.1 (0x00007fc764b52000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007fc764949000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc7645c5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc7643c1000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc764fa0000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc7641a4000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007fc763fa0000)UFO just landed and posted this here
Не уточните, а во FreeBSD такая уязвимость тоже имеет место?
Если приложение загружает библиотеку lib1.dll не указывая полный путь, то Windows ищет библиотеку сначала в текущем каталоге, потом в каталоге программы, в каталоге Windows и так далее.
Не совсем так, в текущем каталоге поиск происходит одним из последних. Проблемы начинаются если во всех остальных каталогах dll-ки с нужным именем нет, что случается чаще чем хотелось бы.
Мне кажется что предложенный вами вариант с архивами ничего не даст атакующему, т.к. в статье речь идёт о сетевых папках. DLL Hijacking конечно можно осуществить с архивами, но это уже не будет относиться к .txt+.dll
Теперь будут приколы вроде:
— Привет! хочешь я тебя через .txt файл ломану?
— Как?
Передача файла virus.rar
— Привет! хочешь я тебя через .txt файл ломану?
— Как?
Передача файла virus.rar
dll hijacking, уязвимость не в txt, а в ПО, которым открываются txt, в данном случае notepad (? в статье не слова про notepad)
В линуксе, если LD_LIBRARY_PATH не включает в себя "." (текущий каталог), а он по умолчанию ни на одном вменяемом дистрибутиве не включает, то подобного бреда не происходит.
Дефолтные настройки в Linux безопасны, да.
Но есть одна тонкость. Пустые записи в LD_LIBRARY_PATH обрабатываются как "."
Пусть было LD_LIBRARY_PATH="" (это означает «нет записей» по мнению загрузчика) а затем стартовый скрипт программы делает:
LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/myapp/"
то получается:
LD_LIBRARY_PATH=":/usr/lib/myapp/"
то есть, пустая запись и каталог. Пустая запись интерпретируется как "." и вот оно.
В общем, см. мой пост выше habrahabr.ru/blogs/infosecurity/128628/?reply_to=4254621#comment_4254657
Но есть одна тонкость. Пустые записи в LD_LIBRARY_PATH обрабатываются как "."
Пусть было LD_LIBRARY_PATH="" (это означает «нет записей» по мнению загрузчика) а затем стартовый скрипт программы делает:
LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/myapp/"
то получается:
LD_LIBRARY_PATH=":/usr/lib/myapp/"
то есть, пустая запись и каталог. Пустая запись интерпретируется как "." и вот оно.
В общем, см. мой пост выше habrahabr.ru/blogs/infosecurity/128628/?reply_to=4254621#comment_4254657
> Файлы *.txt представляют опасность в Windows
Вуа-ха-ха-ха-ха. Скоро, мне кажется, единственным способом защиты от вирусов в Windows будет вообще не включать компьютер. Это же надо так код писать левой пяткой.
Вуа-ха-ха-ха-ха. Скоро, мне кажется, единственным способом защиты от вирусов в Windows будет вообще не включать компьютер. Это же надо так код писать левой пяткой.
офигеть… *лицопальма*
как хорошо, что есть всегда
на ноуте моя гентА
как хорошо, что есть всегда
на ноуте моя гентА
Что это за похожая «уязвимость» для Linux? Пожно подробнее?
Угадай автора по заголовку
> если пользователь открывает ссылку на .txt файл на сетевом диске по протоколу WebDAV, в его системе может запуститься вредоносный код, размещённый в файле .dll в той же папке на сетевом диске, что и файл .txt
Как хитро закручено. Я, честно говоря, понял только с третьего раза.
Как хитро закручено. Я, честно говоря, понял только с третьего раза.
Как раз хотел написать статью про вирусы в bmp файлах, а тут уже про txt :)
Файлы con и prn представляют опасность в Windows
У меня дежавю, или про dll-hijacking в Windows уже носились где-то полгода назад? Только тогда не файлы, вроде бы, надо было открывать, а чтобы dll с именем системной лежала в папке софта.
А вообще всё верно, либы надо искать сначала в системных папках, а потом уж в текущей.
А вообще всё верно, либы надо искать сначала в системных папках, а потом уж в текущей.
Вот тоже дежавю. Еще давался пример вредоносного кода, но почему-то у меня оно не заработало, поддельная dll не загружалась вместо системной.
Если искать сперва в системных папках, то получим dll-hell — проблемы с версиями библиотек, когда программа А скомпилирована под dll версии Х, а программа Б — для dll версии Y. Раньше у меня часто были проблемы при установке софта не из репозиториев — замучаешься нужные версии .so искать.
Динамические библиоткки лучше искать нужно сперва в папке запускаемого файла, а потом уже в системных папках. В текущей папке лучше не искать совсем.
Динамические библиоткки лучше искать нужно сперва в папке запускаемого файла, а потом уже в системных папках. В текущей папке лучше не искать совсем.
Непонятно какое может быть вообше дежавю, это известное и задокументированное поведение. Любой человек кто читал как программировать под windows это прекрасно знает. И этим приемом часто пользуются, например для создания прокси в directx не влезая в чужой процесс для слайсинга функций, что полгода назад, что 10 лет назад.
Ну одно дело, когда dll лежит в каталоге с установленной софтиной, другое дело, когда мы открываем экзешку или документ, а там лежит левая dll, которая и подхватывается
А касаемо же nix*, там для создания прокси библиотек даже есть специальная функциональность — подгрузка своей библиотеки через DYLD_INSERT_LIBRARIES, а библиотека проксирует функции через __interpose секцию.
Не только с WebDAV стабарывает, с обычной шары тоже, а это намного хуже.
Поправьте топик, не вводите в заблуждение.
Поправьте топик, не вводите в заблуждение.
OK, хотя это очевидно, имхо.
Это не имхо, а написано в бюллетене, который похоже никто (включая комментирующих) внимательно не прочел.
(На всякий случай, SMB и CIFS это и есть «обычные шары».)
Кстати, я после прочтения бюллетеня и хождения по сссылкам так и не понял, как можно эксплуатировать эту уязвимость именнно с .txt файлом. Из списка пофиксенных комнонентов, .txt файлы может открывать разве что HyperTerminal.
Если кто-то имеет польше информации, поясните пожалуйста.
(На всякий случай, SMB и CIFS это и есть «обычные шары».)
Кстати, я после прочтения бюллетеня и хождения по сссылкам так и не понял, как можно эксплуатировать эту уязвимость именнно с .txt файлом. Из списка пофиксенных комнонентов, .txt файлы может открывать разве что HyperTerminal.
Если кто-то имеет польше информации, поясните пожалуйста.
Как я понимаю, это должно срабатывать везде, даже из архива, где есть dll
FAR + F4
Не понятно, почему именно .txt, .rtf и .doc. Что, при открытии других файлов .dll не ищется в текущем каталоге?
Ищется, но бюллетень MS11-071 (уязвимость) относиться именно к этим типам файлов
1)Создал в шаре \\office\Videos файл test.txt
2) Положил там же рядом ntdll.dll, собранный из мусора
3) Открыл «блокнотом» текстовый файл.
Эффекта ноль. По идее, должно же ругаться.
Или я не прав?
Кто может привести простой пример эксплуатации?
2) Положил там же рядом ntdll.dll, собранный из мусора
3) Открыл «блокнотом» текстовый файл.
Эффекта ноль. По идее, должно же ругаться.
Или я не прав?
Кто может привести простой пример эксплуатации?
ntdll.dll у вас уже был загружен, поэтому не загрузился заново.
Ок. PE tools в зубы и будем искать dll, которые загружает notepad!
Если получится, отпишусь.
Однако, как же не хватает ldd, lsof и проч…
Если получится, отпишусь.
Однако, как же не хватает ldd, lsof и проч…
Возможно упомянутый в бюллетене IMJPAPI.DLL, только перед этим я бы еще добавил какую-нибудь японскую раскладку и IME для неё. И мне кажется Dependency Walker в режиме Profile или Process Monitor будут удобнее, хотя может я чего-то не знаю про PE Tools. И ещё, попробуйте попереключать SafeDllSearchMode.
Sign up to leave a comment.
Файлы *.txt представляют опасность в Windows