Wie kann ich die Quicktime-Schwachstelle mit h.264-kodierten MP4-Dateien vermeiden?

Ich habe dies früher auf SuperUser gepostet, aber festgestellt, dass dies wahrscheinlich das geeignetere Forum für meine Frage ist.

Wir haben mehrere tausend sehr große MP4-Dateien, die in den letzten zehn Jahren mit Sorenson Squeeze codiert wurden. Im vergangenen Jahr gibt es plötzlich eine wachsende Zahl von Kunden (Universitäten) mit Netzwerk-/Proxy-Servern, die die Videos aufgrund der unter diesem Link beschriebenen Schwachstelle plötzlich nicht mehr ansehen können: Apple QuickTime Vulnerability .

Verzeihen Sie mir, ich weiß sehr wenig über Medien und Kodierung, nur dass das Problem plötzlich auftaucht, während sie unsere Videos ansehen (wir verwenden JWPlayer v7 mit Dateien, die bei AWS/S3/Cloudfront gehostet werden).

Gibt es eine alternative Methode zum Codieren von h.264/MP4, die keine Referenz oder Codecs enthält, oder was auch immer sie als Quicktime-Dateien kennzeichnet, oder eine andere Möglichkeit, dies zu umgehen?

Hinweis: Unsere Website streamt die h.264 MP4-Dateien mit JWPlayer – die Endbenutzer öffnen sie nicht mit 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"
    }
