Security Week 37: патчи Windows станут кумулятивнее, Google против HTTP, уязвимость в MySQL16.09.2016 11:33

Очевидны и недостатки: возможности установки патчей по выбору больше не будет, все будет загружаться и ставиться одним куском. Если какой-то патч оказывается несовместим с установленным ПО или определенными настройками системы — можно будет отказаться только от всего ежемесячного апдейта сразу. Именно с установкой по выбору Microsoft и планирует бороться: ведь по сути такой подход приводит к фрагментации, вместо одной версии Windows приходится иметь дело чуть ли не с десятком, что усложняет и поддержку, и тестирование.

Впрочем, остается одна лазейка: кумулятивный патч включает в себя и обновления безопасности, и обновления, направленные на повышение надежности работы. Можно выбрать и устанавливать только security-фиксы и больше ничего, но эта опция рассчитана на клиентов из числа крупных компаний. Новая политика может выйти боком при использовании специализированного софта с жесткими требованиями по совместимости. Примеров, когда выход патча ломал совместимость немало: можно вспомнить проблемы с софтом от Citrix после апдейта Windows 10, или скажем поломку системы конфигурации через Powershell (вот тут интересный момент — по ссылке левая рука Microsoft жалуется на баги у правой).

Изменения политики обновлений Microsoft отражают текущее состояние битвы между надежностью и безопасностью. Максимально надежен софт, который не обновляется годами, он же максимально небезопасен. В ситуации, когда обнаружение новых уязвимостей (да и просто багов) неизбежно, приходится делать выбор, и Microsoft делает выбор в пользу защиты от взлома. Это похвально, но вот ведь любопытная ситуация получается: каждый месяц новый набор патчей для Android вновь поднимает тему фрагментации, а ведь на десктопах-то это куда более серьезная проблема. С точки зрения безопасности идеальный сценарий — это доставка обновлений (как минимум — заплаток) в момент их готовности (ну типа как в Gentoo). Именно такую стратегию, с регулярными взрывами недовольства пользователей, применяет, например, Facebook. Оба идеальных сценария (максимум надежности или максимум безопасности) недостижимы, но правильный баланс нужно искать. Не исключено, что тут пригодится опыт вендоров защитного софта: они в силу специфики работы рассылают обновления несколько раз в сутки уже много лет.

Раскрыта информация о критической уязвимости в Oracle MySQL и совместимых продуктах

Исследователь Давид Голунски из творческого объединения Legal Hackers на этой неделе частично раскрыл информацию о серьезной уязвимости в Oracle MySQL, которая также затрагивает зависимые продукты, в частности MariaDB и PerconaDB. Эта новость неплохо дополняет предыдущую и также поднимает вопрос о необходимости стандарта как для доставки патчей, так и для раскрытия информации об уязвимостях. Баг в MySQL (CVE-2016–6662, подвержены версии 5.7.15, 5.6.33 и 5.5.52) позволяет внедрять закладки в конфигурационные файлы СУБД, что в свою очередь может привести к выполнению произвольного кода во время ближайшего перезапуска. Уязвимость может быть задействована как при наличии доступа к серверу, так и удаленно, в случае небезопасной конфигурации системы (доступ на запись в конфиги у пользователя mysql).

Подробнее о сценарии (довольно нетривиальном) эксплуатации уязвимости можно почитать по ссылке выше. Важный момент заключается в том, что патчи у совместимого ПО уже есть, а вот для самой MySQL — пока нет, и видимо не будет до 18 октября. Дело в том, что Oracle выпускает заплатки на поквартальной основе, и до следующего релиза (предыдущий в июле закрыл 276 уязвимостей) ничего не произойдет. Возникает вопрос —, а почему собственно исследователь раскрыл информацию до выпуска патчей? Аргументация с этой стороны следующая: уязвимости закрыты в совместимом ПО (а значит злоумышленник может получить информацию об уязвимости, проанализировав изменения), а с момента отправки информации вендору прошло 40 дней.

40 дней — это в данном случае определенно не аргумент, а вот выпуск патчей одной дыры разными вендорами вразнобой пожалуй действительно представляет проблему. Получается, что все хороши. Добро пожаловать в дивный новый, крайне неритмичный мир безопасности программного обеспечения. Кстати, у Oracle нет публичной программы вознаграждения за найденные уязвимости, а в прошлом году CSO Oracle и вовсе нелестно отзывалась о вайт-хетах — мол, нечего ломать наши продукты без разрешения. Пост быстро удалили, но осадок остался.

Google Chrome будет помечать HTTP-only сайты как небезопасные

С января 2017 года Google Chrome начнет помечать сайты, обеспечивающие подключение только по незащищенному протоколу HTTP, как потенциально небезопасные. Сейчас Chrome отмечает эти сайты нейтрально (в отличие от безопасных проверенных подключений по HTTPS), но в Google справедливо считают, что ситуация должна измениться. Переход будет производиться в несколько этапов, и в январе небезопасными станут только те сайты, которые передают по HTTP пароли или данные кредиток (открытым текстом!), что, конечно, совсем уж за гранью добра и зла.

В посте команды Google интересен и такой момент: реакция пользователей на различные методы сортировки веб-сайтов была проверена исследованием, и, ожидаемо, внимание обращают только на явное сообщение о проблеме. Все остальные «вы знаете, тут может быть не все хорошо» игнорируются. Интересно, как часто игнорируются явные сообщения о небезопасности? Разработчики браузеров оказываются таким образом лицом к лицу с армией пользователей, которая вовсе не обязана разбираться в тонкостях сетевых протоколов. В результате приходится сводить многолетний опыт защиты информации в сети к чему-то очень простому и понятному:

Следующим этапом наступления на плейнтекстовый интернет станет предупреждение обо всех HTTP-сайтах в инкогнито-режиме, в котором пользователи, по идее, должны больше заботиться о приватности. И, наконец, в планах Google распространить политику на все HTTP-соединения для всех пользователей.

Что еще произошло:

Троян, маскирующийся под гид для Pokemon Go, протащили в Google Play. 500 000 загрузок.

И на закуску — утечка паролей из QIP открытым текстом.

Древности

Резидентный не опасный вирус. Поражает .COM-файлы при их загрузке в память. Изменяет первые 5 байт файла (MOV AX, Start_Virus; PUSH AX; RET near) и дописывается в его конец.

Активизируется только в DOS 3.30, определяет (сканированием памяти) точки входа обработчиков 13-го и 21-го прерывания в DOS и активно их использует при заражении файлов. Располагается в самых старших адресах памяти, корректируя последний MCB и уменьшая размер доступной памяти (слово по адресу 0000:0413).

При заражении ведет подсчет уже зараженных файлов, и как только встречается 30-й зараженный файл, устанавливает прерывание 8h на подпрограмму генерации звукового сигнала. Перехватывает int 8 и int 21h.

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 89.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Комментарии (0)