1. Ну здесь я вижу возможные причины для обоих вариантов. MS должны были выбрать один — я не могу судить о настоящих причинах, побудивших их выбрать данный конкретный вариант (хотя если бы такое решение зависело от меня, я бы, пожалуй, сделал так же).
2. Ну да. Таргетированные (с очень ограниченным распространением) атаки вполне могут долго оставаться незамеченными. Ботнеты же очень быстро попадают в honeynet-ы и блокируются первым же апдейтом антивирусных баз.
На моей памяти все более менее заметные ботнеты использовали или какой нибудь вариант соц. инженерии («запусти, это мини-игра») или уязвимости, запатченные несколько месяцев назад. И то и другое — вообще не Windows-специфично.
Более того, как раз в винде средства безопасности реализованы лучше всего.
Но это никаким образом не приближает нас к исходной посылке о том, какой плохой Microsoft.
1. Ну я не могу ответить за MS. В любом случае я вижу только одну кривую программу, имеющую отличимую от нуля популярность — iTunes. Большинство остального — скорее всего какие нибудь in-house быдлопрограммы, выпустить shim-ы для которых будет проблематично и при этом беспокоиться о безопасности таких программ не приходится.
2. Не могу проверить информацию про «во всю используются». Скорее речь шла про responsible disclosure (или, как оно теперь называется, CVD).
Кстати, у MS есть достаточно неплохие средства для телеметрии использования уязвимости in-the-wild, так что выбор стоит между «Сообщить той сотне-тысяче пользователей всю информации и пара процентов из них самостоятельно предпримет какие то шаги» и «Не сообщать до выпуска патча и не ставить под удар МИЛЛИАРД остальных пользователей». Общепринятая практика даже при меньших масштабах.
Если посмотреть на историю msblast, sasser, conficker (и большинство остальных нашумевших эпидемий) начинались через МЕСЯЦЫ после выпуска патча (собственно сами уязвимости, использованные в этих червях, были получены реверсингом патчей). То есть пользователи уведомлены и им предоставлены средства для того, чтобы обезопасить себя, им на каждом углу трубят об эпидемии, чтоб защититься от которой нужно всего лишь применить патч — а они все игнорируют.
1. «Зачем оставлять это включённым по умолчанию?»
Как раз потому, что если приложение УЖЕ делает что-то нестандартное (загружает dll-ку из PATH), то неявная смена поведения скорее «поломает» это приложение насовсем, чем «починит» уязвимость в нем.
2. Передергивания здесь нет. Office двух последних версий (минимум) не загружает PoC.
Что же до уязвимостей. К превеликому сожалению, не могу проверить Ваши слова.
По первой ваши же ссылки ведут на CVE, idefence, vupen и прочая. Все как один датированы июлем 2009. Более того, я нашел эту уязвимость на секунии и увидел все тот же «Release Date 2009-07-14». Не могли бы Вы привести ссылки на disclosure летом 2008-го?
По второй «Release Date 2009-08-11», закрыта 14-го.
На всякий случай отмечу, что открытие деталей об уязвимости вместе с патчем — общепринятая практика. Вы же утверждали, что MS (месяцами) официально не признает disclosed уязвимости — не могли бы Вы привести более убедительные ссылки?
Вот с Apple — знаю, с Microsoft — не знаю (но могу и просто заблуждаться).
1. Да. Но загрузка чего нибудь не из системной директории и не из одной директории с исполняемым файлом — КРАЙНЕ редкая вещь в мире Windows. И именно для таких случаев сделан SetDllDirectory
2. Я не о том подтверждении. Официально-то как раз все подтверждено (кстати, интереса ради, не затруднит привести ссылку на уязвимость, «известную всем, кроме Microsoft»?). Я о других подтверждениях в этом топике (Word 2010 и 2007 не загружают PoC dll-ку).
1. Режим по умолчанию, как я уже сказал, не загружает из текущей директории то, что есть в системных или директории, из которой запущено приложение.
2. Уязвимость не подтверждена, если Вы об офисе. Кроме того, сомневаюсь, что там «не могут» (не разобрались) использовать нормальное API и вместо этого меняют текущую директорию каждый раз перед LoadLibrary. Если Вы не об этом — прошу раскрыть свою мысль.
1. Совместимость. И да, по умолчанию, ее ОЧЕНЬ трудно использовать (но эппл смогли — молодцы).
2. Вы тоже «не читатель»? Я даже процитировал слова LeBlanc.
If you cannot do that, here's a code sample that will fix individual calls for you.
Это не для всех. Это только для тех, кто почему то (почему?) не может использовать нормальное API.
Ну iTunes вон умудрились и текущий путь сменить и делать LoadLibrary на библиотеки, не присутсвтующие нигде, выше «текущей» в Вашем списке. Виноват, естественно, Microsoft.
API от MS удивляли? Ну ладно, в данном случае, это просто «авторская интерпретация» собственных же ссылок. Но хотелось бы услышать с чем Вы сравниваете (чтоб не приводить примеры «мимо кассы»).
А при чем здесь Microsoft? Сменить текущую директорию конечно же существенно проще, чем LD_LIBRARY_PATH или LD_PRELOAD.
Автор поста не читатель — автор писатель, ведь его же собственная ссылка указывает на best practices, которые английским по белому указывают на SetDllDirectory:
If this parameter is an empty string (""), the call removes the current directory from the default DLL search order.
А пост LeBlanc, из котого автор вытащил кусок кода, прямым текстом заявляет:
Note that if you can call SetDllDirectory(""), as I documented in my previous post, then you should do that, as it is easier and will solve the problem for all your LoadLibrary calls. If you cannot do that, here's a code sample that will fix individual calls for you.
О чем автор, предусмотрительно, «забыл» упомянуть, подразумевая, что тот быдлокод обязателен для всех разработчиков.
А начинается все со страшилок про то, что существует уязвимость, которая не менее опасна, чем недавно запатченная RCE, но известная как минимум два года и нигде не использующаяся. Удаленный вектор крайне трудно реализуем (drive-by не работает: пользователю нужно вручную сменить текущую директорию на что-нибудь, контроллируемое злоумышленником и запустить оттуда файл).
И это не говоря про довольно вольное понимание автором термина «архитектура» и о том, что общесистемный патч для тех, кому это нужно уже выпущен (но рекомендовано применять его крайне осторожно, потому что это может нарушить совместимость с некоторыми приложениями).
Пост надо переименовать в «По стопам alizar: художественное искажение фактов for fun and profit».
Это не обновления. Это именно support. Даже если взять 5 лет базовой поддержки плюс по два года с момента выхода последнего сервис пака (для той же XP базовая поддержка закончилась лишь недавно — XPSP3 был выпущен в апреле 2008-го — а это почти 10 лет поддержки, включенной в стоимость самого продукта).
Точность на TSC-invariant машинах (большинство серверных процессоров на сегодняшний день) будет до инструкции (на не tsc-invariant придется немного повычислять смещения). Дисковые операции подбирайте из Windows Kernel Trace, сеть — из Microsoft-Windows-NDIS, память скорее всего придется тащить hypercall-ами, но полмиллисекунды на гипервызов — это какой то слишком пессимистичный сценарий (тем более, что не обязательно делать их последовательно и с одного процессора).
Мне сырцы нужны для того, чтобы реализовывать свой функционал при работе с гипервизорами
То есть о дизайне (в частности Open/closed principle) Вы не слышали? Ну в общем не удивительно, что Вам нравится линукс — там наличие дизайна не приветствуется.
Могу я такое сделать в hyper-v?
Можете.
Нет.
А ну да. Я забыл. ВЫ не можете
Почему?
Подозреваю потому, что у Вас недостаточно квалификации и чересчур много предвзятости.
Ну и рассуждения, что линукс же ставят в качестве серверов на атлоны-под-столом выглядят забавно, учитывая, что у MS есть VL — и там тоже никто не учитывает проданных копий (или Вы считаете, что KMS появился специально для того, чтоб китайцы могли помочь обойти активацию?)
Как мило. Premium Subscription
24x7 phone support, web support, unlimited incidents 1 Year $2,499
Windows Server 2008 R2 Enterprise 10/22/2009 7/9/2013 7/10/2018
5 лет базовой поддержки + 5 лет расширенной. Это не считая того, что сервис паки имеют отдельный support lifecycle
Ну а как по мне, правильные «исправления» пошли по другой ветке: VMS -> NT.
Ибо внутренняя простота и элегантность ОС уже давно никого не волнует.
Меня волнует. И именно поэтому я использую Windows.
И в любом случае даже уродливый и переусложнённый POSIX...
Ой, вот не нужно подменять понятия. В винде есть несколько унифицированных API для доступа к данным, в юниксах — нет вообще (есть отдельные врапперы для каждого отдельного языка программирования). Техническое поражение — команда не явилась на игру. Если уж сравнивать POSIX с чем нибудь, так это с Native API (которое одновременно и несравнимо полнее и несравнимо «стройнее»). А если говорить о Win32 API, то и сравнивать нужно с зоопарком *никсовых usermode библиотек (разных не только в разных ОС, но зачастую имеющих кучу разных версий под одну ОС).
Что касается sed/awk/xargs — я не вижу в их применении никакой трагедии
Сериализация в формат, не допускающий однозначной десериализации и собственный для каждой утилиты? Хм, действительно — никаких проблем.
Тем более, что на практике в большинстве случаев в большом конвейере на 4-5 строчек применять sed/awk приходится пару-тройку раз, а не между любыми двумя командами
Только потому, что многие команды научились избегать пайпов или практически не выполняют обработки (типа того же cat).
M$
Сколько еще классов до поступления в институт?
попыталась решить эту проблему в powershell, передавая в канале объекты, но IMHO от этого легче, проще, лучше и удобнее писать конвейеры не стало.
Во-первых, компонентизация за счет объектов была в винде ЗАДОЛГО до powershell (лет 15 как минимум), а во-вторых таки стало. Пайп выглядит ИМЕННО как: ps | select | kill
Комбайны вроде pgrep/pkill и тонны опций у cat и ls появляются зачастую потому, что многие не пытаются следовать описанным в статье принципам
Ну ОК, давайте Вы приведете пример ps-grep-kill на чистом sh (следуя всем правилам), а мы сравним это с pkill (и с парой вариантов на PS, если захочется). pkill сотоварищи действительно появляются потому, что люди не хотят следовать некоторым юникс правилам, а не не хотят они потому, что не враги себе.
почему все ругаются на сетевую составляющую иксов
Потому что она плохо себя зарекомендовала для сетевого доступа (все пользуются компрессированными vnc/rdp), и создает кучу проблем для локального доступа (уже упоминавшиеся здесь MIT-SHM и DRI как раз ОБХОДЯТ сетевую составляющую иксов, чтоб выжать производительности). Более того, давно и успешно разрабатываются всякие библиотеки, типа нотификаторов в трее, которые используют чисто локальные штуки типа d-bus. Вот и получится, что x-сервер у Вас будет на одном компьютере, а трей — будет отображаться (если будет) локально на машине с клиентом. В общем овердизайн в чистом виде.
Сетевая составляющая pulseaudio — очень хорошая фишкаНе совсем. Это наружение слоистоисти же. Слой который отвечает за вывод и микширование звука не должен знать, как к нему этот самый звук приходит. А TCP/UDP стриминг PCM звука — не совсем то, что нужно подавляющему большинству пользователей.
Вы упускаете из виду тот факт, что после того, как память добавлена — она менеджится балунингом. Соответственно, очевидная причина для использования хотплага — выход на steady state по размеру пузыря вместо использования сразу максимального.
2. Ну да. Таргетированные (с очень ограниченным распространением) атаки вполне могут долго оставаться незамеченными. Ботнеты же очень быстро попадают в honeynet-ы и блокируются первым же апдейтом антивирусных баз.
На моей памяти все более менее заметные ботнеты использовали или какой нибудь вариант соц. инженерии («запусти, это мини-игра») или уязвимости, запатченные несколько месяцев назад. И то и другое — вообще не Windows-специфично.
Более того, как раз в винде средства безопасности реализованы лучше всего.
Но это никаким образом не приближает нас к исходной посылке о том, какой плохой Microsoft.
2. Не могу проверить информацию про «во всю используются». Скорее речь шла про responsible disclosure (или, как оно теперь называется, CVD).
Кстати, у MS есть достаточно неплохие средства для телеметрии использования уязвимости in-the-wild, так что выбор стоит между «Сообщить той сотне-тысяче пользователей всю информации и пара процентов из них самостоятельно предпримет какие то шаги» и «Не сообщать до выпуска патча и не ставить под удар МИЛЛИАРД остальных пользователей». Общепринятая практика даже при меньших масштабах.
Если посмотреть на историю msblast, sasser, conficker (и большинство остальных нашумевших эпидемий) начинались через МЕСЯЦЫ после выпуска патча (собственно сами уязвимости, использованные в этих червях, были получены реверсингом патчей). То есть пользователи уведомлены и им предоставлены средства для того, чтобы обезопасить себя, им на каждом углу трубят об эпидемии, чтоб защититься от которой нужно всего лишь применить патч — а они все игнорируют.
Как раз потому, что если приложение УЖЕ делает что-то нестандартное (загружает dll-ку из PATH), то неявная смена поведения скорее «поломает» это приложение насовсем, чем «починит» уязвимость в нем.
2. Передергивания здесь нет. Office двух последних версий (минимум) не загружает PoC.
Что же до уязвимостей. К превеликому сожалению, не могу проверить Ваши слова.
По первой ваши же ссылки ведут на CVE, idefence, vupen и прочая. Все как один датированы июлем 2009. Более того, я нашел эту уязвимость на секунии и увидел все тот же «Release Date 2009-07-14». Не могли бы Вы привести ссылки на disclosure летом 2008-го?
По второй «Release Date 2009-08-11», закрыта 14-го.
На всякий случай отмечу, что открытие деталей об уязвимости вместе с патчем — общепринятая практика. Вы же утверждали, что MS (месяцами) официально не признает disclosed уязвимости — не могли бы Вы привести более убедительные ссылки?
Вот с Apple — знаю, с Microsoft — не знаю (но могу и просто заблуждаться).
2. Я не о том подтверждении. Официально-то как раз все подтверждено (кстати, интереса ради, не затруднит привести ссылку на уязвимость, «известную всем, кроме Microsoft»?). Я о других подтверждениях в этом топике (Word 2010 и 2007 не загружают PoC dll-ку).
2. Уязвимость не подтверждена, если Вы об офисе. Кроме того, сомневаюсь, что там «не могут» (не разобрались) использовать нормальное API и вместо этого меняют текущую директорию каждый раз перед LoadLibrary. Если Вы не об этом — прошу раскрыть свою мысль.
2. Вы тоже «не читатель»? Я даже процитировал слова LeBlanc.
Это не для всех. Это только для тех, кто почему то (почему?) не может использовать нормальное API.
Уточню: запустить оттуда файл, ассоциированный с уязвимым приложением.
Автор поста не читатель — автор писатель, ведь его же собственная ссылка указывает на best practices, которые английским по белому указывают на SetDllDirectory:
А пост LeBlanc, из котого автор вытащил кусок кода, прямым текстом заявляет:
О чем автор, предусмотрительно, «забыл» упомянуть, подразумевая, что тот быдлокод обязателен для всех разработчиков.
А начинается все со страшилок про то, что существует уязвимость, которая не менее опасна, чем недавно запатченная RCE, но известная как минимум два года и нигде не использующаяся. Удаленный вектор крайне трудно реализуем (drive-by не работает: пользователю нужно вручную сменить текущую директорию на что-нибудь, контроллируемое злоумышленником и запустить оттуда файл).
И это не говоря про довольно вольное понимание автором термина «архитектура» и о том, что общесистемный патч для тех, кому это нужно уже выпущен (но рекомендовано применять его крайне осторожно, потому что это может нарушить совместимость с некоторыми приложениями).
Пост надо переименовать в «По стопам alizar: художественное искажение фактов for fun and profit».
Точность на TSC-invariant машинах (большинство серверных процессоров на сегодняшний день) будет до инструкции (на не tsc-invariant придется немного повычислять смещения). Дисковые операции подбирайте из Windows Kernel Trace, сеть — из Microsoft-Windows-NDIS, память скорее всего придется тащить hypercall-ами, но полмиллисекунды на гипервызов — это какой то слишком пессимистичный сценарий (тем более, что не обязательно делать их последовательно и с одного процессора).
То есть о дизайне (в частности Open/closed principle) Вы не слышали? Ну в общем не удивительно, что Вам нравится линукс — там наличие дизайна не приветствуется.
Могу я такое сделать в hyper-v?
Можете.
Нет.
А ну да. Я забыл. ВЫ не можете
Почему?
Подозреваю потому, что у Вас недостаточно квалификации и чересчур много предвзятости.
Потому что MS решила, что это не нужно.
Нет.
Что именно Вам непонятно в словосочетании «Installed Base»?
Ну и рассуждения, что линукс же ставят в качестве серверов на атлоны-под-столом выглядят забавно, учитывая, что у MS есть VL — и там тоже никто не учитывает проданных копий (или Вы считаете, что KMS появился специально для того, чтоб китайцы могли помочь обойти активацию?)
Premium Subscription
24x7 phone support, web support, unlimited incidents
1 Year $2,499
Windows Server 2008 R2 Enterprise 10/22/2009 7/9/2013 7/10/2018
5 лет базовой поддержки + 5 лет расширенной. Это не считая того, что сервис паки имеют отдельный support lifecycle
Вы бы хоть постеснялись так врать то.
Меня волнует. И именно поэтому я использую Windows.
Ой, вот не нужно подменять понятия. В винде есть несколько унифицированных API для доступа к данным, в юниксах — нет вообще (есть отдельные врапперы для каждого отдельного языка программирования). Техническое поражение — команда не явилась на игру. Если уж сравнивать POSIX с чем нибудь, так это с Native API (которое одновременно и несравнимо полнее и несравнимо «стройнее»). А если говорить о Win32 API, то и сравнивать нужно с зоопарком *никсовых usermode библиотек (разных не только в разных ОС, но зачастую имеющих кучу разных версий под одну ОС).
Сериализация в формат, не допускающий однозначной десериализации и собственный для каждой утилиты? Хм, действительно — никаких проблем.
Только потому, что многие команды научились избегать пайпов или практически не выполняют обработки (типа того же cat).
Сколько еще классов до поступления в институт?
Во-первых, компонентизация за счет объектов была в винде ЗАДОЛГО до powershell (лет 15 как минимум), а во-вторых таки стало. Пайп выглядит ИМЕННО как: ps | select | kill
Ну ОК, давайте Вы приведете пример ps-grep-kill на чистом sh (следуя всем правилам), а мы сравним это с pkill (и с парой вариантов на PS, если захочется). pkill сотоварищи действительно появляются потому, что люди не хотят следовать некоторым юникс правилам, а не не хотят они потому, что не враги себе.
Потому что она плохо себя зарекомендовала для сетевого доступа (все пользуются компрессированными vnc/rdp), и создает кучу проблем для локального доступа (уже упоминавшиеся здесь MIT-SHM и DRI как раз ОБХОДЯТ сетевую составляющую иксов, чтоб выжать производительности). Более того, давно и успешно разрабатываются всякие библиотеки, типа нотификаторов в трее, которые используют чисто локальные штуки типа d-bus. Вот и получится, что x-сервер у Вас будет на одном компьютере, а трей — будет отображаться (если будет) локально на машине с клиентом. В общем овердизайн в чистом виде.
Сетевая составляющая pulseaudio — очень хорошая фишкаНе совсем. Это наружение слоистоисти же. Слой который отвечает за вывод и микширование звука не должен знать, как к нему этот самый звук приходит. А TCP/UDP стриминг PCM звука — не совсем то, что нужно подавляющему большинству пользователей.