alizar 17 сен 2011 в 14:21

Файлы *.txt представляют опасность в Windows

1 мин

6.5K

Информационная безопасность *

+51

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

ertaquo 17 сен 2011 в 14:34

Дожили. Самые обычные текстовые файлы могут причинить вред компьютеру. Так скоро «Войну и мир» читать будет опасно — червивая окажется :-\

gene4000 18 сен 2011 в 04:21

Тексты представляли опасность с момента появления текстов. Их даже жгли и запрещали.

amc 17 сен 2011 в 14:52

В связи с этим есть вопрос: а насколько WebDAV вообще популярен сейчас?
Я сам людям несколько раз делал WebDAV доступ к документам, в т.ч. через интернет, но это было настолько эпизодически…

gribozavr 17 сен 2011 в 15:26

То же самое можно сделать и без WebDAV. Главное чтобы DLL лежала в одном каталоге с txt. Например, прислать пользователю zip архив с этими двумя файлами.

НЛО прилетело и опубликовало эту надпись здесь

gribozavr 17 сен 2011 в 15:41

Это уже баян, вообще-то. Уязвимость в 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

whitequark 17 сен 2011 в 15:53

В отличие от 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)

gribozavr 17 сен 2011 в 16:00

В 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)

whitequark 17 сен 2011 в 16:03

О, и правда. Извиняюсь, значит я наврал. В свое время долго мучался с ненавистным rpath и кросс-компиляцией всякого.

НЛО прилетело и опубликовало эту надпись здесь

mt_ 17 сен 2011 в 17:04

Не уточните, а во FreeBSD такая уязвимость тоже имеет место?

amirul 17 сен 2011 в 21:21

Если приложение загружает библиотеку lib1.dll не указывая полный путь, то Windows ищет библиотеку сначала в текущем каталоге, потом в каталоге программы, в каталоге Windows и так далее.

Не совсем так, в текущем каталоге поиск происходит одним из последних. Проблемы начинаются если во всех остальных каталогах dll-ки с нужным именем нет, что случается чаще чем хотелось бы.

M4zD4i 18 сен 2011 в 07:51

Мне кажется что предложенный вами вариант с архивами ничего не даст атакующему, т.к. в статье речь идёт о сетевых папках. DLL Hijacking конечно можно осуществить с архивами, но это уже не будет относиться к .txt+.dll

Fedcomp 17 сен 2011 в 15:32

Теперь будут приколы вроде:
— Привет! хочешь я тебя через .txt файл ломану?
— Как?
Передача файла virus.rar

GetWindowsDirectory 17 сен 2011 в 15:35

dll hijacking, уязвимость не в txt, а в ПО, которым открываются txt, в данном случае notepad (? в статье не слова про notepad)

AlexeyTokar 17 сен 2011 в 15:52

автора видели?

takeit 17 сен 2011 в 18:45

Я себе недавно плагин для хрома поставил, спасибо его создателю :)

takeit 18 сен 2011 в 06:02

Чота вроде ализар обиделся за такой комментарий :D

whitequark 17 сен 2011 в 15:36

В линуксе, если LD_LIBRARY_PATH не включает в себя "." (текущий каталог), а он по умолчанию ни на одном вменяемом дистрибутиве не включает, то подобного бреда не происходит.

gribozavr 17 сен 2011 в 15:45

Дефолтные настройки в 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

7vies 17 сен 2011 в 15:52

М-да, обрабатывать пустые записи как "." — не сильно меньший фейл, чем в винде…

egorinsk 17 сен 2011 в 15:36

> Файлы *.txt представляют опасность в Windows

Вуа-ха-ха-ха-ха. Скоро, мне кажется, единственным способом защиты от вирусов в Windows будет вообще не включать компьютер. Это же надо так код писать левой пяткой.

vitroot 17 сен 2011 в 15:42

офигеть… *лицопальма*

как хорошо, что есть всегда
на ноуте моя гентА

dmchmk 18 сен 2011 в 02:24

Прааильно минусуют! Arch — наше всё!:D

cblp 17 сен 2011 в 15:47

Что это за похожая «уязвимость» для Linux? Пожно подробнее?

cblp 17 сен 2011 в 15:49

Всегда обновляй комментарии перед отправкой!

Gumanoid 17 сен 2011 в 15:47

Угадай автора по заголовку

caffeinum 17 сен 2011 в 15:55

А я угадал по комменту (:
Заметил, что комментарии типа «угадай автора» пишут про alizar'а.

Oblitus 17 сен 2011 в 16:12

Еще про Мицгола.

Evengard 17 сен 2011 в 16:27

Когда пишет Мицгол итак всё понятно)

roman_tik 17 сен 2011 в 22:12

Ибо молвит он импѣрскою нѣвозбранною письмѣнностью.

niro 17 сен 2011 в 18:27

Alizar's topic highlighter for Habrahabr не дает времени угадывать :)

powder96 17 сен 2011 в 15:51

> если пользователь открывает ссылку на .txt файл на сетевом диске по протоколу WebDAV, в его системе может запуститься вредоносный код, размещённый в файле .dll в той же папке на сетевом диске, что и файл .txt
Как хитро закручено. Я, честно говоря, понял только с третьего раза.

