Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 60

Дожили. Самые обычные текстовые файлы могут причинить вред компьютеру. Так скоро «Войну и мир» читать будет опасно — червивая окажется :-\
Всего голосов 40: ↑36 и ↓4+32
Тексты представляли опасность с момента появления текстов. Их даже жгли и запрещали.
Всего голосов 32: ↑32 и ↓0+32
В связи с этим есть вопрос: а насколько WebDAV вообще популярен сейчас?
Я сам людям несколько раз делал WebDAV доступ к документам, в т.ч. через интернет, но это было настолько эпизодически…
Комментарий пока не оценивали0
То же самое можно сделать и без WebDAV. Главное чтобы DLL лежала в одном каталоге с txt. Например, прислать пользователю zip архив с этими двумя файлами.

Всего голосов 3: ↑3 и ↓0+3
НЛО прилетело и опубликовало эту надпись здесь
Это уже баян, вообще-то. Уязвимость в 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
Всего голосов 37: ↑37 и ↓0+37
В отличие от 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)
Всего голосов 19: ↑10 и ↓9+1
В 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)
Всего голосов 13: ↑13 и ↓0+13
О, и правда. Извиняюсь, значит я наврал. В свое время долго мучался с ненавистным rpath и кросс-компиляцией всякого.
Всего голосов 5: ↑4 и ↓1+3
НЛО прилетело и опубликовало эту надпись здесь
Не уточните, а во FreeBSD такая уязвимость тоже имеет место?
Комментарий пока не оценивали0
Если приложение загружает библиотеку lib1.dll не указывая полный путь, то Windows ищет библиотеку сначала в текущем каталоге, потом в каталоге программы, в каталоге Windows и так далее.

Не совсем так, в текущем каталоге поиск происходит одним из последних. Проблемы начинаются если во всех остальных каталогах dll-ки с нужным именем нет, что случается чаще чем хотелось бы.
Всего голосов 5: ↑5 и ↓0+5
Мне кажется что предложенный вами вариант с архивами ничего не даст атакующему, т.к. в статье речь идёт о сетевых папках. DLL Hijacking конечно можно осуществить с архивами, но это уже не будет относиться к .txt+.dll
Всего голосов 2: ↑1 и ↓10
Теперь будут приколы вроде:
— Привет! хочешь я тебя через .txt файл ломану?
— Как?
Передача файла virus.rar
Всего голосов 26: ↑2 и ↓24-22
dll hijacking, уязвимость не в txt, а в ПО, которым открываются txt, в данном случае notepad (? в статье не слова про notepad)
Всего голосов 19: ↑17 и ↓2+15
автора видели?
Всего голосов 46: ↑43 и ↓3+40
Я себе недавно плагин для хрома поставил, спасибо его создателю :)
Всего голосов 15: ↑13 и ↓2+11
Чота вроде ализар обиделся за такой комментарий :D
Всего голосов 6: ↑1 и ↓5-4
В линуксе, если LD_LIBRARY_PATH не включает в себя "." (текущий каталог), а он по умолчанию ни на одном вменяемом дистрибутиве не включает, то подобного бреда не происходит.
Всего голосов 8: ↑8 и ↓0+8
Дефолтные настройки в 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
Всего голосов 8: ↑8 и ↓0+8
М-да, обрабатывать пустые записи как "." — не сильно меньший фейл, чем в винде…
Всего голосов 9: ↑3 и ↓6-3
> Файлы *.txt представляют опасность в Windows

Вуа-ха-ха-ха-ха. Скоро, мне кажется, единственным способом защиты от вирусов в Windows будет вообще не включать компьютер. Это же надо так код писать левой пяткой.
Всего голосов 48: ↑6 и ↓42-36
офигеть… *лицопальма*

как хорошо, что есть всегда
на ноуте моя гентА
Всего голосов 33: ↑8 и ↓25-17
Прааильно минусуют! Arch — наше всё!:D
Всего голосов 14: ↑10 и ↓4+6
Что это за похожая «уязвимость» для Linux? Пожно подробнее?
Всего голосов 10: ↑5 и ↓50
Всегда обновляй комментарии перед отправкой!
Всего голосов 16: ↑6 и ↓10-4
Угадай автора по заголовку
Всего голосов 10: ↑6 и ↓4+2
А я угадал по комменту (:
Заметил, что комментарии типа «угадай автора» пишут про alizar'а.
Всего голосов 14: ↑12 и ↓2+10
Еще про Мицгола.
Всего голосов 4: ↑2 и ↓20
Когда пишет Мицгол итак всё понятно)
Всего голосов 11: ↑11 и ↓0+11
Ибо молвит он импѣрскою нѣвозбранною письмѣнностью.
Всего голосов 6: ↑4 и ↓2+2
Alizar's topic highlighter for Habrahabr не дает времени угадывать :)
Всего голосов 8: ↑6 и ↓2+4
> если пользователь открывает ссылку на .txt файл на сетевом диске по протоколу WebDAV, в его системе может запуститься вредоносный код, размещённый в файле .dll в той же папке на сетевом диске, что и файл .txt
Как хитро закручено. Я, честно говоря, понял только с третьего раза.
Всего голосов 8: ↑1 и ↓7-6
Как раз хотел написать статью про вирусы в bmp файлах, а тут уже про txt :)
Всего голосов 1: ↑1 и ↓0+1
Пишите-пишите. Очень интересно!
Всего голосов 5: ↑5 и ↓0+5
Файлы con и prn представляют опасность в Windows
Комментарий пока не оценивали0
Файлы представляют опасность в Windows
fixed.
Всего голосов 11: ↑11 и ↓0+11
Файлы представляют опасность.
fixed.
Всего голосов 1: ↑0 и ↓1-1
Файлы?
fixed.
Всего голосов 1: ↑0 и ↓1-1
опасность.
Всего голосов 2: ↑1 и ↓10
У меня дежавю, или про dll-hijacking в Windows уже носились где-то полгода назад? Только тогда не файлы, вроде бы, надо было открывать, а чтобы dll с именем системной лежала в папке софта.

