Notepad++ закрыла уязвимость, используемую ЦРУ

В винде и виндософте столько дыр, что мелкодисперсная сетка отдыхает.

Дак это DLL Hijack, он в чём только не работает, даже в том же VLC. Лично я на своей системе повторить не смог, но, теоретически, дырень знатная.

Дак это DLL Hijack, он в чём только не работает, даже в том же VLC.

Вот интересно от него вообще защититься можно?Любая загруженная библиотека имеет доступ к адресному пространству процесса.

Вот интересно от него вообще защититься можно?

Погуглил что это такое. На сколько я понял суть в том что уязвимая программа ищет нужные либы в текущей рабочей директории (в которую добрые люди предварительно положили подложную либу). Если программа может повлиять на процесс поиска либ то решение кажется очевидным.
А ещё можно упороться и сверять контрольные суммы либ загружаемых не из системных директорий, но подозреваю что это создаст кучу прикольных проблем

Надо как в маке, пакет целый.

Вот интересно от него вообще защититься можно?

Грузите либы только динамически по сгенерированному софтово абсолютному пути. Ещё можно подпись либ проверять, чтоб левую не подсунули.

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

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

Я бы сказал по другому, для любого приложения использующего динамические библиотеки.

Грузите либы только динамически по сгенерированному софтово абсолютному пути

Поправка: *динамически только

Статически, естественно, можно линковаться свободно :)

Типо теперь читы к блокноту++ не подключить? А причем тут «ОНИ»?

Кто мешает этот пакет редактировать?

C точки зрения ОС, пакет – такая же директория как и остальные. :)

Если сотрудник ЦРУ может редактировать пакеты у тебя на компьютере и никто не способен ему помешать, то дыры в софте – наименьшая для тебя проблема.

При чём тут ЦРУ? Речь идёт о подмене dll, которую никто не мешает сделать в маке.

В винде и виндософте столько дыр, что мелкодисперсная сетка отдыхает.

https://www.opennet.ru/opennews/art.shtml?num=46267

Так как dmcrypt-get-device поставляется только в Debian и Ubuntu, лишь данные дистрибутивы подвержены проблеме.

О да! Сравнение хера и пальца.

Надо делать snap-пакет, упакованный разработчиком, в котором нельзя ничего менять.

да, два процесса, между ними пайп. Вся ценная инфа в одном, dll в другом

Речь идёт о подмене dll, которую никто не мешает сделать в маке.

Кажется, ты не вполне понял, как работает атака.

К тебе в руки попадает флешка, на которой есть папка с большим количеством текстовых файлов. Рядом с ними лежит незаметный файл SciLexer.dll. Ты открываешь какой-то текстовый в Notepad++, который (сюрприз!) загружает SciLexer.dll из той же папки. Всё потому, что в Windows по умолчанию текущий каталог находится в списке поиска. Файл открывается нормально, и ты думаешь, что ничего не произошло, но на самом деле, ты фактически запустил код с левой флешки.

Wut? Зачем он грузит dll из этой папки? Это сам notepad++ делает или винда?

Зачем он грузит dll из этой папки?

Я погуглил, и похоже, с DLL'ками я ошибся, спутал с EXE. Для DLL сначала проверяется «The directory from which the application loaded», а потом уже текущая директория. До Windows XP SP2 можно было так подсунуть какую-нибудь DLL'ку вместо системной. После SP2 текущую директорию переместили чуть ли не самый конец списка.

Правила довольно запутанные. Так что не исключено, что при удачном стечении обстоятельств и получится так библиотеку подсунуть.

Я знаю что винда ищет в системной папке и рядом с .exe

А вот про поиск в папке с файлом по ассоциации слышу впервые.

Ну мне когда-то запомнилось среди правил параноика — не открывать файлы из незнакомых источников просто кликая на них. Сначала запускаешь программу, а уже из неё открываешь файл. Причина как раз в том, что текущая директория есть списке поиска при загрузке DLL, и вирусня этим пользуется.

А сейчас вот узнал, что с Windows XP SP2 эту неимоверную дырень прикрыли.

Кажется я был не прав. Потестил прогу на Qt. QDir().absolutePath() выдает не рабочую папку, как ожидалось, а папку, в которой был файл, по которому кликнули.

Поэтому код вида: QFile("text.txt") прочтёт файл не из рабочей папки, а из той, в которой мы кликали.

Я впервые узнал о таком поведении...

PS: тестил на Win7

У LoadLibrary/LoadLibraryEx другие правила.

А если плагин грузится динамически?

Предлагаю посмотреть в https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms682586(v=vs.85).aspx. Там как-то сложно всё, есть условия.

Жуть. Под плагинами я понимал что-то типа QLibrary/QPluginLoader. Хз следуют ли он этим правилам. Если они работают тупо поверх QFile, тогда вариант типа QPluginLoader("myplugin.dll") сработает.