Das Qt-Modell für geteilte Sicherheit

Das Qt Shared Security Model definiert die Verteilung der Sicherheitsverantwortlichkeiten zwischen Qt-Anwendungsentwicklern, der Qt Group und dem Qt Project als Anbietern des Qt-Frameworks sowie Betreibern oder Geräteherstellern. Das Modell legt klare Erwartungen hinsichtlich der Sicherheitsverantwortung über die verschiedenen Schichten des Technologie-Stacks in einer typischen Qt-Anwendung oder einem typischen Qt-Gerät fest.

Diese Seite bietet Leitlinien für Entwickler, die Qt-Anwendungen erstellen, sowie für Sicherheitsforscher, die Sicherheitsprobleme in Qt melden.

Überblick

Sicherheit in Qt-Anwendungen ist eine gemeinsame Verantwortung. Qt stellt sichere Frameworks und Bibliotheken bereit, doch die letztendliche Sicherheit einer Anwendung hängt davon ab, wie Entwickler diese Komponenten nutzen und wie sie mit anwendungsspezifischen Aspekten umgehen.

Eine typische Qt-Anwendung lässt sich als Stapel veranschaulichen:

Rollen und Verantwortlichkeiten

Verantwortlichkeiten des Anwendungsentwicklers

Als Anwendungsentwickler sind Sie für die Sicherheit des anwendungsspezifischen Codes, der Assets und der Konfiguration verantwortlich. Sie übernehmen zudem die Verantwortung für alle eigenständigen Bibliotheken von Drittanbietern, die mit der Anwendung ausgeliefert werden.

Qt ist bestrebt, eine benutzerfreundliche API bereitzustellen, die standardmäßig sicher ist. Es liegt jedoch in Ihrer Verantwortung, die API sorgfältig zu nutzen und beispielsweise auf Fehlerzustände zu prüfen und diese angemessen zu behandeln. Einen Überblick über Sicherheitsaspekte bei der Verwendung von Qt finden Sie unter „Sicherheit in Qt“.

Überprüfen Sie Ihre Anwendung dahingehend, welche Datenquellen vertrauenswürdig und welche nicht vertrauenswürdig sind. Stellen Sie sicher, dass nicht vertrauenswürdige Daten mithilfe geeigneter Qt-APIs validiert und bereinigt werden. Weitere Informationen finden Sie unter „Umgang mit nicht vertrauenswürdigen Daten “.

Planen Sie Mechanismen ein, um die Anwendung zu aktualisieren und Qt-Sicherheitsupdates zeitnah zu installieren. Verfolgen Sie Qt-Veröffentlichungen und Sicherheitsankündigungen und aktualisieren Sie Qt entsprechend. Stellen Sie außerdem sicher, dass Sie Qt aus einer vertrauenswürdigen Quelle beziehen.

Das Gleiche gilt für die von Ihnen erstellten Projekte. Die Entwicklertools von Qt laufen auf Ihrem Build-Rechner und behandeln das von ihnen verarbeitete Projekt als vertrauenswürdige Eingabe. Erstellen Sie daher Projekte nur aus Quellen, denen Sie vertrauen. Weitere Informationen finden Sie unter „Sichere Nutzung der Qt-Entwicklertools“.

Wenn Sie Qt als Teil Ihrer Anwendung ausliefern, beschränken Sie die Anzahl der Bibliotheken und Plugins, um die Angriffsfläche zu verringern. Liefern Sie beispielsweise nur die Bild-Plugins für die Formate aus, die Sie tatsächlich benötigen.

Achten Sie beim Ändern der Qt-Standardeinstellungen darauf, dass Sie nicht versehentlich Sicherheitsfunktionen deaktivieren oder Sicherheitsgarantien schwächen. Deaktivieren Sie beispielsweise die SSL/TLS-Zertifikatsvalidierung nur, wenn Sie einen sehr guten Grund dafür haben. Ein weiteres Beispiel sind Änderungen an den Qt-Suchpfaden, beispielsweise über die Datei „qt.conf“. Stellen Sie sicher, dass alle Pfade vertrauenswürdig sind.