А вообще всё верно, либы надо искать сначала в системных папках, а потом уж в текущей.
Всего голосов 2: ↑2 и ↓0+2
Вот тоже дежавю. Еще давался пример вредоносного кода, но почему-то у меня оно не заработало, поддельная dll не загружалась вместо системной.
Комментарий пока не оценивали0
Если искать сперва в системных папках, то получим dll-hell — проблемы с версиями библиотек, когда программа А скомпилирована под dll версии Х, а программа Б — для dll версии Y. Раньше у меня часто были проблемы при установке софта не из репозиториев — замучаешься нужные версии .so искать.
Динамические библиоткки лучше искать нужно сперва в папке запускаемого файла, а потом уже в системных папках. В текущей папке лучше не искать совсем.
Всего голосов 4: ↑4 и ↓0+4
Хорошее уточнение, текущая папка != папка запускаемого файла, видимо, в этом и факап
Всего голосов 2: ↑2 и ↓0+2
Непонятно какое может быть вообше дежавю, это известное и задокументированное поведение. Любой человек кто читал как программировать под windows это прекрасно знает. И этим приемом часто пользуются, например для создания прокси в directx не влезая в чужой процесс для слайсинга функций, что полгода назад, что 10 лет назад.
Всего голосов 3: ↑2 и ↓1+1
Ну одно дело, когда dll лежит в каталоге с установленной софтиной, другое дело, когда мы открываем экзешку или документ, а там лежит левая dll, которая и подхватывается
Всего голосов 2: ↑2 и ↓0+2
А касаемо же nix*, там для создания прокси библиотек даже есть специальная функциональность — подгрузка своей библиотеки через DYLD_INSERT_LIBRARIES, а библиотека проксирует функции через __interpose секцию.
Всего голосов 1: ↑1 и ↓0+1
Не только с WebDAV стабарывает, с обычной шары тоже, а это намного хуже.
Поправьте топик, не вводите в заблуждение.
Комментарий пока не оценивали0
OK, хотя это очевидно, имхо.
Комментарий пока не оценивали0
Это не имхо, а написано в бюллетене, который похоже никто (включая комментирующих) внимательно не прочел.
(На всякий случай, SMB и CIFS это и есть «обычные шары».)

Кстати, я после прочтения бюллетеня и хождения по сссылкам так и не понял, как можно эксплуатировать эту уязвимость именнно с .txt файлом. Из списка пофиксенных комнонентов, .txt файлы может открывать разве что HyperTerminal.

Если кто-то имеет польше информации, поясните пожалуйста.
Комментарий пока не оценивали0
Там патчится еще IMJPAPI.DLL, которая может грузиться в любой процесс, позволяющий вводить текст с помощью IME. Я только не понимаю, почему это работает только для сетевых шар, но не для локальных дисков. Из KB не ясно.
Комментарий пока не оценивали0
Как я понимаю, это должно срабатывать везде, даже из архива, где есть dll
Комментарий пока не оценивали0
FAR + F4
Комментарий пока не оценивали0
Не понятно, почему именно .txt, .rtf и .doc. Что, при открытии других файлов .dll не ищется в текущем каталоге?
Всего голосов 1: ↑1 и ↓0+1
Традиционно наиболее «безопасные», к тому же уязвимость в основном таргетирована на стандартные офисные приложения
Всего голосов 1: ↑1 и ↓0+1
Ищется, но бюллетень MS11-071 (уязвимость) относиться именно к этим типам файлов
Комментарий пока не оценивали0
1)Создал в шаре \\office\Videos файл test.txt
2) Положил там же рядом ntdll.dll, собранный из мусора
3) Открыл «блокнотом» текстовый файл.

Эффекта ноль. По идее, должно же ругаться.
Или я не прав?

Кто может привести простой пример эксплуатации?
Комментарий пока не оценивали0
ntdll.dll у вас уже был загружен, поэтому не загрузился заново.
Всего голосов 1: ↑1 и ↓0+1
Ок. PE tools в зубы и будем искать dll, которые загружает notepad!
Если получится, отпишусь.
Однако, как же не хватает ldd, lsof и проч…
Комментарий пока не оценивали0
Возможно упомянутый в бюллетене IMJPAPI.DLL, только перед этим я бы еще добавил какую-нибудь японскую раскладку и IME для неё. И мне кажется Dependency Walker в режиме Profile или Process Monitor будут удобнее, хотя может я чего-то не знаю про PE Tools. И ещё, попробуйте попереключать SafeDllSearchMode.
Всего голосов 2: ↑2 и ↓0+2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr