Gedanken zum Tainted Mode in der Programmierung

Gedanken zum Tainted Mode in der Programmierung

Marc Ruef
by Marc Ruef
time to read: 7 minutes

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

About the Author

Marc Ruef

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

You need support in such a project?

Our experts will get in contact with you!

×
Specific Criticism of CVSS4

Specific Criticism of CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentication

Voice Authentication

Marc Ruef

Bug Bounty

Bug Bounty

Marc Ruef

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here