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

    Microsoft опубликовала важный бюллетень о безопасности MS11-071 с описанием уязвимости во всех версиях Windows.

    Суть уязвимости в том, что если пользователь открывает .txt файл из сетевой папки, то в его системе может запуститься вредоносный код из .dll в той же сетевой папке, что и файл .txt. В результате злоумышленник может получить такие же права в системе, какие есть у пользователя. Кроме .txt, уязвимость покрывает файлы .rtf и .doc.

    Подробнее о загрузке DLL в Windows, а также о настройке реестра для ограничений на поиск DLL (CWDIllegalInDllSearch).

    Похожая «уязвимость» для Linux связана с использованием LD_LIBRARY_PATH.

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

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

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

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

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

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

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

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

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

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

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

                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                          Самое читаемое