Gedanken zum Tainted Mode in der Programmierung

Gedanken zum Tainted Mode in der Programmierung

Marc Ruef
von Marc Ruef
Lesezeit: 7 Minuten

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 $var2 = $var1;
Partiell $var2 = substr($var1, 0, 1);
Indirekt $vartmp = $var1; $var2 = $vartmp;
Manipuliert $var2 = encode_entities($var1);
Konstruiert $var2 = $var1."string\n";
Berechnet $var2 = $var1 * (1 + 2);
Typisiert $var2 = intval($var1);

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).

Über den Autor

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSS4

Konkrete Kritik an CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentisierung

Voice Authentisierung

Marc Ruef

Bug-Bounty

Bug-Bounty

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv