Security Week 31: уязвимость в VLC и испорченный телефон

    На прошлой неделе широко обсуждалась (новость) серьезная уязвимость в популярном медиаплеере VLC. Информация о проблеме была добавлена в реестр немецкого центра реагирования на угрозы CERT Bund и в американскую базу National Vulnerability Database. Изначально уязвимость CVE-2019-13615 получила рейтинг 9,8, то есть классифицировалась как максимально опасная.

    Проблема связана с ошибкой чтения за границами буфера в куче, которая может возникнуть при воспроизведении видеоролика. Если объяснять более человеческими словами, можно отправить жертве подготовленный файл .mkv и получить контроль над системой через выполнение произвольного кода. Такая новость является хорошим поводом поговорить о проблемах в софте, который вроде бы не несет серьезных рисков для вашего компьютера. Но не в этот раз: судя по всему, исследователь, сообщивший об уязвимости, ошибся и приписал свежей версии VLC проблему, существовавшую исключительно в его Linux-дистрибутиве. Поэтому сегодняшний пост посвящается взаимонепониманию и сенсационным заголовкам.

    Все началось пять недель назад с этого тикета в багтрекере VLC. Пользователь topsec (zhangwy) без дополнительных описаний залил файл .mp4, который вызывает падение плеера. Там это сообщение лежало некоторое время без внимания, пока информация об уязвимости каким-то образом (никто не знает, каким) попала в базы NIST NVD и CERT Bund. Уже после этого на багрепорт посмотрели разработчики — и не смогли воспроизвести атаку на свежей версии медиаплеера.


    Тем временем об уязвимости со ссылкой на CERT Bund написали СМИ, и там уже с заголовками никто не стеснялся. Удалите VLC прямо сейчас! Страшная уязвимость, для которой нет патча! Все очень плохо! В целом крупным организациям, ведущим реестр уязвимостей в софте, принято доверять. Но в этом случае нормальный процесс обнаружения проблемы и поиска решения для нее был нарушен.


    Что именно пошло не так, рассказали разработчики VideoLan в серии твитов в официальном аккаунте (рекомендуем прочитать весь тред, разработчики были очень злые и не стесняли себя в выражениях). Начнем с того, что VLC убедительно просит исследователей не репортить уязвимости в публичный трекер. По очевидным причинам: если обнаружится действительно серьезная проблема, у разработчиков должно быть время ее починить. Изначальный багрепорт юзера topsec попал именно в публичную часть трекера.


    Во-вторых, инициатор багрепорта не выходил на связь, когда у него пытались уточнить детали. В-третьих, мейнтейнеры базы NIST NVD добавили информацию об уязвимости и присвоили близкий к максимальному рейтинг опасности без консультаций с разработчиками VLC. Аналогичным образом поступил CERT Bund, после чего тему подхватили СМИ.

    А была ли уязвимость? Была! В библиотеке libebml, которая является частью открытого проекта Matroska.org. VLC действительно обращается к этой библиотеке при парсинге файлов в формате MKV, но используемые в эксплойте уязвимости были закрыты в версии 1.3.6 в апреле 2018 года. Начиная с версии 3.0.3 сам VLC применяет обновленную библиотеку. Понадобилось очень редкое сочетание относительно старой и, видимо, не обновляемой системы Ubuntu со старой библиотекой libebml и новым плеером, чтобы реализовать атаку. Понятно, что такая конфигурация у обычных пользователей маловероятна, и VLC тут в любом случае не при чем — уже больше года.


    Последнее сообщение от автора изначального багрепорта выглядит так: «Вы извините, если что». А вот реальная уязвимость с аналогичными свойствами была закрыта в актуальной на дату публикации дайджеста версии VLC 3.0.7. Она тоже содержалась в открытой библиотеке, используемой VLC, и приводила к выполнению произвольного кода при открытии подготовленного файла. Ее удалось обнаружить благодаря инициативе Европейского Союза по вознаграждению за уязвимости в популярных (и используемых госорганами) проектах с открытым исходным кодом. В список софта кроме VLC были включены Notepad++, Putty и FileZilla.

    В общем, безопасность — это разговор скорее о процессе, чем о результате. Качество этого процесса определяется не громкими заголовками в СМИ, а, в случае вашего персонального компьютера, как минимум регулярными апдейтами софта. Проблемы могут быть где угодно, и тот факт, что уязвимость в VLC оказалась ненастоящей, не отменяет необходимость постоянно обновлять программы. Даже те, которые вроде и так работают и не воспринимаются как опасные. В их число можно отнести, например, архиватор WinRAR, в котором несколько месяцев назад нашли очень древнюю критическую уязвимость. Отключать напоминалки об обновлении VLC тоже не стоит, хотя многие так делают. Относительно свежее исследование Avast в январе этого года показало, что актуальная на тот момент версия VLC была установлена всего у 6% пользователей.


    Разработчикам VLC в принципе не нравится практика, когда любой уязвимости с выполнением произвольного кода присваивают максимальный рейтинг опасности. В большинстве случаев реальная эксплуатация такой дыры затруднена: это надо жертве нужный файл (или ссылку на потоковое видео) отправить, и заставить открыть, и вызвать не просто падение программы, а выполнение кода, да еще и с нужными привилегиями, которые не факт, что можно получить. Это интересный теоретический вариант таргетированной атаки, но пока и вправду маловероятный.

    Disclaimer: Мнения, изложенные в этом дайджесте, могут не совпадать с официальной позицией «Лаборатории Касперского». Дорогая редакция вообще рекомендует относиться к любым мнениям со здоровым скептицизмом.
    «Лаборатория Касперского»
    357,31
    Ловим вирусы, исследуем угрозы, спасаем мир
    Поделиться публикацией

    Комментарии 1

      0

      Паника, паника, паника! В любой ситуации главное — спокойствие. Ну… если хочется действительно позитивного результата, а тут на лицо погоня за дешёвым хайпом.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое