Seth Larson: str.lower() als Sicherheitslücke in Python
When str.lower() is a security vulnerability in Python – Seth Larson
Seth Larson zeigt, wie eine unscheinbare Python-Funktion zu einer Sicherheitslücke werden kann: str.lower() verwendet die Unicode-Version des jeweiligen Interpreters, während der IDNA-2003-Standard auf Unicode 3.2.0 basiert. Diese Diskrepanz führte zu falschen Domain-Encodings und damit zu potenziellen Sicherheitsproblemen. Der Artikel erklärt die Hintergründe, wie der Fehler entdeckt wurde und wie er durch neue Ausnahmen behoben wurde, sodass IDNA 2003 wieder spezifikationskonform arbeitet.
Der str.lower()-Aufruf in dieser Funktion ist eine Schwachstelle!
- echoangle
> Deshalb ist der Aufruf von str.lower() ein Unterschied zwischen Implementierung und Spezifikation und daher eine Sicherheitslücke:
Ich wünschte, es gäbe eine Erklärung, wie das eine Sicherheitslücke ist und nicht nur ein Bug, der fehlerhafte Daten erzeugt. Sicherheitslücke klingt für mich so, als gäbe es einen plausiblen Weg, aus dem Bug einen Exploit zu bauen, und ich sehe hier keinen, als jemand, der mit dem Thema nicht sehr vertraut ist.
- tialaramex
Diese Idiotie ist ein großer Teil des Grundes, warum es so wichtig war, Python-Leute, die an TLS-Implementierungen arbeiten, dazu zu bringen, zu verstehen, dass der definierte Mechanismus für SANs (nein, das "alternative" in Subject Alternative Name bedeutet nicht im Sinne von mehr als einem, X.509 stammt ursprünglich aus dem X.500-System und das Internet hat X.509 zweckentfremdet, also sind dies alternative Namen aus dem Internet) besagt, dass dies DNS-Namen sind, die ausdrücklich nicht als eine Art von menschenlesbarem Text zu verstehen sind, und daher ist ihr "Dekodieren" in Unicode definitiv Unsinn, obwohl Python das unbedingt tun wollte und ich glaube, es früher getan hat oder zumindest vorgeschlagen hat.
Die Regel, wie SAN-DnsNames mit ähnlichen Namen aus dem DNS abgeglichen werden, ist sehr, sehr einfach, damit man es nicht vermasselt. Man behandelt einen einzelnen Wildcard (ASCII * Code 42 passt auf ein einzelnes DNS-Label) und darüber hinaus ist es buchstäblich Byte-Vergleich. Es ist egal, was diese Bytes bedeuten; entweder sind die Bytes alle identisch oder das ist kein Match und wir sind fertig.
- ummonk
> Die Lösung war, neue Ausnahmen zu schaffen, damit sich str.lower() so verhält, als würde es Unicode 3.2.0 nur für bestimmte Funktionen verwenden. Also gehen wir jedes Unicode-Codepoint durch und notieren, wann sich das Verhalten von str.lower() unterscheidet, wenn man die mit Python gelieferte Unicode-Version und Unicode 3.2.0 vergleicht.
Das klingt nach einer wirklich hackigen Lösung im Vergleich zur Implementierung eines separaten eingefrorenen Unicode-3.2.0-lower.
- jooon
Erinnert mich an einen alten Sicherheitsvorfall bei Spotify https://engineering.atspotify.com/2013/06/creative-usernames
- ike_sh
Bin darauf mal mit dem Kelvin-Zeichen gestoßen. Hat peinlich lange gedauert, das aufzuspüren.