Sicherheitsaspekte bei Multimedia

Datenflussdiagramm

Das Diagramm zeigt die übergeordneten Datenverarbeitungselemente in „ Qt Multimedia “, die zum sicheren Umgang mit nicht vertrauenswürdigen Medienquellen beitragen.

Annahmen

Wie auch der Rest von Qt geht „ Qt Multimedia “ davon aus, dass die Ausführungsumgebung korrekt konfiguriert und nicht kompromittiert ist. Insbesondere wird davon ausgegangen, dass die Prozessumgebung, die Suchpfade, aus denen Bibliotheken und Plugins geladen werden, sowie die installierten Hardware-Decodier-Treiber von demjenigen kontrolliert werden, der die Anwendung bereitstellt, und nicht von einem Angreifer. Angriffe, die eine bereits unsichere Prozessumgebung erfordern, fallen außerhalb des Geltungsbereichs der Sicherheitsverantwortung von Qt, wie im Qt Shared Security Model beschrieben.

Die Medieninhalte selbst fallen nicht unter diese Annahme. Mediendaten und die URLs, die auf sie verweisen, werden als nicht vertrauenswürdige Eingaben behandelt und sind Gegenstand des restlichen Teils dieser Seite. Siehe auch „Umgang mit nicht vertrauenswürdigen Daten“.

Einige der folgenden Punkte werden daher nicht deshalb aufgeführt, weil „ Qt Multimedia “ Schutz vor ihnen bietet, sondern weil sie in die Verantwortung des Anwendungsentwicklers fallen und bei der Bereitstellung einer Anwendung berücksichtigt werden müssen.

Risiken

Theoretisch gilt: Wenn eine Anwendung es Benutzern erlaubt, nicht vertrauenswürdige Medienquellen abzuspielen, und ein Angreifer eine Schwachstelle in einem der in der obigen Abbildung dargestellten Elemente kennt, kann er eine Medienquelle erstellen, die die Schwachstelle auslöst, und diese der Anwendung auf die vorgesehene Weise bereitstellen.

Die folgenden Risiken sind entsprechend den im Qt Shared Security Model definierten Rollen nach den Verantwortlichen für ihre Behebung gruppiert.

Von Qt behobene Risiken

• Sicherheitslücken in Bibliotheken von Drittanbietern, die mit „ Qt Multimedia “ ausgeliefert werden. „ Qt Multimedia “ versucht nicht, eine kompromittierte Bibliothek eines Drittanbieters einzudämmen; daher schützt nur die Aktualisierung dieser Bibliotheken die Anwendung. Wir verfolgen gemeldete Sicherheitslücken in den von uns ausgelieferten Bibliotheken, aktualisieren sie, sobald Patch-Versionen verfügbar sind, und melden die von uns selbst gefundenen Fehler an die Upstream-Projekte.
• Qt Multimedia Fehler in den eigenen Datenflusselementen von „ Qt Multimedia “, die zu undefiniertem Verhalten führen können. Der sensibelste Bereich ist die Verarbeitung des Datenlayouts von nativen und Backend-Medienframes. Wir befolgen etablierte Praktiken für sicheres Programmieren, decken diesen Code mit manuellen und automatisierten Tests ab und führen intern Fuzz-Tests an „ “ durch, um Fehler zu finden, die diese Tests nicht abdecken.

Vom Anwendungsentwickler zu berücksichtigende Risiken

• Mehrere Qt Multimedia -APIs verwenden eine URL als Quelle oder Ziel und führen im Auftrag der Anwendung Dateisystem- oder Netzwerkzugriffe durch. Dazu gehören QMediaPlayer::setSource, QAudioDecoder::setSource, QSoundEffect::setSource und QMediaRecorder::setOutputLocation. Die Übergabe einer nicht validierten URL an diese APIs ermöglicht es daher demjenigen, der diese URL kontrolliert, zu entscheiden, welche Dateien gelesen oder geschrieben werden und welche Hosts kontaktiert werden.
• Beim GStreamer-Medien-Backend kann durch die Übergabe einer bösartigen, benutzerdefinierten GStreamer-Pipeline-Beschreibung an QGStreamerVideoSource oder QMediaPlayer ein Sicherheitsrisiko entstehen. Wir empfehlen dringend, niemals eine nicht vertrauenswürdige GStreamer-Medien-Pipeline mit Qt Multimedia auszuführen, es sei denn, Sie können GStreamer-Pipeline-Beschreibungen sinnvoll vorverarbeiten und validieren.
• Ein Medien-Backend wird nur verwendet, wenn sein Plugin tatsächlich geladen werden kann. Das FFmpeg-Medien-Backend bindet sich dynamisch an die FFmpeg-Bibliotheken. Wenn diese Binärdateien also nicht zusammen mit der Anwendung bereitgestellt werden oder beim Laden des Plugins vom dynamischen Linker nicht aufgelöst werden können, weicht „ Qt Multimedia “ ohne Warnung auf ein anderes verfügbares Backend aus. Die verbleibenden Backends werden in der Reihenfolge ausprobiert, in der ihre Plugins aufgelistet sind, und nicht in einer dokumentierten Präferenzreihenfolge. Ein Fehler bei der Bereitstellung kann daher dazu führen, dass die Anwendung auf einem Backend läuft, das dafür nie getestet wurde. Wenn überhaupt kein Backend geladen werden kann, bleiben nur QMediaDevices, QAudioDevice, QSoundEffect, QAudioSink und QAudioSource funktionsfähig.

Risiken, die von der Betriebsumgebung abhängen

Diese Risiken ergeben sich aus der Umgebung, in der die Anwendung ausgeführt wird, und nicht aus „ Qt Multimedia “ selbst; „ Qt Multimedia “ kann sie weder erkennen noch verhindern. Der Anwendungsentwickler muss sie bei der Bereitstellung der Anwendung berücksichtigen.

• Falsche Konfiguration der Umgebung oder der Treiber für die Hardware-Decodierung. Stellen Sie sicher, dass die Umgebung korrekt konfiguriert ist und dass die Treiber für die Hardware-Decodierung ordnungsgemäß installiert und auf dem neuesten Stand sind.
• Qt Multimedia wählt sein Medien-Backend zur Laufzeit aus, und die Auswahl kann mit der Umgebungsvariable QT_MEDIA_BACKEND überschrieben werden, wie unter „Backends ändern“ beschrieben. Jeder, der Einfluss auf die Umgebung des Anwendungsprozesses nehmen kann, kann daher bewirken, dass die Anwendung auf einem anderen Medien-Backend läuft als dem, für das sie entwickelt und getestet wurde – mit einem anderen Satz unterstützter Formate und Protokolle sowie einer anderen Angriffsfläche.

Auswirkungen

Die Ausnutzung der oben aufgeführten Probleme kann zu folgenden Sicherheitsfolgen führen:

• Undefiniertes Verhalten, das in der Praxis zu Speicherlecks, zum Absturz der Anwendung oder zum Einfrieren führen kann.
• Die Ausführung von Remote-Code könnte möglich sein, wann immer ein Angreifer eine Heap-Korruption sinnvoll ausnutzen kann.
• Bei Medienformaten wie m3u, die die Verwendung verschiedener Protokolle in Playlist-Einträgen zulassen, kann eine fehlerhafte Konfiguration es einem Angreifer ermöglichen, das Dateisystem auszulesen oder beliebige Netzwerkhosts zu kontaktieren. Standardmäßig werden potenziell gefährliche Protokolle auf einer Sperrliste geführt, doch dieses Verhalten kann durch eine der folgenden Maßnahmen geändert werden:
  • Umgebungskonfiguration. Siehe „Konfigurieren zulässiger Netzwerkprotokolle für das FFmpeg-Medien-Backend“.
  • Benutzerdefinierte GStreamer-Pipeline. Weitere Informationen finden Sie in den Hinweisen zum GStreamer-Backend vonQt Multimedia , unter QGStreamerVideoSource sowie in der Dokumentation zur GStreamer-Pipeline.
  • Ein anderes Medien-Backend als die mit Qt Multimedia mitgelieferten. Das Medien-Backend wird zur Laufzeit als Plugin geladen. Daher wendet ein Backend-Plugin, das in den Plugin-Suchpfaden der Anwendung gefunden wird, oder eine ersetzte FFmpeg-Binärdatei, die in den Bibliothekssuchpfaden der Anwendung gefunden wird, die Protokollbeschränkungen an, mit denen es erstellt wurde, anstatt der oben genannten Standardwerte.

