Пользователи Google Chrome будут получать патчи в два раза быстрее

Пользователи Google Chrome будут получать патчи в два раза быстрее

Пользователи Google Chrome будут получать патчи в два раза быстрее

Разработчики Google, работающие над устранением уязвимостей в Chrome, сообщили, что им удалось уменьшить так называемое «окно патчинга» (patch gap) — с 33 до 15 дней. Термин patch gap описывает промежуток времени между устранением уязвимости и доставкой патча пользователям.

В современных условиях разработки программ подобная задержка в доставке патчей расценивается как серьёзная угроза безопасности.

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

В дальнейшем злоумышленники могут использовать эту информацию для создания соответствующего эксплойта. Пока пользователи не получат патч, они остаются в зоне риска — все атаки на уязвимый компонент позволят преступникам проникнуть на целевое устройство.

У разработчиков, как правило, график обновлений чётко спланирован — они могут выходить каждые две недели или каждый месяц. Именно это окно наиболее критично для атак.

В этом смысле Chrome был как раз характерным образцом проблемного патчинга. Например, в 2019 году исследователи из Exodus заявили, что киберпреступники могут использовать большое окно перед выходом патчей для браузера.

Теперь же, по словам разработчиков, вышеупомянутое окно до выхода патчей для Chrome сократится до двух недель.

Вышла утилита RKN Block Checker для диагностики блокировок

Разработчик Дмитрий Виноградов представил утилиту RKN Block Checker с открытым исходным кодом. Она помогает понять, почему конкретный сайт не открывается: это обычная сетевая проблема или блокировка на стороне провайдера / регуляторной инфраструктуры.

Проект написан на Python и опубликован под лицензией MIT. Утилита работает из командной строки и проверяет соединение по цепочке DNS → TCP → TLS → HTTP.

Идея простая: не просто выдать вердикт, что сайт недоступен, а показать, на каком именно уровне всё сломалось. Например, если системный DNS не даёт нормальный ответ, а Cloudflare DoH возвращает корректный адрес, это может указывать на DNS-подмену. Если TCP-соединение на 443-й порт сбрасывается, речь может идти о блокировке на уровне IP.

Если TCP проходит, но соединение рвётся на TLS-рукопожатии с SNI, это уже похоже на работу DPI / ТСПУ. А если сайт открывается, но вместо страницы приходит заглушка провайдера или код 451, утилита фиксирует и такой сценарий.

 

Автор отдельно подчёркивает, что смысл RKN Block Checker не в том, чтобы заменить браузер. Браузер и так сообщает, что сайт не открылся. Здесь задача другая — разложить проблему по слоям и дать пользователю более понятную картину, где именно произошёл сбой и на что это похоже.

Утилита сравнивает ответы системного DNS и DNS over HTTPS через Cloudflare, проверяет обычное TCP-подключение, запускает TLS-handshake с SNI целевого домена и затем делает HTTP-запрос. Вердикт выставляется по первому уровню, на котором возникла ошибка.

 

У проекта есть и ограничения. Пока поддерживается только IPv4. Списки целей жёстко заданы в коде и включают около 20 сайтов на категорию, поэтому инструмент не поймает все частные случаи. Кроме того, это разовая проверка без повторов и долгосрочного мониторинга, хотя JSON-вывод можно использовать в cron для регулярных запусков.

RSS: Новости на портале Anti-Malware.ru