alizar Sep 17 2011 at 18:21

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

1 min

6.3K

Information Security*

+51

Comments 60

ertaquo Sep 17 2011 at 18:34

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

gene4000 Sep 18 2011 at 08:21

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

amc Sep 17 2011 at 18:52

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

gribozavr Sep 17 2011 at 19:26

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

UFO just landed and posted this here

gribozavr Sep 17 2011 at 19: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 Sep 17 2011 at 19: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 Sep 17 2011 at 20: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 Sep 17 2011 at 20:03

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

UFO just landed and posted this here

mt_ Sep 17 2011 at 21:04

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

amirul Sep 18 2011 at 01:21

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

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

M4zD4i Sep 18 2011 at 11:51

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

Fedcomp Sep 17 2011 at 19:32

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

GetWindowsDirectory Sep 17 2011 at 19:35

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

AlexeyTokar Sep 17 2011 at 19:52

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

takeit Sep 17 2011 at 22:45

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

takeit Sep 18 2011 at 10:02

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

whitequark Sep 17 2011 at 19:36

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

gribozavr Sep 17 2011 at 19: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 Sep 17 2011 at 19:52

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

egorinsk Sep 17 2011 at 19:36

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

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

vitroot Sep 17 2011 at 19:42

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

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

4umak Sep 18 2011 at 06:24

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

cblp Sep 17 2011 at 19:47

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

cblp Sep 17 2011 at 19:49

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

Gumanoid Sep 17 2011 at 19:47

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

caffeinum Sep 17 2011 at 19:55

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

Oblitus Sep 17 2011 at 20:12

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

Evengard Sep 17 2011 at 20:27

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

roman_tik Sep 18 2011 at 02:12

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

niro Sep 17 2011 at 22:27

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

powder96 Sep 17 2011 at 19:51

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

Andrew1000000 Sep 17 2011 at 20:32

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

mt_ Sep 17 2011 at 21:05

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

terrance Sep 17 2011 at 21:46

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

lomalkin Sep 18 2011 at 05:33

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

Colwin Sep 19 2011 at 09:48

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

khekkly Sep 19 2011 at 12:12

Файлы?
fixed.

pcholberg Sep 19 2011 at 13:09

опасность.

Lure_of_Chaos Sep 17 2011 at 23:01

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

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

dimmaq Sep 17 2011 at 23:26

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

diamant Sep 17 2011 at 23:57

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

Lure_of_Chaos Sep 18 2011 at 00:00

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

CLR Sep 18 2011 at 01:33

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

Lure_of_Chaos Sep 18 2011 at 01:36

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

CLR Sep 18 2011 at 01:37

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

ComodoHacker Sep 18 2011 at 00:07

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

alizar Sep 18 2011 at 00:11

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

ComodoHacker Sep 18 2011 at 00:40

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

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

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

Paul Sep 18 2011 at 02:28

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

Lure_of_Chaos Sep 18 2011 at 00:14

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

Methos Sep 18 2011 at 10:32

FAR + F4

Lsh Sep 18 2011 at 11:41

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

Lure_of_Chaos Sep 18 2011 at 12:02

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

M4zD4i Sep 18 2011 at 11:59

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

Nastradamus Sep 19 2011 at 17:35

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

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

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

Paul Sep 19 2011 at 19:51

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

Nastradamus Sep 19 2011 at 20:48

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

Paul Sep 19 2011 at 20:56

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