Beachten Sie, dass je nach Medienformat selbst eine gültige Medienquelle nicht unbedingt streng dem jeweiligen Medienstandard entspricht. Es gibt zudem zahlreiche Möglichkeiten, wie eine Quelle beschädigt oder ungültig gemacht werden kann. Trotz der manuellen und automatisierten Tests, die von den jeweiligen Communities an „ Qt Multimedia “ und Bibliotheken von Drittanbietern durchgeführt werden, können wir keine korrekte Verarbeitung jeder einzelnen fehlerhaften Medienquelle garantieren. Berücksichtigen Sie diese Einschränkung bei der Entwicklung von Anwendungen mit hohen Sicherheitsanforderungen.

Abhilfemaßnahmen

• Behandeln Sie jede URL, die nicht aus der Anwendung selbst stammt, als nicht vertrauenswürdige Eingabe und validieren Sie sie, bevor Sie sie an „ Qt Multimedia “ weiterleiten. Bevorzugen Sie eine Zulassungsliste mit akzeptierten URL-Schemas und Hosts gegenüber einer Sperrliste mit abgelehnten. Wenn die Anwendung bereits über die Mediendaten verfügt oder diese selbst beziehen kann, behält die Anwendung mit „ QMediaPlayer::setSourceDevice “ die Kontrolle darüber, wie die Daten gelesen werden.
• Schränken Sie die Protokolle ein, die das Medien-Backend verwenden darf. Für das FFmpeg-Medien-Backend siehe „Konfiguration zulässiger Netzwerkprotokolle “ im Abschnitt „Erweiterte FFmpeg-Konfiguration“.
• Steuern Sie, welches Medien-Backend die bereitgestellte Anwendung nutzen kann. Die effektive Steuerung erfolgt hier durch die Bereitstellung nur des Medien-Backend-Plugins, das die Anwendung benötigt, da „ QT_MEDIA_BACKEND “ so kein anderes Plugin zur Auswahl hat. Beachten Sie, dass die Wahl eines anderen Standard-Backends allein nicht ausreicht: „ QT_MEDIA_BACKEND “ hat Vorrang vor dem Standard, auch vor einem Standard, der mit der Konfigurationsoption „ -default-media-backend “ festgelegt wurde, wenn „ Qt Multimedia “ selbst aus dem Quellcode kompiliert wurde.
• Vergewissern Sie sich im Rahmen der Bereitstellungstests, dass die Anwendung tatsächlich auf dem vorgesehenen Medien-Backend läuft. Die Protokollkategorie „ qt.multimedia.plugin “ gibt an, welches Backend geladen wurde und welche Plugins zuvor nicht geladen werden konnten.
• Die mit dem „ Qt Online Installer “ ausgelieferten „ Qt Multimedia “-Binärdateien sind dynamisch mit den FFmpeg-Bibliotheken „ avcodec “, „ avutil “, „ avformat “, „ swscale “ und „ swresample “ verknüpft. Ein Anwendungsentwickler oder Endbenutzer kann daher eigene, binärkompatible Builds dieser Bibliotheken – d. h. Builds derselben FFmpeg-Hauptversion – bereitstellen, um FFmpeg-Sicherheitslücken zu beheben, ohne auf die Veröffentlichung eines Qt-Patches warten zu müssen.