Andrew1000000 17 сен 2011 в 16:32

Как раз хотел написать статью про вирусы в bmp файлах, а тут уже про txt :)

mt_ 17 сен 2011 в 17:05

Пишите-пишите. Очень интересно!

terrance 17 сен 2011 в 17:46

Файлы con и prn представляют опасность в Windows

lomalkin 18 сен 2011 в 01:33

Файлы представляют опасность в Windows
fixed.

Colwin 19 сен 2011 в 05:48

Файлы представляют опасность.
fixed.

khekkly 19 сен 2011 в 08:12

Файлы?
fixed.

pcholberg 19 сен 2011 в 09:09

опасность.

Lure_of_Chaos 17 сен 2011 в 19:01

У меня дежавю, или про dll-hijacking в Windows уже носились где-то полгода назад? Только тогда не файлы, вроде бы, надо было открывать, а чтобы dll с именем системной лежала в папке софта.

А вообще всё верно, либы надо искать сначала в системных папках, а потом уж в текущей.

dimmaq 17 сен 2011 в 19:26

Вот тоже дежавю. Еще давался пример вредоносного кода, но почему-то у меня оно не заработало, поддельная dll не загружалась вместо системной.

diamant 17 сен 2011 в 19:57

Если искать сперва в системных папках, то получим dll-hell — проблемы с версиями библиотек, когда программа А скомпилирована под dll версии Х, а программа Б — для dll версии Y. Раньше у меня часто были проблемы при установке софта не из репозиториев — замучаешься нужные версии .so искать.
Динамические библиоткки лучше искать нужно сперва в папке запускаемого файла, а потом уже в системных папках. В текущей папке лучше не искать совсем.

Lure_of_Chaos 17 сен 2011 в 20:00

Хорошее уточнение, текущая папка != папка запускаемого файла, видимо, в этом и факап

CLR 17 сен 2011 в 21:33

Непонятно какое может быть вообше дежавю, это известное и задокументированное поведение. Любой человек кто читал как программировать под windows это прекрасно знает. И этим приемом часто пользуются, например для создания прокси в directx не влезая в чужой процесс для слайсинга функций, что полгода назад, что 10 лет назад.

Lure_of_Chaos 17 сен 2011 в 21:36

Ну одно дело, когда dll лежит в каталоге с установленной софтиной, другое дело, когда мы открываем экзешку или документ, а там лежит левая dll, которая и подхватывается

CLR 17 сен 2011 в 21:37

А касаемо же nix*, там для создания прокси библиотек даже есть специальная функциональность — подгрузка своей библиотеки через DYLD_INSERT_LIBRARIES, а библиотека проксирует функции через __interpose секцию.

ComodoHacker 17 сен 2011 в 20:07

Не только с WebDAV стабарывает, с обычной шары тоже, а это намного хуже.
Поправьте топик, не вводите в заблуждение.

alizar 17 сен 2011 в 20:11

OK, хотя это очевидно, имхо.

ComodoHacker 17 сен 2011 в 20:40

Это не имхо, а написано в бюллетене, который похоже никто (включая комментирующих) внимательно не прочел.
(На всякий случай, SMB и CIFS это и есть «обычные шары».)

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

Если кто-то имеет польше информации, поясните пожалуйста.

Paul 17 сен 2011 в 22:28

Там патчится еще IMJPAPI.DLL, которая может грузиться в любой процесс, позволяющий вводить текст с помощью IME. Я только не понимаю, почему это работает только для сетевых шар, но не для локальных дисков. Из KB не ясно.

Lure_of_Chaos 17 сен 2011 в 20:14

Как я понимаю, это должно срабатывать везде, даже из архива, где есть dll

Methos 18 сен 2011 в 06:32

FAR + F4

Lsh 18 сен 2011 в 07:41

Не понятно, почему именно .txt, .rtf и .doc. Что, при открытии других файлов .dll не ищется в текущем каталоге?

Lure_of_Chaos 18 сен 2011 в 08:02

Традиционно наиболее «безопасные», к тому же уязвимость в основном таргетирована на стандартные офисные приложения

M4zD4i 18 сен 2011 в 07:59

Ищется, но бюллетень MS11-071 (уязвимость) относиться именно к этим типам файлов

Nastradamus 19 сен 2011 в 13:35

1)Создал в шаре \\office\Videos файл test.txt
2) Положил там же рядом ntdll.dll, собранный из мусора
3) Открыл «блокнотом» текстовый файл.

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

Кто может привести простой пример эксплуатации?

Paul 19 сен 2011 в 15:51

ntdll.dll у вас уже был загружен, поэтому не загрузился заново.

Nastradamus 19 сен 2011 в 16:48

Ок. PE tools в зубы и будем искать dll, которые загружает notepad!
Если получится, отпишусь.
Однако, как же не хватает ldd, lsof и проч…

Paul 19 сен 2011 в 16:56

Возможно упомянутый в бюллетене IMJPAPI.DLL, только перед этим я бы еще добавил какую-нибудь японскую раскладку и IME для неё. И мне кажется Dependency Walker в режиме Profile или Process Monitor будут удобнее, хотя может я чего-то не знаю про PE Tools. И ещё, попробуйте попереключать SafeDllSearchMode.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий