¿Cómo puedo evitar la vulnerabilidad de Quicktime con archivos MP4 codificados en h.264?

Publiqué esto anteriormente en SuperUser, pero me di cuenta de que este es probablemente el foro más apropiado para mi pregunta.

Tenemos varios miles de archivos MP4 muy grandes que se han codificado durante la última década con Sorenson Squeeze. Durante el año pasado, repentinamente hubo un número creciente de clientes (universidades) con Network/Proxy Server que de repente no pueden ver los videos debido a la vulnerabilidad descrita en este enlace: Apple QuickTime Vulnerability .

Perdóneme, sé muy poco sobre medios y codificación, solo que el problema comenzó a aparecer repentinamente mientras ven nuestros videos (usamos JWPlayer v7 con archivos alojados en AWS/S3/Cloudfront).

¿Existe una forma alternativa de codificar h.264/MP4 que no incluya ninguna referencia o códec, o lo que sea que los marque como archivos Quicktime, o alguna otra forma de evitar esto?

Nota: Nuestro sitio transmite los archivos h.264 MP4 con JWPlayer; los usuarios finales no los abren con 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"
    }
¿Conoce algunas de las marcas de cortafuegos que plantean este problema? ¿Tiene alguna forma de probar si un nuevo archivo pasará o no?
Por lo que puedo decir, la vulnerabilidad se relaciona con el funcionamiento de Apple Quicktime player versión 7.6.6 o anterior en Windows , no con JWPlayer en la web. ¿Cómo ha identificado la vulnerabilidad como relevante?
En realidad no puedo reproducirlo, son todos los clientes dándonos el mismo informe. Nuestro servidor web ES Windows, pero no sé cuáles son todas las redes de clientes, por supuesto. Sé que esto es vago, pero no soy un gurú de los medios O de la red, así que estoy tambaleándome como tal.
Me perdí el detalle de aws. ¿Está transcodificando los videos con AWS Elastic Transcoder ? ¿Los sirven como descarga progresiva o streaming? También sería útil tener el error real del firewall, el navegador de los usuarios y la versión del sistema, y ​​su código de inserción de jwplayer.
Creo que sería útil preguntar a sus clientes qué vulnerabilidad es exactamente la que activa sus firewalls. Una búsqueda rápida en Google arrojó alrededor de 3-4 vulnerabilidades graves en QuickTime en los últimos años, que parecen usar fallas diferentes. Si esto sucedió recientemente, asumo que se refieren a este exploit y no al que vinculaste, que es de 2010. Threatpost.com/…
En cualquier caso, la demanda de los clientes me parece un poco extraña: tienen instalado el software vulnerable (o tal vez no, pero su firewall quiere proteger a sus posibles clientes QuickTime desactualizados). No hay nada malicioso en sus archivos.
Además, dado que tiene rtmp en sus etiquetas de preguntas, supongo que está utilizando algún tipo de servidor de transmisión. ¿O simplemente estás haciendo pseudo streaming de http?
Están utilizando nuestra página JWPlayer con transmisión RTMP de AWS Los clientes básicamente dicen que lo solucionen o no lo compraremos... ($10K-$50K pedidos)
No sé si AWS puede hacer esto o si sería costoso el tiempo de la CPU, pero siempre podría transcodificar los archivos en tiempo real a un formato diferente hasta que los clientes entren en razón y se den cuenta de que son sus reproductores los que tienen el problema, no tus corrientes.
O mire esto, afirman poder transcodificar más rápido que nadie, también desde AWS... Supongo que su problema debería desaparecer si tuviera todos sus archivos, es decir, en WebM o mpeg dash... al menos hasta que se produzca un exploit. activado con archivos WebM se encuentra. bitcodin.com/blog/2015/02/…
Sin embargo, toda la idea es ridícula, ya que solo estaría trabajando en torno a sus extrañas ideas de seguridad, ya que cualquier formato de video podría usarse para desencadenar una vulnerabilidad en algún reproductor y no pueden excluirlos a todos a menos que consideren ver videos en Internet como inseguro por se.
La recodificación puede ser la única respuesta, pero la última vez que hicimos esto en MP4 tomó casi 2 meses hacer la colección completa: hay 12000 películas completas involucradas, por lo que estamos buscando soluciones alternativas. Si fueran solo un par de clientes, no es gran cosa, pero cada mes recibimos más y más tickets de soporte y cancelaciones debido al problema.
Creo que tal vez una solución "legal" a este problema es más fácil de lograr. Como indica la descripción de los exploits, el archivo de video malicioso debe diseñarse específicamente para explotar la vulnerabilidad en los reproductores afectados. Si su plataforma no está abierta al público y puede asegurarse de que ningún archivo de video creado con fines malintencionados pueda colarse en su colección, ¿esto debería ser suficiente como garantía para ellos o no? Luego, podrían incluir su servicio en la lista blanca de sus firewalls. Por lo que veo, no hay una alternativa real, si buscas WebM y exploits, también encontrarás incidentes, así que supongo
@Hans, ven el video en nuestra página web, con JWPlayer: ¿el reproductor QT es parte de la ecuación? El manifiesto del archivo en el script JWP está siendo bloqueado entre su navegador y nuestro servidor (presumiblemente con su servidor proxy)
Y lo mismo podría suceder con Mpeg dash, incluso si no hay una vulnerabilidad reportada a partir de ahora. Entonces, el próximo mes podrían decir que bloquearán WebM o mpeg dash también...
¡No! El reproductor QuickTime no forma parte del proceso, por lo que puedo ver. ¿Está utilizando jwplayer en modo flash o html5?
Flash/falback predeterminado a HTML5: esto solo sucede con RTMP
Entonces no entiendo completamente la preocupación de los clientes. Aparentemente, internamente, Safari usa Quicktime como reproductor cuando usa objetos de video HTML5, pero supongo que RTMP significa que JWPlayer está usando flash para la reproducción. En cuanto a la seguridad, Adobe Flash es un problema en general, pero no usa Quicktime, estoy bastante seguro de eso. Entonces, nuevamente, creo que las preocupaciones de seguridad de sus clientes son bastante aleatorias en mi humilde opinión... ¿Cuál es el tamaño total de su colección en h264, solo para tener una idea de cuánto sería la transcodificación, es decir, en bitcodin...
Estoy de acuerdo con usted en general, la transcodificación sería de unos 30 TB, por lo que lo dejamos como última opción, y aún tenemos que descubrir cómo volver a codificarlos de todos modos. NOSOTROS no podemos reproducirlo, y los 80 o más clientes principales nos dejan que lo averigüemos. Estoy desconcertado, y simplemente quieren que lo arreglen, o comprarán en otro lugar (ingresos muy sustanciales). El principal temor es que la cantidad de clientes en este estado siga creciendo y todos se vayan.
Realmente creo que debería comunicarse con un cliente que tenga estas preocupaciones y tratar de comprender mejor qué es lo que teme. Quiero decir, ¿están bloqueando videos h264 en general? Porque potencialmente todos los archivos h264 (o WebM o flv para el caso) pueden diseñarse para explotar una vulnerabilidad. Por lo tanto, un servicio que ofrece colecciones de videos no públicas (como parece ser la suya) es en realidad una forma segura de permitir videos, mientras que las cosas que flotan en la Web son potencialmente peligrosas. Quiero decir que incluso podría obtener diferentes escáneres de virus y escanear sus archivos en busca de exploits si eso los calma.
Por supuesto que hemos hecho todo eso... son escuelas: no hay presupuesto para gastar tiempo/dinero ayudándonos a identificar lo que sea que esté bloqueando la transmisión, por lo que estamos felices de cambiarnos a otro proveedor. Es muy frustrante, pero gracias :)
La cuestión es: ¿qué va a hacer otro proveedor con ese tema? MP4 (el contenedor) está modelado muy de cerca a partir de la estructura de archivos de QuickTime. Entonces mediainfo / Ffmpeg lo considerará como un contenedor mp4 / Mov. No hay nada que nadie pueda hacer al respecto. WebM ha conocido vulnerabilidades al igual que FLV (y muy probablemente también MPEG dash), por lo que transcodificar sus cosas solo los calmará hasta que aprendan sobre las otras vulnerabilidades también. Mientras tanto, crea costos considerables para usted. Personalmente, me alejaría de usar un reproductor basado en flash por varias razones, siendo la seguridad solo una.
El aviso de CISCO es útil. Dice que la vulnerabilidad está ligada a la explotación de rnetcajas en MP4. Esas no son una especificación obligatoria del formato de archivo MP4. De hecho, ffmpeg no los escribe, por lo que cualquier archivo MP4 empaquetado con ffmpeg debe estar protegido contra vulnerabilidades. Si los MP4 todavía están marcados, entonces su detector de malware tiene un desencadenante muy amplio, tal vez solo esté mirando la extensión.
@Mulvya Bueno, no es "nuestro" detector... son universidades repartidas por el hemisferio occidental, lol. Hemos estado usando Sorenson Squeeze para hacer la codificación, pero hay una década de archivos heredados que están en uso. ¿Conoce alguna forma de excluir las cajas de rnet al codificar y/o mejor aún, cómo eliminarlas con FFMPEG?
Si ejecuta el comando en la respuesta de Duvrai, la salida no tendrá ese cuadro porque el código de FFmpeg no tiene ninguna disposición para escribirlo. Suponiendo que la salida no se altere por otra cosa, debería ser así.
Me parece que lo intenté hace mucho tiempo sin suerte, pero lo intentaré de nuevo... al menos has respondido una pregunta que me ha estado atormentando durante varios años: es la caja de rnet , ahora sé qué está desencadenando su detectores!!!
¿Puede vincular a uno de los archivos que desencadenan el error? Y el texto o captura de pantalla de la advertencia específica que se lanza.
Dios, desearía que fuera tan fácil... no estaría aquí si lo fuera, jajaja. Los archivos están en Cloudfront, los detectores están "Dios sabe dónde", y me tomó tantos años obtener los detalles vagos del problema de un cliente. Pero realmente, REALMENTE aprecio la oferta. Tal vez algún día, si puedo obtener esos detalles, te cazaré, jajaja.
Si pones tus sugerencias/direcciones como respuesta, ¡ciertamente lo aceptaré!

Respuestas (1)

Puede eliminar la mayoría de los metadatos de sus archivos usando ffmpeg:

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

Esto copiará las primeras transmisiones de audio y video a un nuevo mp4.

Thx, pero lo acabo de probar y los "format_long_name": "QuickTime / MOV",restos
Tal vez me equivoque, pero ¿el contenedor mp4 no es prácticamente lo mismo que un archivo QuickTime y, por lo tanto, se incluye en un cuadro (metadatos) con "MOv"?
Tienes casi toda la razón.
¿Cómo puedo evitar la vulnerabilidad de Quicktime con archivos MP4 codificados en h.264?
RespuestasAquíPolítica de privacidad1y, 0v