Kennen Sie einige der Firewall-Marken, die dieses Problem aufwerfen? Haben Sie eine Möglichkeit zu testen, ob eine neue Datei durchgeht oder nicht?
Soweit ich das beurteilen kann, betrifft die Schwachstelle den Betrieb des Apple Quicktime-Players Version 7.6.6 oder älter unter Windows , nicht JWPlayer im Web. Wie haben Sie die Schwachstelle als relevant identifiziert?
Ich kann es nicht wirklich reproduzieren, es sind alle Kunden, die uns den gleichen Bericht geben. Unser Webserver ist Windows, aber ich weiß natürlich nicht, was alle Kundennetzwerke sind. Ich weiß, das ist vage, aber ich bin kein Medien- ODER Netzwerk-Guru, also zappele ich als solcher.
Ich habe nur das aws-Detail verpasst. Transkodieren Sie die Videos mit AWS Elastic Transcoder ? Bieten Sie sie als progressiven Download oder Streaming an? Es wäre auch hilfreich, den tatsächlichen Firewall-Fehler, die Browser- und Systemversion des Benutzers und Ihren jwplayer-Einbettungscode zu haben.
Ich denke, es wäre hilfreich, Ihre Kunden zu fragen, welche Sicherheitslücke genau ihre Firewall auslöst. Eine schnelle Google-Suche hat in den letzten Jahren etwa 3-4 schwerwiegende Exploits in QuickTime aufgespürt, die jedoch anscheinend andere Fehler verwenden. Wenn dies kürzlich passiert ist, nehme ich an, dass sie sich auf diesen Exploit beziehen und nicht auf den, den Sie verlinkt haben, der aus dem Jahr 2010 stammt. terrorpost.com/…
Auf jeden Fall finde ich die Nachfrage der Clients etwas seltsam: Sie haben die anfällige Software installiert (oder vielleicht auch nicht, aber ihre Firewall möchte ihre möglicherweise veralteten QuickTime-Clients schützen). In Ihren Dateien ist nichts Bösartiges.
Da Sie rtmp in Ihren Fragen-Tags haben, nehme ich an, dass Sie eine Art Streaming-Server verwenden? Oder machst du nur http-Pseudo-Streaming?
Sie verwenden unsere JWPlayer-Seite mit RTMP-Streaming von AWS. Kunden sagen im Grunde, reparieren Sie es, oder wir werden es nicht kaufen ... (Bestellungen von 10.000 bis 50.000 USD)
Ich weiß nicht, ob AWS das kann oder ob die CPU-Zeit teuer wäre, aber Sie könnten die Dateien immer in Echtzeit in ein anderes Format transcodieren, bis die Clients zur Vernunft kommen und erkennen, dass es ihre Spieler sind, die das Problem haben, nicht Ihre Ströme.
Oder sehen Sie sich das an, sie behaupten, schneller transcodieren zu können als alle anderen, auch von AWS ... Ich denke, Ihr Problem sollte behoben sein, wenn Sie alle Ihre Dateien hatten, dh in WebM oder MPEG-Dash ... zumindest bis zu einem Exploit ausgelöst mit WebM-Dateien gefunden. bitcodin.com/blog/2015/02/…
Die ganze Idee ist jedoch lächerlich, da Sie nur ihre seltsamen Sicherheitskonzepte umgehen würden, da jedes Videoformat verwendet werden könnte, um eine Schwachstelle in einigen Playern auszulösen, und sie nicht alle ausschließen können, es sei denn, sie betrachten das Ansehen von Videos über das Internet als unsicher per se.
Rencoding könnte die einzige Antwort sein, aber das letzte Mal, als wir dies mit MP4 gemacht haben, hat es fast 2 Monate gedauert, um die gesamte Sammlung zu erstellen - es sind 12000 Filme in voller Länge involviert, also suchen wir nach alternativen Lösungen. Wenn es nur ein paar Kunden wären, keine große Sache, aber wir bekommen jeden Monat mehr und mehr Support-Tickets und Absagen aufgrund des Problems.
Ich denke, vielleicht ist eine "legale" Lösung für dieses Problem einfacher zu erreichen. Wie die Beschreibung des Exploits besagt, muss die bösartige Videodatei speziell erstellt werden, um die Schwachstelle in den betroffenen Playern auszunutzen. Wenn Ihre Plattform nicht für die Öffentlichkeit zugänglich ist und Sie versichern können, dass sich keine böswillig erstellte Videodatei in Ihre Sammlung einschleichen kann, sollte dies als Beruhigung für sie ausreichen, oder nicht? Dann könnten sie Ihren Dienst auf ihren Firewalls auf die Whitelist setzen. Da gibt es meines Erachtens keine wirkliche Alternative, wenn man nach WebM und Exploits sucht, findet man auch Vorfälle, so gu ich
@Hans, sie sehen sich das Video auf unserer Webseite mit JWPlayer an - ist der QT-Player überhaupt Teil der Gleichung? Das Manifest der Datei im JWP-Skript wird zwischen ihrem Browser und unserem Server blockiert (vermutlich mit ihrem Proxy-Server).
Und dasselbe könnte mit Mpeg Dash passieren, auch wenn derzeit keine gemeldete Schwachstelle vorliegt. Nächsten Monat könnten sie also sagen, dass sie auch WebM oder MPEG-Dash blockieren werden ...
Nein! QuickTime Player ist nicht Teil des Prozesses, soweit ich das sehen kann. Verwenden Sie den jwplayer im Flash- oder HTML5-Modus?
Standard-Flash/Falback auf HTML5 – dies geschieht nur mit RTMP
Dann verstehe ich die Bedenken der Kunden überhaupt nicht. Anscheinend verwendet Safari intern Quicktime als Player, wenn HTML5-Videoobjekte verwendet werden, aber ich denke, RTMP bedeutet, dass JWPlayer Flash für die Wiedergabe verwendet. Sicherheitstechnisch ist Adobe Flash im Allgemeinen ein Problem, aber es verwendet kein Quicktime, da bin ich mir ziemlich sicher. Also, noch einmal, ich denke, die Sicherheitsbedenken Ihrer Kunden sind meiner Meinung nach ziemlich zufällig ... Wie groß ist Ihre Sammlung in h264 insgesamt, nur um eine Vorstellung davon zu haben, wie viel die Transcodierung, dh in Bitcoin, wäre ...
Ich stimme Ihnen im Allgemeinen zu, Transcodierung würde etwa 30 TB betragen, also lassen wir das als letzte Option, und wir müssen sowieso noch herausfinden, wie wir sie neu codieren können. WIR können es nicht reproduzieren, und die rund 80 Großkunden überlassen es uns, es herauszufinden. Ich bin verblüfft, und sie wollen es einfach repariert haben oder woanders kaufen (sehr hohe Einnahmen). Die größte Befürchtung ist, dass die Zahl der Kunden in diesem Staat weiter wächst und sie alle gehen werden.
Ich denke wirklich, Sie sollten sich an einen Kunden wenden, der diese Bedenken hat, und versuchen, besser zu verstehen, was er fürchtet. Ich meine, blockieren sie h264-Videos im Allgemeinen? Weil potenziell jede h264-Datei (oder WebM oder flv für diese Angelegenheit) so manipuliert werden kann, dass sie eine Schwachstelle ausnutzt. Ein Dienst, der nicht-öffentliche Videosammlungen anbietet (wie Ihre zu sein scheinen), ist also eigentlich eine sichere Möglichkeit, Videos zuzulassen, während das Zeug, das im Internet herumschwirrt, potenziell gefährlich ist. Ich meine, Sie könnten sich sogar verschiedene Virenscanner besorgen und Ihre Dateien auf Exploits scannen, wenn das sie beruhigt
Natürlich haben wir all das getan ... sie sind Schulen - kein Budget, um Zeit/Geld dafür aufzuwenden, uns dabei zu helfen, herauszufinden, was den Stream blockiert, also wechseln wir genauso gerne zu einem anderen Anbieter. Es ist sehr frustrierend, aber danke :)
Die Sache ist die: Was wird ein anderer Anbieter in Bezug auf dieses Problem tun? MP4 (der Container) ist sehr eng an die QuickTime-Dateistruktur angelehnt. Mediainfo / Ffmpeg wird es also als mp4 / Mov-Container betrachten. Es gibt nichts, was jemand dagegen tun kann. WebM hat bekannte Exploits, ebenso wie FLV (und höchstwahrscheinlich auch MPEG Dash). Das Transkodieren Ihrer Sachen wird sie also nur beruhigen, bis sie auch von den anderen Exploits erfahren. Dabei entstehen für Sie erhebliche Kosten. Persönlich würde ich jedoch aus mehreren Gründen von der Verwendung eines Flash-basierten Players abraten, wobei die Sicherheit nur einer ist.
Die CISCO-Beratung ist hilfreich. Es heißt, dass die Schwachstelle mit der Ausnutzung von rnetBoxen in MP4 zusammenhängt. Dies sind keine obligatorischen Spezifikationen des MP4-Dateiformats. Tatsächlich schreibt ffmpeg diese nicht, daher sollten alle MP4-Dateien, die mit ffmpeg neu verpackt wurden, vor Exploits geschützt werden. Wenn die MP4s immer noch markiert werden, hat Ihr Malware-Detektor einen sehr breiten Auslöser – vielleicht schaut er nur auf die Erweiterung.
@Mulvya Nun, es ist nicht "unser" Detektor ... seine Universitäten sind über die westliche Hemisphäre verstreut, lol. Wir haben Sorenson Squeeze für die Kodierung verwendet, aber es gibt noch mehr als ein Jahrzehnt alte Dateien, die verwendet werden. Kennen Sie eine Möglichkeit, die rnet-Boxen beim Codieren auszuschließen, und / oder noch besser, wie Sie sie mit FFMPEG entfernen können?
Wenn Sie den Befehl in Duvrais Antwort ausführen, enthält die Ausgabe dieses Feld nicht, da der Code von FFmpeg keine Möglichkeit hat, es zu schreiben. Unter der Annahme, dass die Ausgabe dann nicht durch etwas anderes verändert wird, sollte es das sein.
Mir scheint, ich habe das vor langer Zeit ohne Erfolg versucht, werde es aber noch einmal versuchen ... zumindest haben Sie eine Frage beantwortet, die mich seit einigen Jahren verfolgt - es ist die rnet -Box, jetzt weiß ich, was sie auslöst Detektoren!!!
Können Sie auf eine der Dateien verlinken, die den Fehler auslösen? Und der Text oder Screenshot der spezifischen Warnung, die ausgegeben wird.
Gott, ich wünschte, es wäre so einfach ... wäre nicht hier, wenn es so wäre, lol. Die Dateien befinden sich auf Cloudfront, die Detektoren sind „Gott weiß wo“, und es hat mich so viele Jahre gekostet, nur um die vagen Details des Problems von einem Kunden zu erhalten. Aber ich weiß das Angebot wirklich sehr zu schätzen. Vielleicht jage ich dich eines Tages, wenn ich diese Einzelheiten herausbekomme, lol.
Wenn Sie Ihre Vorschläge / Anweisungen als Antwort geben, werde ich sie auf jeden Fall akzeptieren !!

Antworten (1)

Sie können die meisten Metadaten mit ffmpeg aus Ihren Dateien entfernen:

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

Dadurch werden die ersten Audio- und Videostreams in eine neue mp4-Datei kopiert.

Thx, aber gerade ausprobiert und das "format_long_name": "QuickTime / MOV",bleibt
Vielleicht irre ich mich, aber ist der mp4-Container nicht praktisch dasselbe wie eine QuickTime-Datei und daher mit "MOv" in eine (Metadaten-) Box geworfen?
Du hast fast genau recht.
Wie kann ich die Quicktime-Schwachstelle mit h.264-kodierten MP4-Dateien vermeiden?
AntwortenHierDatenschutz-Bestimmungen1y, 1v