Евгений Касперский: По части эмуляции и анализа мы впереди планеты всей

Евгений Касперский: По части эмуляции и анализа мы впереди планеты всей

Евгений Касперский: По части эмуляции и анализа мы впереди планеты всей

Евгений Касперский в своём блоге углубился в анализ методов детектирования вредоносных программ. В частности, основатель и бессменный лидер «Лаборатории Касперского» особо выделил способ эмуляции, который, по его мнению, реализован у Kaspersky максимально эффективно.

Проведя аналогию с одной из сцен фильма «Миссия невыполнима», Евгений Валентинович объяснил: эмулятор запускает анализируемый объект в изолированной среде, чтобы тот проявил свои вредоносные функции.

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

«С другой стороны, есть ещё один способ отследить поведение объекта — виртуальная машина. Почему нет? Виртуализация знакома всем с 1992 года, почему же никому не пришло это в голову?», — пишет Касперский.

Оказалось, что и здесь есть свои проблемы. Во-первых, анализ объектов в виртуальной машине — ресурсоемкий процесс. Это больше подойдёт решениям, ориентированным на корпоративный сектор. Для домашних компьютеров, а тем более для смартфонов такая технология не годится.

А во-вторых, отмечает Касперский, «Лаборатория Касперского» уже использует такую технологию для внутренних расследований.

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

«Здесь я могу без ложной скромности сказать, что мы впереди планеты всей».

К слову, недавно «Лаборатория Касперского» получила в США патент (US10339301) за создание подходящей среды для виртуальной машины, которая может осуществлять глубокий и быстрый анализ подозрительных объектов.

По словам Касперского, скоро эта технология будет добавлена в KATA, а также выйдет на рынок в качестве отдельного решения для предприятий — Kaspersky Sandbox.

Баги в ядре 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