Verantwortlichkeiten von Qt

Die Qt Group und das Qt-Projekt sind für die Sicherheit des Qt-Frameworks selbst verantwortlich, einschließlich aller offiziell vertriebenen Binärdateien und weiterverteilbaren Komponenten. Dazu gehören die Wartung und Aktualisierung aller mit Qt-Bibliotheken und -Plugins gebündelten Komponenten von Drittanbietern, die Verfolgung bekannter Schwachstellen sowie die Bereitstellung zeitnaher Korrekturen.

Qt ist bestrebt, APIs bereitzustellen, die standardmäßig sicher sind. Gängige Anwendungsfälle sind so konzipiert, dass das Risiko eines Missbrauchs minimiert wird, während Vorgänge mit sicherheitsrelevanten Auswirkungen explizite Maßnahmen seitens der Entwickler erfordern.

Qt stellt APIs bereit, mit denen Entwickler Daten aus nicht vertrauenswürdigen Quellen – wie Benutzereingaben, Netzwerkkommunikation oder externe Dateien – verarbeiten und validieren können. In Fällen, in denen es für einen Entwickler unzumutbar ist, eine eigene Validierung zu implementieren, bietet Qt eine integrierte Validierung an. So sind beispielsweise die Bilddecoder von Qt darauf ausgelegt, Bilddateien sicher zu analysieren. Es kann jedoch APIs geben, bei denen beides weder möglich noch zumutbar ist; in diesen Fällen warnt die Dokumentation vor dem Aufruf der API mit nicht vertrauenswürdigen Daten.

Verantwortlichkeiten des Betreibers oder Geräteherstellers

Sowohl Qt als auch die Anwendung müssen sich auf die Sicherheit und Integrität der Betriebsumgebung (Hardware, Betriebssystem und Dienste) verlassen können. Auf Desktop-Systemen liegt dies in der Regel in der Verantwortung des Betreibers der Anwendung, beispielsweise durch die regelmäßige Aktualisierung des Betriebssystems. Bei eingebetteten Geräten liegt die Verantwortung beim Gerätehersteller.

Dies umfasst auch die Prozessumgebung, in der die Qt-Anwendung ausgeführt wird. So gehen beispielsweise alle Desktop-Anwendungen davon aus, dass die Verzeichnisse in der Umgebungsvariablen „ PATH “ vertrauenswürdig sind.

Annahmen

Die Sicherheitsgarantien von Qt und die nachstehenden Akzeptanzkriterien beruhen auf den folgenden grundlegenden Annahmen bezüglich der Umgebung, in der eine Qt-Anwendung ausgeführt wird. Sollte eine dieser Annahmen nicht zutreffen, fallen die damit verbundenen Probleme außerhalb des beabsichtigten Verwendungszwecks und der unterstützten Nutzungsbedingungen, auf denen die Cybersicherheits-Risikobewertung von Qt basiert, und werden daher nicht als Schwachstellen in Qt behandelt.

