[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FYI] Hacking Insurance



Thomas Roessler <roessler@does-not-exist.org> writes:

> > Sicherlich können Probleme entstehen, wenn man unsauber
> > arbeitet und z.B. RFC 2279 in den Wind schlägt, aber
> > dann wird man schon an korrekten ASCII-Parsern
> > scheitern.
> 
> ... was auch viele tun, nicht wahr?

Meistens scheitern sie an der Programmiersprache C. ;-)

> Tatsache ist, daß Code, der _eigentlich_ UTF-8 als
> irgendeine Obermenge von US-ASCII betrachten könnte, durch
> die faktische Mehrdeutigkeit der Codierung zusätzlich die
> Aufgabe aufgebrummt bekommt, die Eingabedaten auf
> ungültige Sequenzen zu überprüfen, da man ja nie weiß, ob
> nicht irgendein darüberliegender Decoder etwas zu "liberal
> in what it accepts" ist und diese ungültigen Sequenzen
> schluckt.  Das fügt unter Umständen eine ganze Menge an
> Komplexität zum Code hinzu - und damit Gelegenheiten,
> Fehler zu machen, die zu Sicherheitslücken führen.

Korrekt. Das heißt, man müßte die Menge der UTF-8-Dekoder klein halten
und sie genau unter die Lupe nehmen. Der von Python war in der Tat
reichlich buggy (was tatsächlich an der Programmiersprache C lag,
nicht am Algorithmus, ehrlich!), als nächstes werde ich mir Tcl und
Perl anschauen.  Java ist mir ein zu weites Feld (und zu proprietär,
größtenteils).

Andererseits: UTF-8 mit liberalem Decoder kann nur dann zu Problemen
führen, falls man Parser schachtelt (d.h. erst Parser, dann Decoder,
dann wieder Parser). So etwas wird auch ohne den Decoder selten sicher
sein (siehe die mailcap-Geschichten).

(Das ganze hat natürlich nur bedingt etwas mit der Sicherheit von
Unicode zu tun, da UTF-8 nur ein kleines Teilgebiet davon ist. Ada
unterstützt Unicode und hat keine Sicherheitsprobleme damit. UTF-8 ist
AFAIK auch jünger als Ada95.)

> Selbst wide-character- bzw. iconv-Implementierungen in
> Sytembibliotheken sind häufig schlicht reif für den Müll.

Das stimmt leider, nicht nur von einem Sicherheitsstandpunkt aus.

> (Und können, ganz nebenbei, gleich wieder zu neuen buffer
> overflows führen, wenn etwa die erwartete Länge der
> decodierten/codierten Daten falsch zurückgegeben wird.)

Ich habe iconv()-Exploit im Hinterkopf, der kein buffer overflow ist.
(Die meisten iconv()-Implementationen sind vermutlich nicht für
suid-Binaries ausgelegt.)

> Und was schließen wir daraus?  Von us-ascii verschiedene
> Zeichensätze haben in Kontrollinformationen nichts zu
> suchen, weil sie zu Interoperabilitätsalbträumen,
> Sicherheitslöchern und Bugs aller Art führen.

Korrekt. Schreibst Du eine Antwort an Schneier, oder soll ich das tun?

> (Ich freue mich schon auf die erste Internet-Domain, die
> ich nur mit einer chinesischen Tastatur eintippen kann.)

Nimm GNU Emacs. Dann brauchst Du keine chinesische Tastatur. ;-)

PS: Eigentlich wollte ich hier ein kleines chinesisches Grußwort
einflechten, aber leider hat sich GNU Emacs als fehlerhaft
erwiesen. *sigh* (Ein prinzipielles Problem von GNU Emacs ist,
daß bei eingeschalteter MULE-Unterstützung bestimmte Zeichen mit
gesetztem achten Bit für inband signalling eingesetzt werden. Bei
UTF-8-Kodierung treten diese Zeichen bevorzugt auf, weshalb die
quoted-printable-Codierung manchmal etwas eigenwillige Ergebnisse
liefert.)