¿H.264 está sujeto a vulnerabilidades? ¿Algunos códecs H.264 están sujetos a vulnerabilidades?

¿Qué tan seguras son las transmisiones H.264 de las vulnerabilidades? Más exactamente, ¿los códigos H.264 de grado de consumidor son generalmente "seguros"?

Actualmente estoy transcodificando gratuitamente archivos A/V para evitar estar expuesto a posibles vulnerabilidades. Esto fue después de que me di cuenta de que algunos archivos de video más antiguos tienen errores muy curiosos, errores que me hacen preguntarme si realmente son intentos de explotación ("extraño, ¿por qué hay una CADENA en medio de la transmisión?"). Sé que en algunos formatos/códecs más antiguos, hubo exploits anteriores.

Dado que los códecs H.264 son un poco más modernos que algunos de los más antiguos, me gustaría saber si una transmisión tan elemental es segura en los reproductores "sospechosos habituales": Windows Media, VLC, Quicktime y los principales navegadores (yo uso Chrome y Firefox, pero debería incluir Safari e InternetExploder por si acaso).

En ese caso, si el video es una transmisión elemental H.264, no necesitaría realizar un paso de transcodificación de desinfección y solo crear un nuevo contenedor MP4. Esto al menos eliminaría cualquier vulnerabilidad basada en contenedores. En otras palabras:

ffmpeg -i <file> -c copy newcontainer.mp4

(o -c:v copiar y transcodificar el audio, etc.).

Claramente, la seguridad de la sala blanca requeriría transcodificar todo, pero eso es conseguir todo Felix Unger.

Respuestas (1)

Todo lo que alguien podría decir es que no hay agujeros conocidos en los distintos jugadores. (No sé si eso es cierto, solo que es imposible saber que no hay errores no descubiertos en un código complejo). Los flujos H.264 son lo suficientemente complejos como para tener muchos casos de esquina. Se analizan con código de velocidad optimizada escrito en C y ensamblaje.

Tienes toda la razón en que esta es una ENORME superficie de ataque, especialmente. cuando permite formatos de entrada arbitrarios, incluidos aquellos con desmultiplicadores / decodificadores viejos y toscos escritos por algún tipo al azar hace mucho tiempo, que podría o no haber tenido en mente la seguridad. Este artículo sobre las correcciones de seguridad de ffmpeg es bastante interesante.

re: cadenas ascii dentro de archivos de video. Eso no es raro en absoluto. La salida x264 incrusta una cadena como

x264 - core 142 r2455 021c0dc - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=6 deblock=1:2:2 analyse=0x3:0x133 me=umh subme=10 psy=1 psy_rd=1.00:0.50 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-4 threads=6 lookahead_threads=1 sliced_threads=0 nr=200 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=6 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=crf mbtree=1 crf=25.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:0.50

Y, por supuesto strings, encontrará muchas secuencias de caracteres en el rango ascii, solo por casualidad. Algunos contenedores usan secuencias de caracteres ASCII como valores mágicos para indicar qué tipo de objeto es algo. por ejemplo, mp4 tiene "moov", "mdat" y otros átomos. Si puede elegir cualquier secuencia de 4 bytes para su formato, también puede elegir caracteres ASCII para facilitar la depuración.

Creo que transcodificar todo el video entrante incurriría en una ENORME sobrecarga de calidad/CPU/almacenamiento. La transcodificación con compilaciones nocturnas de ffmpeg lo protegería potencialmente de errores conocidos en la versión típicamente antigua de ffmpeg en versiones estables de VLC, y cualquier error que se encuentre en material de código cerrado de Microsoft y Apple.

Remuxing no es un mal compromiso.

También existe un equilibrio entre la destrucción de metadatos y el paso a través de cosas potencialmente dañinas. (por ejemplo, capítulos, subtítulos, ...)

Si realmente estuviera haciendo esto, probablemente almacenaría mi salida en archivos mkv. Usar un contenedor diferente es quizás un mejor seguro contra cualquier rareza de un mp4 de entrada que se pasa a un mp4 de salida.

Además, si realmente está haciendo esto, supongo que ejecutaría ffmpeg (o MP4Box solo para mp4-> mp4 remuxing) en un chroot o vm de sandbox, o incluso como un usuario sin privilegios, por lo que las explotaciones exitosas están contenidas. .

¡Gracias por la excelente respuesta! Entonces, si estuviera buscando desinfectar el contenedor, ¿un MP4->MKV->MP4 sería superior a una recontainerización directa de MP4->MP4?
Probablemente no mejor que MP4-> MP4 remuxing. MP4->MKV PUEDE convertir un desbordamiento de búfer -> ejecución remota de código en solo un bloqueo en el código de análisis de capítulo, por ejemplo. (O puede que no, el remuxing no siempre ayudará). Ponerlo de nuevo en MP4 podría alinear las cosas de la misma manera que el contenedor original. Si realmente desea que la salida sea MP4, mp4->mp4 remux probablemente sea lo mismo que mp4->mkv->mp4. Y podrías hacerlo con MP4Box o algo así, en lugar de ffmpeg.