Yahoo! случайно опубликовала свой сертификат цифровой подписи

Yahoo! случайно опубликовала свой сертификат цифровой подписи

Сегодня Yahoo! выпустив новый обозреватель Axis опубликовала сертификат, который является цифровой подписью для продукции компания; обозреватель предназначен для iPhone и iPad. Однако есть версии программы, которые могут быть использованы в качестве плагинов для обозревателей Chrome, Firefox, Internet Explorer и Safari.

Axis была создана в помощь тем, кто активно используют сервисы Yahoo! для поиска и оформления заказов в интернет-магазинах. Однако не прошло и нескольких часов, как австралийский исследователь в области безопасности сообщил об уязвимости.

Как оказалось, в Yahoo! перед выпуском приложения не проверили продукт на наличие уязвимостей. В данном случае такой ошибкой стала невнимательность, благодаря которой вместе с версией плагина для обозревателя Chrome  был опубликован конфиденциальный сертификат. Такой сертификат обычно является своеобразной "визитной карточкой" компании, и во время установки приложение проходит соответствующую верификацию. В случае, если приложение не имеет цифровой подписи изготовителя, оно будет определено как поддельное.

Как отмечает исследователь, в пакете с программой был обнаружен файл сертификата, который при установке на созданное им приложение не потребовал ни пароля, ни другой идентификационной информации, используемой для защиты ключа от несанкционированного доступа. Таким образом, получив в распоряжение такой сертификат, злоумышленник может подписать им свою разработку и распространять как легитимный плагин. В доказательство, эксперт продемонстрировал работу ключа. Он создал программу, которая перехватывает весь трафик, включая пароли доступа, файлы сессии и прочие конфиденциальные данные и подписал ее добытым сертификатом.

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

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

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

Важно уточнить: речь идёт о багах в целом, а не только об уязвимостях. Лишь 158 ошибок из всей выборки получили CVE, остальные могли приводить к сбоям, нестабильности или неопределённому поведению, но не обязательно к эксплуатации.

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

Оказалось, что скорость обнаружения ошибок сильно зависит от подсистемы ядра:

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

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

Отдельная проблема — неполные фиксы. Исследование показывает, что нередко разработчики закрывают проблему лишь частично. Например, в 2024 году был выпущен патч для проверки полей в netfilter, но уже через год исследователь нашёл способ его обойти.

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

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