Как я могу избежать уязвимости Quicktime с файлами MP4, закодированными в формате h.264?

Я разместил это ранее на SuperUser, но понял, что это, вероятно, более подходящий форум для моего вопроса.

У нас есть несколько тысяч очень больших файлов MP4, которые были закодированы за последнее десятилетие с помощью Sorenson Squeeze. За последний год внезапно выросло число клиентов (университетов) с сетевым/прокси-сервером, которые внезапно не могут просматривать видео из-за уязвимости, описанной по этой ссылке: Уязвимость Apple QuickTime .

Простите, я очень мало знаю о медиа и кодировании, только то, что проблема внезапно начала появляться, когда они просматривают наши видео (мы используем JWPlayer v7 с файлами, размещенными на AWS/S3/Cloudfront).

Есть ли альтернативный способ кодирования h.264/MP4, который не включает какие-либо ссылки или кодеки или что-то еще, что помечает их как файлы Quicktime, или какой-либо другой способ обойти это?

Примечание. Наш сайт транслирует файлы MP4 в формате h.264 с помощью JWPlayer — конечные пользователи не открывают их с помощью Apple Quicktime.

Partial ffmpeg Output for one of the videos in question:

"format": {
    "filename": "c:\\videos\\ABC-123.mp4",
    "nb_streams": 4,
    "nb_programs": 0,
    "format_name": "mov,mp4,m4a,3gp,3g2,mj2",
    "format_long_name": "QuickTime / MOV",
    "start_time": "0.000000",
    "duration": "1632.480000",
    "size": "86937415",
    "bit_rate": "426038",
    "probe_score": 100,
    "tags": {
        "major_brand": "mp42",
        "minor_version": "0",
        "compatible_brands": "mp42isomavc1",
        "creation_time": "2011-07-13 14:02:44",
        "compilation": "0",
        "encoder": "Sorenson Squeeze 5.0"
    }
Знаете ли вы, какие бренды брандмауэров создают эту проблему? У вас есть способ проверить, пройдет ли новый файл или нет?
Насколько я могу судить, уязвимость связана с работой проигрывателя Apple Quicktime версии 7.6.6 или старше в Windows , а не JWPlayer в Интернете. Как вы определили уязвимость как релевантную?
На самом деле я не могу воспроизвести это, все клиенты дают нам один и тот же отчет. Наш веб-сервер - это окна, но я, конечно, не знаю, что такое все клиентские сети. Я знаю, что это расплывчато, но я не гуру СМИ ИЛИ сетей, поэтому я барахтаюсь как таковой.
Я просто пропустил деталь aws. Вы перекодируете видео с помощью AWS Elastic Transcoder ? Вы предоставляете их в виде прогрессивной загрузки или потоковой передачи? Также было бы полезно иметь фактическую ошибку брандмауэра, версию браузера пользователя и системы, а также код для встраивания вашего jwplayer.
Я думаю, было бы полезно спросить ваших клиентов, какая именно уязвимость вызывает срабатывание их брандмауэров. Быстрый поиск в Google выдал около 3-4 серьезных эксплойтов в QuickTime за последние пару лет, которые, похоже, используют разные недостатки. Если это произошло недавно, я предполагаю, что они имеют в виду этот эксплойт, а не тот, на который вы ссылаетесь, который датируется 2010 годом .
В любом случае, я нахожу требование клиентов немного странным: у них установлено уязвимое программное обеспечение (а может и нет, но их брандмауэр хочет защитить их возможные устаревшие клиенты QuickTime). В ваших файлах нет ничего вредоносного.
Кроме того, поскольку у вас есть rtmp в тегах ваших вопросов, я предполагаю, что вы используете какой-то потоковый сервер? Или вы просто делаете псевдопотоки http?
Они используют нашу страницу JWPlayer с потоковой передачей RTMP от AWS. Клиенты в основном говорят, исправьте это, иначе мы не будем это покупать… (заказы на сумму от 10 до 50 тысяч долларов)
Я не знаю, может ли AWS это сделать или дорого будет процессорное время, но вы всегда можете в реальном времени перекодировать файлы в другой формат, пока клиенты не придут в себя и не поймут, что проблема в их игроках, а не ваши потоки.
Или проверьте это, они утверждают, что могут транскодировать быстрее, чем кто-либо другой, в том числе из AWS ... Я думаю, ваша проблема должна исчезнуть, если у вас есть все ваши файлы, то есть в WebM или mpeg dash ... по крайней мере, до эксплойта срабатывает с файлами WebM. bitcodin.com/blog/2015/02/…
Однако вся эта идея нелепа, поскольку вы просто будете обходить их странные представления о безопасности, поскольку любой формат видео может быть использован для запуска уязвимости в каком-либо проигрывателе, и они не могут исключить их все, если только они не считают просмотр видео через Интернет небезопасным. се.
Перекодирование может быть единственным ответом, но в прошлый раз, когда мы делали это с MP4, на создание всей коллекции ушло почти 2 месяца - задействовано 12000 полнометражных фильмов, поэтому мы ищем альтернативные решения. Если бы это была всего пара клиентов, ничего страшного, но каждый месяц мы получаем все больше и больше обращений в службу поддержки и отмен из-за проблемы.
Я думаю, что, возможно, легче добиться "легального" решения этой проблемы. Как говорится в описании эксплойтов, вредоносный видеофайл должен быть специально создан для использования уязвимости в уязвимых проигрывателях. Если ваша платформа закрыта для публики, и вы можете гарантировать, что ни один злонамеренно созданный видеофайл не сможет проникнуть в вашу коллекцию, этого должно быть достаточно для их уверенности или нет? Тогда они смогут занести ваш сервис в белый список на своих брандмауэрах. Насколько я вижу, реальной альтернативы нет, если вы будете искать WebM и эксплойты, вы также найдете инциденты, поэтому я гу
@ Ганс, они смотрят видео на нашей веб-странице с помощью JWPlayer - является ли проигрыватель QT частью уравнения? Манифест файла в сценарии JWP блокируется между их браузером и нашим сервером (предположительно, с их прокси-сервером)
И то же самое может произойти с Mpeg dash, даже если на данный момент нет сообщений об уязвимости. Так что в следующем месяце они могут сказать, что заблокируют WebM или mpeg dash...
Нет! Насколько я вижу, проигрыватель QuickTime не является частью процесса. Вы используете jwplayer в режиме flash или html5?
Flash/Falback по умолчанию для HTML5 - это происходит только с RTMP
Тогда я совершенно не понимаю озабоченность клиентов. По-видимому, внутренне Safari использует quicktime в качестве проигрывателя при использовании видеообъектов HTML5, но я предполагаю, что RTMP означает, что JWPlayer использует флэш-память для воспроизведения. С точки зрения безопасности Adobe Flash в целом является проблемой, но он не использует Quicktime, я в этом уверен. Итак, опять же, я думаю, что проблемы безопасности ваших клиентов довольно случайны, ИМХО... Каков общий размер вашей коллекции в h264, просто чтобы иметь представление, сколько будет транскодирования, то есть в биткодине...
Я согласен с вами в целом, перекодирование будет около 30 ТБ, поэтому мы оставляем это как последний вариант, и нам все равно еще предстоит выяснить, как их перекодировать. МЫ не можем воспроизвести это, и примерно 80 крупных клиентов оставляют это нам, чтобы разобраться. Я сбит с толку, и они просто хотят, чтобы это починили, или купят в другом месте (очень существенный доход). Главный страх в том, что количество клиентов в этом состоянии будет расти, и все они уйдут.
Я действительно думаю, что вам следует обратиться к клиенту, у которого есть эти опасения, и попытаться лучше понять, чего он боится. Я имею в виду, они вообще блокируют видео h264? Потому что потенциально каждый файл h264 (или WebM или flv, если на то пошло) может быть создан для использования уязвимости. Таким образом, сервис, предлагающий непубличные коллекции видео (такие, как ваша), на самом деле является безопасным способом разрешить видео, в то время как материал, циркулирующий в Интернете, потенциально опасен. Я имею в виду, что вы даже можете получить различные антивирусные сканеры и сканировать свои файлы на наличие эксплойтов, если это их успокоит.
Конечно, мы сделали все это... это школы - нет бюджета, чтобы тратить время/деньги на помощь нам в определении того, что блокирует поток, поэтому мы так же счастливы перейти к другому провайдеру. Это очень расстраивает, но спасибо :)
Вопрос в том, что другой провайдер собирается делать с этой проблемой? MP4 (контейнер) очень похож на файловую структуру QuickTime. Таким образом, mediainfo/FFmpeg будет рассматривать его как контейнер mp4/Mov. Никто ничего не может с этим поделать. WebM знает эксплойты, как и FLV (и, скорее всего, MPEG dash). Поэтому перекодирование вашего материала только успокоит их, пока они не узнают и о других эксплойтах. В то же время создавая значительные расходы для вас. Лично я бы отказался от использования проигрывателя на основе флэш-памяти, хотя по нескольким причинам, безопасность — только одна из них.
Рекомендации CISCO полезны. В нем говорится, что уязвимость связана с эксплуатацией rnetбоксов в MP4. Это не обязательная спецификация формата файла MP4. На самом деле, ffmpeg их не записывает, поэтому любые файлы MP4, перепакованные с помощью ffmpeg, должны быть защищены от эксплойтов. Если MP4 по-прежнему помечаются, значит, у вашего детектора вредоносных программ очень широкий триггер — возможно, он просто смотрит на расширение.
@Mulvya Ну, это не «наш» детектор ... его университеты разбросаны по западному полушарию, лол. Мы использовали Sorenson Squeeze для кодирования, но есть устаревшие файлы, которые используются уже десять лет. Знаете ли вы, как исключить блоки rnet при кодировании и/или, что еще лучше, как удалить их с помощью FFMPEG?
Если вы запустите команду в ответе Дувраи, на выходе не будет этого поля, потому что в коде FFmpeg нет возможности для его записи. Предполагая, что вывод не изменяется чем-то другим, это должно быть так.
Мне кажется, я пробовал это давно, но безуспешно, но попробую еще раз... по крайней мере, вы ответили на вопрос, который преследует меня уже несколько лет - это rnet box, теперь я знаю, что вызывает их детекторы!!!
Можете ли вы дать ссылку на один из файлов, вызывающих ошибку? И текст или скриншот конкретного выдаваемого предупреждения.
Боже, я бы хотел, чтобы это было так просто ... не было бы здесь, если бы это было так, лол. Файлы находятся на Cloudfront, Детекторы — «Бог знает где», и мне потребовалось столько лет, чтобы просто получить от клиента смутные подробности проблемы. Но я действительно, ОЧЕНЬ ценю это предложение. Может быть, однажды, если я смогу получить эти подробности, я выследю тебя, лол.
Если вы разместите свои предложения / указания в качестве ответа, я обязательно приму это!

Ответы (1)

Вы можете удалить большую часть метаданных из ваших файлов, используя ffmpeg:

ffmpeg -i oldfile.mp4 -c copy newfile.mp4

Это скопирует первые аудио- и видеопотоки в новый файл mp4.

Спасибо, но только что попробовал и "format_long_name": "QuickTime / MOV",осталось
Может быть, я ошибаюсь, но не является ли контейнер mp4 практически таким же, как файл QuickTime, и поэтому он помещается в одно поле (метаданные) с «MOv»?
Вы почти абсолютно правы.
Как я могу избежать уязвимости Quicktime с файлами MP4, закодированными в формате h.264?
СпросиСетьПолитика конфиденциальности1y, 0v