На прошлой неделе широко обсуждалась () серьезная уязвимость в популярном медиаплеере VLC. Информация о проблеме была добавлена в реестр немецкого центра реагирования на угрозы и в американскую базу . Изначально уязвимость CVE-2019-13615 получила рейтинг 9,8, то есть классифицировалась как максимально опасная.
Проблема связана с ошибкой чтения за границами буфера в куче, которая может возникнуть при воспроизведении видеоролика. Если объяснять более человеческими словами, можно отправить жертве подготовленный файл .mkv и получить контроль над системой через выполнение произвольного кода. Такая новость является хорошим поводом поговорить о проблемах в софте, который вроде бы не несет серьезных рисков для вашего компьютера. Но не в этот раз: судя по всему, исследователь, сообщивший об уязвимости, ошибся и приписал свежей версии VLC проблему, существовавшую исключительно в его Linux-дистрибутиве. Поэтому сегодняшний пост посвящается взаимонепониманию и сенсационным заголовкам.
Все началось пять недель назад с в багтрекере VLC. Пользователь topsec (zhangwy) без дополнительных описаний залил файл .mp4, который вызывает падение плеера. Там это сообщение лежало некоторое время без внимания, пока информация об уязвимости каким-то образом (никто не знает, каким) попала в базы NIST NVD и CERT Bund. Уже после этого на багрепорт посмотрели разработчики — и не смогли воспроизвести атаку на свежей версии медиаплеера.
Что именно пошло не так, рассказали разработчики VideoLan в серии твитов в официальном аккаунте (рекомендуем прочитать весь , разработчики были очень злые и не стесняли себя в выражениях). Начнем с того, что VLC убедительно исследователей не репортить уязвимости в публичный трекер. По очевидным причинам: если обнаружится действительно серьезная проблема, у разработчиков должно быть время ее починить. Изначальный багрепорт юзера topsec попал именно в публичную часть трекера.
А была ли уязвимость? Была! В библиотеке , которая является частью открытого проекта . VLC действительно обращается к этой библиотеке при парсинге файлов в формате MKV, но используемые в эксплойте уязвимости были закрыты в версии 1.3.6 в апреле 2018 года. Начиная с версии 3.0.3 сам VLC применяет обновленную библиотеку. Понадобилось очень редкое сочетание относительно старой и, видимо, не обновляемой системы Ubuntu со старой библиотекой libebml и новым плеером, чтобы реализовать атаку. Понятно, что такая конфигурация у обычных пользователей маловероятна, и VLC тут в любом случае не при чем — уже больше года.
В общем, безопасность — это разговор скорее о процессе, чем о результате. Качество этого процесса определяется не громкими заголовками в СМИ, а, в случае вашего персонального компьютера, как минимум регулярными апдейтами софта. Проблемы могут быть где угодно, и тот факт, что уязвимость в VLC оказалась ненастоящей, не отменяет необходимость постоянно обновлять программы. Даже те, которые вроде и так работают и не воспринимаются как опасные. В их число можно отнести, например, архиватор WinRAR, в котором несколько месяцев назад нашли очень древнюю . Отключать напоминалки об обновлении VLC тоже не стоит, хотя многие так делают. Относительно свежее исследование Avast в январе этого года , что актуальная на тот момент версия VLC была установлена всего у 6% пользователей.
Разработчикам VLC в принципе не нравится практика, когда любой уязвимости с выполнением произвольного кода присваивают максимальный рейтинг опасности. В большинстве случаев реальная эксплуатация такой дыры затруднена: это надо жертве нужный файл (или ссылку на потоковое видео) отправить, и заставить открыть, и вызвать не просто падение программы, а выполнение кода, да еще и с нужными привилегиями, которые не факт, что можно получить. Это интересный теоретический вариант таргетированной атаки, но пока и вправду маловероятный.
Disclaimer: Мнения, изложенные в этом дайджесте, могут не совпадать с официальной позицией «Лаборатории Касперского». Дорогая редакция вообще рекомендует относиться к любым мнениям со здоровым скептицизмом.
