In einem gebe ich persönlich dieser Diskussion recht - aber das hat wenig mit Sicherheitslücken zu tun: den alten ProRes Dekoder endlich mal zu ersetzen ist eigentlich überfällig.
Schön wenn die NLE-Hersteller gezwungen werden das mal flächendeckend zu tun - für Adobe oder auch Grass Valley ist das ja sicherlich kein Thema. Ältere Applikationen wie das von mir geschätzte Vegas kommen dabei wohl aber sicher unter die Räder, dort darf bezweifelt werden ob das passieren wird.
wolfgang hat geschrieben:Also in der Praxis sehe ich da keine Probleme. ProRes zu Cineform transkodiert und die Sache funktioniert in vielen Schnittsystemen problemlos.
Aber um überhaupt ProRes konvertieren (sprich: lesen) zu können, muss auf Deinem Windows-Rechner bereits Quicktime installiert sein. Dann kannst Du ProRes auch gleich in Deinen NLE statt den Konvertierer laden - das Sicherheitsrisiko ist dasselbe.
Falls im Untergrundmarkt Quicktime-Exploits zirkulieren (bzw. verkauft werden) sollten, sehe ich da eine reale Gefahr. Für Malware-Programmierer ist das ein attraktives Einfallstor für Ransomware bzw. Dateien-verschlüssende Erpressungstrojaner. Überdurchschnittlich viele professionelle Anwender sind betrofffen, die im Zweifelsfall eher und mehr Erpressungsgeld bezahlen.
Und wenn wir mal das Szenario weiterdenken: Es kann Malware geschrieben (bzw. an schädliche Quicktime-Dateien gekoppelt) werden, die den Quicktime-Schadcode in alle auf einem Rechner vorgefundenen .mov-Dateien einbaut. Dann wären auch selbsterstellte/aufgenommene Quicktime-Dateien keine Sicherheitsgarantie mehr.
Als Auslöser würde es reichen, wenn jemand einmal eine manipulierte .mov-Datei ins Netz stellt, die sich viele herunterladen (z.B. weil sie angeblich out-of-the-cam footage einer neuen und vieldiskutierten Kamera ist, oder z.B. ein kostenloses Filmkorn-Overlay), und dann setzt sich die Infektionskette in Gang.
Ab heute muss man also .mov-Dateien unter Total-Quarantäne stellen, wenn man mit Windows arbeitet.
Zuletzt geändert von cantsin am So 17 Apr, 2016 13:14, insgesamt 1-mal geändert.
wolfgang hat geschrieben:In einem gebe ich persönlich dieser Diskussion recht - aber das hat wenig mit Sicherheitslücken zu tun: den alten ProRes Dekoder endlich mal zu ersetzen ist eigentlich überfällig.
wie gesagt, die genze geschichte hat ausgesprochen wenig mit einem einzelnen dekoder oder gar format/container zu tun, sondern mit der konkreten implementierung der basisinfrastruktur. auf der ebene wäre bspw. gstreamer eine offene alternative, was die funktionalität angeht. in der praxis gibt's aber auch damit derart viele probleme, dass es wirklich mehr als blauäugig erscheinen würde, von kommerziellen produkten zu erwarten, dass sie diese alternative nutzen sollten.
cantsin hat geschrieben:Ab heute muss man also .mov-Dateien unter Total-Quarantäne stellen, wenn man mit Windows arbeitet.
du solltest nicht übersehen, dass MPEG4 über weite strecken sehr stark an quicktime angelehnt ist. würde es also wirklich ein problem des formats/containers sein, hätte das noch viel weitreichendere folgen. das ist aber in der praxis mit größter wahrscheinlichkeit nicht der fall. betroffen ist wirklich nur die reale implementation des entsprecheden windows multimedia frameworks, was halt auf grund der gleichlautenden bzw. nicht klar differenzierten namensgebung immer schon für ziemliche verwirrung gesorgt hat.
mit allen playern/web-browser-plugins etc.. die sich z.b. direkt auf ffmpeg stützen, ohne die quicktime system-mechanismen zu nutzen, kann man die files auch weiterhin ohne jedes risiko abspielen. wobei man der ehrlichkeit halber sagen muss, dass auch ffmpeg in vergangenheit immer wieder mit groben sicherheitsmängeln konfrontiert war, was ja u.a. auch dazu geführt hat dass die spaltung zw. ffmpeg und libav wieder stark im schwinden ist, weil man einfach all kräfte bündeln muss, um derartigen problemen rasch und effizient zu begegnen. im umfeld der freien software gibt's dafür wenigstens ein recht waches bewusstsein -- man diskutiert und fixt die probleme ganz offen und kehrt sie nicht einfach unter den tisch.
Zuletzt geändert von mash_gh4 am So 17 Apr, 2016 13:23, insgesamt 1-mal geändert.
@Slashcam:
Was Ihr als Ratschlag A schreibt, finde ich gefährlich missverständlich:
"Plan A: Ignorieren muss kein großes Risiko sein, da die Lücke ja in erster Linie über den Browser ausgenutzt wird. Solange der Browser nicht mehr die Quicktime-Komponenten benutzt, dürfte eine Infektion über das Netz schwer fallen. Unmöglich ist eine Infektion dadurch aber sicher nicht. Besonders wenn am Desktop die *.MOV-Dateien noch mit Quicktime verknüpft sind. Daher nicht nur im Browser das PluginPlugin im Glossar erklärt deaktivieren, sondern auch die Desktop-Verknüpfungen auf einen alternativen Player umlenken."
Weder das Löschen der Browser-Quicktime-Komponente, noch der Desktop-Verknüpfungen lösen doch das Problem, denn sobald man eine .mov-Datei, die man nicht selbst erstellt hat, in einen NLE oder auch nur in den Adobe Media Encoder, in After Effects, ins Filmconvert-Standaloneprogramm, in Resolve.... lädt, setzt man seinen Windows-Rechner einem Infektionsrisiko aus.
Das scheint noch nicht allen Leuten klar zu sein, und Euer Ratschlag vernebelt diese Tatsache eher, als dass er zur Aufklärung beiträgt.
cantsin hat geschrieben:Ab heute muss man also .mov-Dateien unter Total-Quarantäne stellen, wenn man mit Windows arbeitet.
du solltest nicht übersehen, dass MPEG4 über weite strecken sehr stark an quicktime angelehnt ist. würde es also wirklich ein problem des formats/containers sein, hätte das noch viel weitreichendere folgen. das ist aber in der praxis mit größter wahrscheinlichkeit nicht der fall.
Nein, es ist kein Problem des Formats oder Containers, sondern ein Problem, dass fast alle Videobearbeitungssoftware unter Windows das Quicktime-Framework verwendet, um .mov-Dateien zu laden.
Ich habe natürlich kein Risiko, wenn ich eine .mov-Datei in VLC abspiele (das eigene Bibliotheken verwendet) - aber sobald ich sie in eine Adobe CC-Applikation, in Edius, Vegas, Resolve lade, habe ich das Risiko.
Zuletzt geändert von cantsin am So 17 Apr, 2016 13:41, insgesamt 1-mal geändert.
cantsin hat geschrieben:Nein, es ist kein Problem des Formats oder Containers, sondern ein Problem, dass fast alle Videobearbeitungssoftware unter Windows das Quicktime-Framework verwendet, um .mov-Dateien zu laden.
Ich habe natürlich kein Risiko, wenn ich eine .mov-Datei in VLC abspiele (dass eigene Bibliotheken verwendet) - aber sobald ich es in eine Adobe CC-Applikation, in Edius, Vegas, Resolve lade, habe ich das Risiko.
genau! -- da bist mir jetzt zuvorgekommen, während ich das gerade noch ergänzt habe. :)
dienstag_01 hat geschrieben:Habt ihr mal ein Fallbeispiel für eine Infektion über ein Videofile?
Glücklicherweise sind wir noch nicht soweit - bis jetzt gibt es nur zwei bekannte Sicherheitslücken, und wir wissen noch nicht, ob diese bereits aktiv ausgenutzt werden (bzw. ob bereits Exploits auf dem Malware-Schwarzmarkt angeboten werden). Leider ist so etwas aber oft nur eine Frage von wenigen Tagen. Wenn sich, wie hier geschehen, CERT und Homeland Security einschalten, ist es auf jeden Fall ernst zu nehmen.
cantsin hat geschrieben:Glücklicherweise sind wir noch nicht soweit - bis jetzt gibt es nur zwei bekannte Sicherheitslücken
Ach, du meinst, bisher gab es noch keine Sicherheitslücken in den diversen media frameworks?!
Das ist ja nun der größte Quatsch ;)
Sorry, es geht um bekannte Sicherheitslücken, die aktiv ausgenützt werden können und die gravierend genug sind, um die Betriebssicherheit nicht nur einer bestimmten Software, sondern des gesamten PC zu unterminieren. Hinzu kommt, dass Quicktime auf praktischen allen Windows-Schnittrechnern und auch auf Millionen Consumer-PCs installiert ist und daher ein attraktives Einfallstor für Malwareprogrammierer ist (genau wie zuvor Flash und PDF).
cantsin hat geschrieben:Sorry, es geht um bekannte Sicherheitslücken, die aktiv ausgenützt werden können und die gravierend genug sind, um die Betriebssicherheit nicht nur einer bestimmten Software, sondern des gesamten PC zu unterminieren.
Sorry, das sagst du.
Ich habe bis jetzt nur von zwei Sicherheitslücken gelesen, aber nichts darüber, was genau sie betreffen und ob es wirklich möglich ist, Schadcode über ein Mov File aus einer Videoanwendung heraus zu installieren.
Aber vielleicht weisst du da mehr.
dienstag_01 hat geschrieben:
Ich habe bis jetzt nur von zwei Sicherheitslücken gelesen, aber nichts darüber, was genau sie betreffen und ob es wirklich möglich ist, Schadcode über ein Mov File aus einer Videoanwendung heraus zu installieren.
Aber vielleicht weisst du da mehr.
S.o., siehe meine zwei Links. Ja, leider ist das möglich. Lücke Nr.1: "The specific flaw exists within the moov atom. By specifying an invalid value for a field within the moov atom, an attacker can write data outside of an allocated heap buffer. An attacker could leverage this to execute arbitrary code under the context of the QuickTime player." Lücke Nr. 2: "The specific flaw exists within atom processing. By providing an invalid index, an attacker can write data outside of an allocated heap buffer. An attacker could leverage this to execute arbitrary code under the context of the QuickTime player."
(Nur um Missverständnisse zu vermeiden, QuickTime player ist in diesem Fall nicht bloss die QuickTime-Videoplayer-App, sondern auch die QuickTime-Abspielroutinen, die von Adobe CC, Vegas, Edius, Resolve & Co. verwendet werden. Daher auch die Warnung von Adobe.)
DV_Chris hat geschrieben:Deine Kunden liefern manipulierte ProRes Files an? Na dann...
Sagen wir mal so: Angesichts des absolut fehlenden Problembewusstseins würde ich bei 90% der Diskussionsteilnehmer hier, dich eingeschlossen, durchaus davon ausgehen, dass sie zumindest potentiell früher oder später verseuchte Dateien ausliefern.
Ganz davon abgesehen, dass ein nicht vernetzer (was in der Realität der Leute hier de facto nicht geupdatet bedeutet) Rechner nicht nur durch Videodatein sondern durch etliche schimmelige USB, SMB, whatever Exploits von vor drei Jahren angreifbar ist.
Ich bin seit weit mehr als einem Jahrzehnt Händler für Schnittplätze, externen Storage usw. Datensicherheit zu gewährleisten ist ein Teil meines Berufs.
Aber natürlich kann man sich den Aluhut aufsetzen und sich vor jedem Exploit fürchten wie vor dem nächsten Meteoriten. So gesehen ist es am besten, wenn Du den Rechner sofort abdrehst!
DV_Chris hat geschrieben:Ich bin seit weit mehr als einem Jahrzehnt Händler für Schnittplätze, externen Storage usw. Datensicherheit zu gewährleisten ist ein Teil meines Berufs.
Das hat wahrscheinlich der Händler des Lukaskrankenhaus auch gesagt.
Seinen Beruf (bzw. Teile davon) kann man stets gut oder schlecht machen.
Quicktime in Windows einfach normal weiterverwenden. Alles andere ist Paranoia. Wer ganz "sicher" sein will, der benennt einfach die Quicktime Player exe um und fertig.
patshi hat geschrieben:Quicktime in Windows einfach normal weiterverwenden. Alles andere ist Paranoia. Wer ganz "sicher" will, der benennt einfach die Quicktime Player exe um und fertig.
Offenbar haben viele Leute immer noch nicht verstanden, dass es nicht um den Quicktime-Player, sondern um die Quicktime-Abspielbibliotheken geht, die auch in aller möglichen anderen Videosoftware verwendet werden. Aber dieser Thread hier wird langsam sinnlos.
dienstag_01 hat geschrieben:
Ich habe übrigens mal die CC2015 auf Windows 8.1 installiert, Premiere meldet nichts, aber After Effects mahnt das fehlen von Quicktime an.
Dasselbe wie Leute mit Avid unter 8, FCP7 Nutzer (sobald Apple in ihrem OS nur noch AV reinbaut) oder auch Adobe CS6 Benutzer machen: in die Röhre schaun.
Mich erstaunt es immer noch, dass Leute ein Anspruchsdenken haben, nur weil sie vor Jahrzehnten vllt 1000-1500 Euro in Software gesteckt haben, jetzt Support für Neues bis zur Rente haben wollen. Software funzt so einfach nicht.
1. Wenn man keine .mov Datein runterlädt - ist man dann in "Gefahr"?
2. Gibt es keine Programm die .mov Dateien wie antivirenprogramme checken können?
Zu 1: Nein. Es sei denn dein Browser nutzt Quicktime auch zum Abspielen von eingebetteten Mov Files. Dann kann auch eine MOV Datei automatisch geöffnet werden, wenn du auf einer unsicheren Webseite bist.
2. Falls die Lücke aktiv ausgenutzt wird, werden wahrscheinlich die Antivirenprogramme auch anfangen, die MOV Dateien daraufhin zu checken. Ist immer ein Henne-Ei Problem.
Aber das größte Problem ist dabei, dass man halt einer der ersten sein kann, der sich was einfängt, bevor der Virus große Verbreitung gefunden hat und überhaupt bekannt geworden ist...
DV_Chris hat geschrieben:
Deine Kunden liefern manipulierte ProRes Files an? Na dann...
Es kommt sehr darauf an, wer was mit einem Virus erreichen will. Ein denkbares Szenario wäre, dass sich eine Malware auf dem User-Rechner private MOV-Files infiziert und von dort einen neuen Verbreitungsweg öffnet.
Wenn dieser User dann anderen Anwendern seine Mov-Files gibt (denkt mal an mal Familien-Videos von der DSLR) könnten sich sowas abseits von Webseiten verbreiten. Denke aber nicht, dass sowas tatsächlich passiert, weil die Verbreitung hier nicht sonderlich breit flächig gelingen wird. Aber für den Einzelfall (wie z.b, Bundestrojaner) sicherlich ein nützlicher Einfalls-Vektor.
rudi hat geschrieben:
Wenn dieser User dann anderen Anwendern seine Mov-Files gibt (denkt mal an mal Familien-Videos von der DSLR) könnten sich sowas abseits von Webseiten verbreiten.
Naja, es sind nicht nur Familien-Videos von der DSLR, sondern eigentlich muss man jetzt alle .mov-Dateien, die man von Dritten erhält, mit spitzen Fingern anfassen. Das können auch Dateien von einer Filmproduktions- oder Postproduction-Firma seien, deren Rechner infiziert sind. Es könnten Super 8-Scans von einem Dienstleister sein, der Quicktime-Dateien anliefert. Es könnten selbst die eigenen Kameradateien sein, wenn ein Assi das Offloading auf einen verseuchtem Rechner vorgenommen hat. Es reicht ja, dass auf einem infizierten PC eine Malware sitzt, die sich in alle .mov-Dateien schreibt, die sie auf dem Rechner vorfindet.
Man kann nur hoffen, dass es bald Virenscanner geben wird, die Quicktime-Dateien auf Schadcode in den bekannten zwei Exploits prüfen.
cantsin hat geschrieben:Man kann nur hoffen, dass es bald Virenscanner geben wird, die Quicktime-Dateien auf Schadcode in den bekannten zwei Exploits prüfen.
diese art von lücken sind mit virenscanner leider kaum aufzuspüren. dazu müsste der ganze videostrom decodiert und auf seine konformität überprüft werden. wenn man mit einfachem scannen hier etwas erreichen kann, dann vermutlich erst, wenn die lücke im großen stil ausgenutzt wird und in den betreffenden files eine bekannte form von schadcode eingebettet wurde.
und was die verteilung betrifft, wäre ich auch vorsichtig, nur ganz primitiven methoden der weitergabe im auge zu haben. es ist z.b. durchaus möglich, dass auf einem verseuchten rechner irgendwo in der nähe DNS anfragen sehr selektiv umgebogen werden und auf proxis umgeleitet werden, die dann plötzlich in irgendwelchem material, das via dropbox, wetransfer od.ä. zugeliefert wird, den entsprechenden schadcode on the fly in die videodateien injizieren. so etwas fällt nicht unbedingt gleich ins auge, bevor es dann plötzlich ernst wird...
ich bin immer wieder ziemlich überrascht, wie schrecklich unterentwickelt das entsprechende problembewusstsein im video-umfeld ist. gar nicht so sehr nur bei den usern, sondern zum teil auch bei den herstellern. ich denke da z.b. an professionelle resolve remote grading lösungen, die mit linux installern ausgeliefert werden, die ganz gravierende sicherheitsmängel aufweisen (pregenerated ssh keys), die jedem einschlägig befassten techniker die haare zu berge stehen lassen bzw. allen entsprechenden empfehlungen grob zuwider laufen.
mash_gh4 hat geschrieben:diese art von lücken sind mit virenscanner leider kaum aufzuspüren. dazu müsste der ganze videostrom decodiert und auf seine konformität überprüft werden.
Der Fehler liegt im moov atom und ist somit ziemlich leicht scanbar:
The specific flaw exists within the moov atom. By specifying an invalid value for a field within the moov atom, an attacker can write data outside of an allocated heap buffer. An attacker could leverage this to execute arbitrary code under the context of the QuickTime player.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
