Ich versuche, PCI-kompatibel zu werden, und das PCI-Scan-Unternehmen markiert unser Ubuntu 12.04 PHP 5.3.10-1ubuntu3.9 für CVE-2013-1635. Lauthttp://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-1635.htmlDie Ubuntu-Antwort lautet „Wir unterstützen den Benutzer von open_basedir nicht“ und alle Versionen wurden als ignoriert markiert.
Ich weiß nicht, was ich hier tun soll. Ich habe meine Scan-Firma auf dieselbe URL verwiesen, aber sie akzeptieren das nicht als Antwort.
Was soll ich machen?
Aktualisieren
Ich verwende diese Funktion nicht und die Direktive open_basedir ist in php.ini deaktiviert. Sie halten dies jedoch nicht für eine geeignete Lösung.
Hier ist ihre Antwort auf die Ablehnung meines Einspruchs:
Wir haben diesen Streit aufgrund der bereitgestellten Informationen bezüglich der Behandlung dieses Befunds abgelehnt. Es wurde festgestellt, dass die derzeit auf diesem System ausgeführte PHP-Version die vom Benutzer bereitgestellten Eingaben nicht ordnungsgemäß bereinigt. Obwohl „open_basedir“ auf diesem System deaktiviert ist, kann ein Angreifer dieses Problem ausnutzen und WSDL-Dateien im Kontext der betroffenen Anwendung schreiben. Außerdem wurde festgestellt, dass auch andere Angriffe möglich sind. Infolgedessen legt die Direktive „soap.wsdl_cache_dir“ den Verzeichnisnamen fest, in dem die SOAP-Erweiterung die Cache-Dateien ablegt. Das Deaktivieren von „open_basedir“ hat 1) nicht bereits vorhandene Cache-Dateien entfernt und/oder 2) nicht verhindert, dass neue Cache-Dateien in einem beliebigen Verzeichnis abgelegt werden können.
Lesen Sie bittehttps://www.pcisecuritystandards.org/security_standards/glossary.php#Compensating%20Controlsfür die Definition einer kompensierenden Kontrolle. Unter anderem müssen „kompensierende Kontrollen: … über andere PCI DSS-Anforderungen hinausgehen (nicht einfach nur andere PCI DSS-Anforderungen erfüllen)“, und das Deaktivieren von „open_basedir“ geht nicht wirklich darüber hinaus, das zugrunde liegende Problem sollte hier wirklich angegangen werden. Noch einmal: Die im Scanbericht aufgeführten Anforderungen bestehen darin, das System zu aktualisieren oder die genannten kompensierenden Kontrollen zu verwenden (wobei das Deaktivieren von „open_basedir“ in diesem Fall nicht ausreichen würde).
Bei allen Problemen, die auf einem System erkannt werden, das in den Geltungsbereich der PCI-DSS-Konformität fällt, müssen alle PCI-nichtkonformen Probleme behoben werden (das betrifft alle Systeme, die an der Speicherung, Verarbeitung und/oder Übertragung von Kreditkarteninhaberdaten beteiligt sind, und alle Systeme, die direkt mit einem an solchen Prozessen beteiligten Netzwerk verbunden sind und für die keine entsprechende Netzwerksegmentierung eingerichtet ist).
Bitte überprüfen Sie den Scanbericht und befolgen Sie die Vorschläge in der Spalte „Behebung“. Führen Sie dann einen weiteren Scan durch, wenn die Sicherheitslücke behoben wurde, um den Befund aus Ihrem nächsten Scanbericht zu löschen.
Wenn die Sicherheitslücke danach weiterhin besteht und/oder Sie dies bereits getan haben, können Sie diese Sicherheitslücke jederzeit erneut anfechten und erklären, was zur Behebung des Befunds unternommen wurde.
Antwort1
Es scheint verdächtig, dass Ubuntu eine Standard-PHP-Konfigurationsanweisung „nicht unterstützt“, da bereits zuvor Fehler damit behoben wurden (zum Beispiel).
Bearbeiten: Es scheint, als hätten Debian und Red Hat tatsächlich die gleiche Richtlinie – „nicht unterstützen“ ist eine schlechte Formulierung, aber alle diese Distributionen sind der Meinung, dass Mängel in einem von Natur aus fehlerhaften Sicherheitsmechanismus kein Problem darstellen.
Dies ist jedoch wahrscheinlich irrelevant. Überprüfen Sie Ihr php.iniSystem open_basedir. Wenn es nicht vorhanden ist, sind Sie von diesem Sicherheitsproblem überhaupt nicht betroffen, da der Fehler eine Umgehung der Sicherheitsbeschränkungen darstellt, die open_basedirbereitgestellt werden.
Wenn Ihr Prüfer darin jedoch besonders schlecht ist, ist es vielleicht am besten, ihm nicht mehr zu zeigen, welche PHP-Version Sie verwenden – die Überprüfung von Versionszeichenfolgen ist ohnehin eine furchtbare Methode zur Schwachstellenbewertung. Wenn es sich um einen Apache-Webserver handelt, der seine Versionszeichenfolgen anzeigt, geben Sie ihm ServerSignature Offund ServerTokens Prod.
Bearbeiten Sie die Antwort, die Sie erhalten haben, mit Notizen …
Es wurde festgestellt, dass die derzeit auf diesem System ausgeführte PHP-Version die vom Benutzer bereitgestellten Eingaben nicht richtig bereinigt.
Dieser Fehler hat nichts mit der Bereinigung der Eingabe zu tun, sondern ist ein Fehler in einer Sandboxing-Mechanik.
Obwohl „open_basedir“ auf diesem System deaktiviert ist, kann ein Angreifer dieses Problem ausnutzen und WSDL-Dateien im Kontext der betroffenen Anwendung schreiben.
Ich bin keineswegs ein Experte für die internen Vorgänge von PHP, aber das scheint eine schwerwiegende Fehlinterpretation der Sicherheitslücke zu sein. Soweit ich das über diesen Fehler sagen kann, besteht das Problem darin, dass ein Angreifer die WSDL-Caching-Mechanik verwenden kann, um eine WSDL von einem Verzeichnis außerhalb des open_basedirStammverzeichnisses zu laden (aber wahrscheinlich immer noch innerhalb des soap.wsdl_cache_dir, das standardmäßig auf eingestellt ist /tmp).
Damit dies überhaupt von Bedeutung ist, müssten Sie über Dateien verfügen, die tatsächlich auf diese Weise angesteuert werden könnten, und über eine Zugriffsmethode, um die Zwischenspeicherung auszulösen (vielleicht eine Verzeichnisnavigation auf Ihrem Webserver?).
In jedem Fall ist das Auslösen der Erstellung eines zwischengespeicherten WSDL auf der Grundlage von bereits im System vorhandenen Inhalten etwas ganz anderes als das Schreiben von Dateien in Ihre Webanwendung.
Als Ergebnis legt die Direktive „soap.wsdl_cache_dir“ den Verzeichnisnamen fest, in dem die SOAP-Erweiterung die Cachedateien ablegt. Durch das Deaktivieren von „open_basedir“ wurden 1) bereits vorhandene Cachedateien nicht entfernt und/oder 2) die Möglichkeit, neue Cachedateien in einem beliebigen Verzeichnis abzulegen, nicht verhindert.
Obwohl in der CVE tatsächlich von „beliebigem Verzeichnis“ die Rede ist, scheint eigentlich „das konfigurierte WSDL-Cache-Verzeichnis“ gemeint zu sein. Diese Sicherheitslücke wäre noch viel schwerwiegender, wenn sie eine Komponente zur Verzeichnisdurchquerung enthalten würde. In Wirklichkeit wurde lediglich eine Validierung hinzugefügt, um sicherzustellen, dass sich das Cache-Verzeichnis innerhalb des befindet open_basedir. SieheHier.
das Deaktivieren von 'open_basedir' geht nicht wirklich darüber hinaus, das zugrunde liegende Problem sollte hier wirklich angesprochen werden
Das ist Unsinn. Dies ist ein Fehler, bei dem das WSDL-Cache-Verzeichnis nicht richtig überprüft hat, ob es sich innerhalb befindet open_basedir. Wenn Sie kein konfiguriert haben open_basedir, ist die gesamte Sicherheitslücke völlig irrelevant – es wurden keine anderen Änderungen vorgenommen, um irgendeinen zusätzlichen Sicherheitsvorteil zu bieten.