• Der Angreifer hat noch keine Kontrolle über das Gerät oder das Konto: Qt schützt nicht vor einem Angreifer, der bereits physische oder Fernkontrolle über das Gerät, auf dem die Anwendung läuft, oder über das Benutzerkonto, unter dem sie ausgeführt wird, besitzt (z. B. ein gestohlenes oder entsperrtes Gerät, eine offene Remote-Desktop-Sitzung oder ein kompromittiertes Konto), unabhängig davon, ob er den Anwendungsprozess selbst erreichen kann. Entscheidend ist, ob der Angreifer dadurch Berechtigungen, Zugriff oder Vertrauen erlangt, über die er zuvor nicht verfügte. Wenn ein nicht privilegierter lokaler Akteur die Berechtigungen der Anwendung erlangt oder diese durch Daten beeinflusst, die an einer von der Anwendung gelesenen Stelle platziert wurden, wurde eine Sicherheitsgrenze überschritten und das Problem fällt in den Geltungsbereich, auch wenn der Angriff lokal erfolgt. Siehe auch „Probleme, die Qt nicht akzeptiert“.
• Das Betriebssystem und seine Umgebung sind korrekt konfiguriert: Qt geht davon aus, dass das Betriebssystem, seine Konfiguration und die Prozessumgebung (wie die Variablen „ PATH “ und „ QT_PLUGIN_PATH “) nicht manipuliert oder falsch konfiguriert wurden. Siehe „Verantwortlichkeiten des Betreibers oder Geräteherstellers“.
• Die angeschlossene Hardware ist original: Qt geht davon aus, dass die Hardware, mit der die Anwendung interagiert (Peripheriegeräte, Sensoren oder andere angeschlossene Geräte), original ist und nicht ausgetauscht oder physisch manipuliert wurde. Dies gilt nicht für die Daten, die diese Hardware sendet: Von externen Geräten empfangene Eingaben sind nicht vertrauenswürdige Eingaben, und über sie erreichbare Fehler fallen weiterhin in den Geltungsbereich. Siehe „Umgang mit nicht vertrauenswürdigen Daten“.

Akzeptanzkriterien für Sicherheitsprobleme

Sicherheitsforscher sollten sich bei der Entscheidung, ob ein potenzielles Sicherheitsproblem dem Qt-Projekt gemeldet werden sollte, an die folgenden Richtlinien halten:

Probleme, die Qt akzeptiert

Die Qt Group und das Qt-Projekt akzeptieren Sicherheitsprobleme, die:

• den Qt-Framework-Code betreffen: Sicherheitslücken im Qt-eigenen Code, einschließlich Fehler durch Speicherbeschädigung, Typverwechslungen, „Use-after-free“, Pufferüberläufe und ähnliche Probleme mit der Speichersicherheit in Qt-Bibliotheken.
• die mitgelieferten Komponenten von Drittanbietern betreffen: Sicherheitslücken in Bibliotheken und Komponenten von Drittanbietern, die mit Qt mitgeliefert werden.
• Sicherheitsgarantien verletzen: Probleme, bei denen Qt-APIs die dokumentierten Sicherheitsgarantien nicht erfüllen oder gegen angemessene Sicherheitserwartungen für sicherheitskritische APIs verstoßen.
• die Standardkonfigurationen betreffen: Sicherheitsprobleme in den Standardkonfigurationen von Qt, die typische Anwendungen ohne Eingreifen des Entwicklers beeinträchtigen könnten.

Qt erwartet außerdem, dass Sicherheitsprobleme ein realistisches Angriffsszenario aufweisen. Probleme, die in der Praxis nicht ausgenutzt werden können oder unrealistische Bedingungen erfordern, werden als Fehler behandelt, jedoch nicht als Sicherheitsprobleme betrachtet.

Probleme, die Qt nicht akzeptiert

Die Qt Group und das Qt-Projekt akzeptieren keine Meldungen zu Sicherheitsproblemen, die:

• Unsicheren Anwendungscode erfordern: Probleme, die nur dann auftreten, wenn der Anwendungsentwickler unsicheren Code schreibt oder Qt-APIs in einer Weise missbraucht, die nicht der Dokumentation oder etablierten Best Practices entspricht.
• auf anwendungsspezifischen Logikfehlern beruhen: Sicherheitsprobleme in der anwendungsspezifischen Logik, wie z. B. Umgehung der Authentifizierung, Autorisierungsfehler oder Schwachstellen in der Geschäftslogik.
• Von bösartigem Anwendungscode abhängen: Probleme, bei denen die Anwendung bösartigen Code ausführen muss. Qt geht davon aus, dass Anwendungsentwickler die Kontrolle über ihren eigenen Code und ihre Ressourcen haben.
• bösartigen QML-/JavaScript-Code erfordern: Qt Qml Es wird davon ausgegangen, dass der gesamte QML- und JavaScript-Code vom Anwendungsentwickler bereitgestellt wird. Die Ausführung von nicht vertrauenswürdigem QML-Code wird nicht unterstützt. Weitere Informationen finden Sie unter „Umgang mit nicht vertrauenswürdigen Daten “.
• Abhängigkeit von Problemen in der Betriebsumgebung: Schwachstellen im zugrunde liegenden Betriebssystem, in der Hardware oder in Systembibliotheken, die nicht im Lieferumfang von Qt enthalten sind.
• Abhängigkeit von einer unsicheren Prozessumgebung: Angriffe, die eine unsichere Prozessumgebung erfordern, wie z. B. nicht vertrauenswürdige Verzeichnisse in den Umgebungsvariablen „ PATH “ oder „ QT_PLUGIN_PATH “, fallen nicht in den Bereich der Sicherheitsverantwortung von Qt.
• Abhängigkeit von privaten Qt-Header-Dateien: Die Verwendung privater Header-Dateien widerspricht dem vorgesehenen Verwendungszweck von Qt und stellt keine unterstützte Konfiguration dar. Schwachstellen, die nur durch die Verwendung privater Header-Dateien ausnutzbar sind, fallen nicht unter den vorgesehenen Verwendungszweck und die unterstützten Nutzungsbedingungen, auf denen die Cybersicherheits-Risikobewertung von Qt basiert, und werden daher nicht als Schwachstellen behandelt. Dennoch begrüßen wir Meldungen über solche Schwachstellen, da sie auf Möglichkeiten hinweisen können, die Robustheit von Qt zu verbessern.
• Keine Auswirkungen auf die Bibliotheken, Plugins oder Tools von Qt: Die Autotests von Qt sowie die Infrastruktur, die zum Erstellen und Veröffentlichen von Qt verwendet wird, sind nicht Teil des bereitgestellten Produkts. Schwachstellen, die nur über diese zugänglich sind, werden in Qt nicht als Sicherheitslücken behandelt. Dateien und Tools des Build-Systems, die mit Qt ausgeliefert werden, fallen in den Geltungsbereich; siehe „Sichere Nutzung der Qt-Entwicklertools“.
• Betreffen nur Beispielcode: Die Beispiele von Qt veranschaulichen die Verwendung der API und sind nicht für den produktiven Einsatz vorgesehen. Schwachstellen in diesen Beispielen werden eher als Fehler denn als Sicherheitslücken behandelt, doch Meldungen sind willkommen, da Beispiele häufig in Anwendungen kopiert werden.

Darüber hinaus erfordern Meldungen zu Cybersicherheitsproblemen ein realistisches Angriffsszenario, das

• eine Sicherheitsgrenze überschreitet: Ein Problem überschreitet eine Sicherheitsgrenze, wenn es dem Angreifer Berechtigungen, Zugriff oder Vertrauen verschafft, über die er zuvor nicht verfügte. Beispielsweise gelten Probleme, bei denen der Angreifer bereits Zugriff auf den Anwendungsprozess haben und Code ausführen können muss, nicht als Sicherheitsprobleme, da der Angreifer diesen Zugriff bereits besitzt.
• nicht auf Social Engineering beruht: Probleme, die in erster Linie auf Social Engineering oder der Täuschung von Benutzern beruhen und nicht auf technischen Schwachstellen in Qt.

Häufig gestellte Fragen

Wer ist für die Validierung von Benutzereingaben verantwortlich?

Der Anwendungsentwickler ist für die Validierung von Benutzereingaben verantwortlich. Zwar stellt Qt Validierungstools zur Verfügung (siehe „ QValidator “ und „QML Validators“), doch liegt es in der Verantwortung der Anwendung, diese Tools angemessen einzusetzen und anwendungsspezifische Validierungslogik zu implementieren.

Ist Qt für SQL-Injection-Schwachstellen verantwortlich?

Nein. SQL-Injection-Schwachstellen resultieren in der Regel aus der unsachgemäßen Verwendung von SQL-APIs. Entwickler müssen parametrisierte Abfragen und vorbereitete Anweisungen (wie z. B. QSqlQuery::prepare) verwenden, um SQL-Injection zu verhindern. Qt ist jedoch dafür verantwortlich, sicherzustellen, dass diese sicheren APIs korrekt funktionieren.

Wie sieht es mit Cross-Site-Scripting (XSS) in Qt-Anwendungen aus?

Die Verhinderung von XSS liegt in erster Linie in der Verantwortung des Anwendungsentwicklers. Entwickler müssen Daten bei der Darstellung nicht vertrauenswürdiger Inhalte ordnungsgemäß bereinigen und escapen, insbesondere in Web-Views oder Rich-Text-Komponenten. Qt stellt APIs wie ` QString::toHtmlEscaped ` zur Unterstützung bereit und Qt WebEngine implementiert Sicherheitsfunktionen der Webplattform, doch die Anwendung muss diese korrekt nutzen.

Wer ist für die Verschlüsselung und die sichere Kommunikation zuständig?

Sowohl Qt als auch der Anwendungsentwickler tragen gemeinsam die Verantwortung:

• Qt stellt sichere Netzwerk-APIs (QSslSocket, QNetworkAccessManager) mit sicheren Standardeinstellungen bereit.
• Anwendungsentwickler müssen diese APIs ordnungsgemäß nutzen, die Zertifikatsvalidierung implementieren, Schlüssel sicher verwalten und sensibel mit Daten umgehen. Wenn sie OpenSSL in die Anwendung integrieren, liegt es ebenfalls in ihrer Verantwortung, es auf dem neuesten Stand zu halten und Sicherheitspatches anzuwenden.

Stellt das Laden von nicht vertrauenswürdigem QML-Code ein Sicherheitsrisiko dar?

Das Ausführen von nicht vertrauenswürdigem QML-Code wird ausdrücklich nicht unterstützt und gilt als Missbrauch der QML-Engine. Qt Qml Das System basiert auf der Annahme, dass der gesamte QML- und JavaScript-Code vertrauenswürdig ist und vom Anwendungsentwickler bereitgestellt wird. Wenn Ihre Anwendung nicht vertrauenswürdige Inhalte laden muss, verwenden Sie geeignete Sandboxing-Mechanismen oder alternative Ansätze, wie beispielsweise eine benutzerdefinierte domänenspezifische Sprache (DSL).

Wie sieht es mit Sicherheitslücken in Bilddateien aus?

Qt betrachtet die Bilddekodierung als sicherheitskritische API und übernimmt die Verantwortung für das sichere Parsen von Bilddateien aus nicht vertrauenswürdigen Quellen. Sicherheitsprobleme in den Bilddekodierern von Qt (Pufferüberläufe, Abstürze und ähnliche Probleme) sollten der Qt Group oder dem Qt Project gemeldet werden. Anwendungen müssen jedoch weiterhin Bildquellen validieren, große Bilder angemessen verarbeiten und anwendungsspezifische Sicherheitsaspekte im Zusammenhang mit Bildern berücksichtigen.

Wie melde ich ein Sicherheitsproblem?

Ausführliche Anweisungen zum Melden von Sicherheitsproblemen an das Qt-Projekt finden Sie unter „Sicherheitsprobleme melden “ auf der Seite „Sicherheit in Qt “.

Welche Qt-Versionen erhalten Sicherheitsupdates?

Sicherheitsupdates werden für unterstützte Qt-Versionen bereitgestellt. Informationen zu unterstützten Versionen finden Sie unter „Qt-Veröffentlichungen“ und Informationen zur erweiterten Sicherheitspflege für Versionen, deren Support ausgelaufen ist, unter „Erweiterte Sicherheitspflege “.

Weitere Ressourcen

Weitere Informationen zur Sicherheit in Qt finden Sie unter:

• Sicherheit in Qt
• Umgang mit nicht vertrauenswürdigen Daten
• Anwendungsberechtigungen
• QUIP 15 – Sicherheitsrichtlinie des Qt-Projekts
• Liste bekannter Sicherheitslücken in Qt-Produkten