Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03259.jsonl.gz/775

Password Leak Analyse
Marc Ruef
Eines der Grundprinzipien von sicherheitsbezogenen Source Code Analysen basiert darauf, dass potentiell böswillige Daten erkannt und deren Verarbeitung geprüft wird. Als böswillig werden alle Daten verstanden, die aus einer nicht-vertrauenswürdigen Quelle stammen. In erster Linie sind dies Benutzereingaben, wie sie bei PHP-Skripten beispielsweise durch $_GET, $_POST, $_REQUEST, $_COOKIE und teilweise $_SERVER bereitgestellt werden. Derlei Daten werden in der englischen Literatur auch als infected, tainted, dirty, contaminated oder unclean bezeichnet.
In einer manuellen Analyse wird sodann mittels Program Slicing der Datenpfad der böswilligen Daten ermittelt. Lösungen wie codEX versuchen diese Arbeit – in diesem Fall gar sprachunabhängig – zu automatisieren. Dennoch ist immer ein gewisser Arbeitsaufwand erforderlich, um der Komplexität einer Sprache gerecht zu werden.
Manche Sprachen, allen voran Ruby und Perl, unterstützen einen sogenannten Taint Mode. Bei diesem kennzeichnet die Sprache ein Objekt als potentiell gefährlich und schränkt entsprechend die Weiterverarbeitung bei sicherheitskritischen Funktionen ein. Bei Ruby wird in der Variable
$SAVE ein Wert zwischen 1 und 4 gespeichert, um als Save-Level den Grad der Einschränkungen zu bestimmen. Mit der Methode
.tainted? kann sodann geprüft werden, ob ein Objekt restriktiv behandelt wird. Bei Perl 4 muss ein Skript mit
/usr/local/bin/taintperl und bei Perl 5 mit
/usr/local/bin/perl -T aufgerufen werden, um einen ähnlichen Effekt zu erzielen. Nachfolgende Tabelle zeigt die Einstufung durch Ruby:
|Level||Beschreibung|
|0||Es wird kein Einfluss durch den Tainted Mode ausgeführt. Dies ist die Standardeinstellung von Ruby.|
|>=1||Es wird die Nutzung von Tainted Daten durch potenziell gefährliche Operationen verhindert.|
|>=2||Es wird das Laden von Programm-Dateien von global beschreibbaren Orten verhindert.|
|>=3||Alle neu erzeugten Objekte werden standardmässig als tainted markiert.|
|>=4||Ruby teilt das Programm quasi in zwei Teile auf, wobei als tainted markierte Objekte nicht mehr verändert werden können.|
Sicherheitstechnisch interessant ist an diesem Konzept die Vererbung des Tainted-Status. Es stellt sich nämlich die Frage, inwiefern ein gesamtes Objekt oder Teile davon bei einer Übernahme in ein anderes/neues Objekt Einfluss auf den Status ausübt. Hierbei kann zwischen sieben verschiedenen Übernahmevarianten unterschieden werden:
|Übernahmetyp||Beispiel (PHP)|
|Komplett|| |
|Partiell|| |
|Indirekt|| |
|Manipuliert|| |
|Konstruiert|| |
|Berechnet|| |
|Typisiert|| |
Streng genommen bleibt bei jeglicher Übernahme der Tainted-Status bestehen und wird auf das neue Objekt vererbt. Dies ist natürlich nicht immer korrekt, denn so können beispielsweise Assertion, Typenumwandlungen und Encodierungen dabei helfen, grundlegende Angriffstechniken unwirksam werden zu lassen. Dennoch bleibt es in diesem Zusammenhang die Aufgabe des Programmierers, dass er die betroffenen Objekte manuell untainted. Der Tainted Mode ist damit nicht nur eine technische Stütze bei der Entwicklung, sondern auch eine psychologische Hilfe bei der Qualitätssicherung.
In jedem Fall ist die Nutzung eines solchen zu empfehlen und damit auch in anderen Sprachen – allen voran PHP (Vorschlag auf der PHP-Mailingliste) – wünschenswert. PHP hatte zwar mit dem safe_mode eine ähnliche Funktion eingeführt, dabei jedoch das Pferd rückwärts aufgezäumt: Nicht die Quelle der Daten, sondern Funktionsaufrufe als solche wurden als Grundlage für Einschränkungen verwendet. Ein unbeliebter und unnützer Effekt dieser Methode war, dass auch legitime Daten und Funktionsrufe pauschal eingeschränkt wurden. Eine gänzliche Entfernung dieser Konfigurationseinstellung mit PHP 5.3.0 bzw. 6.0 erschien sodann naheliegend (PHP kann beispielsweise mit Core Grasp um eine Art Tainted-Funktionalität erweitert werden).
Unsere Spezialisten kontaktieren Sie gern!
Marc Ruef
Marc Ruef
Marc Ruef
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv