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

Re: [FYI] Hacking Insurance



On 2000-07-18 16:03:26 +0200, Florian Weimer wrote:

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

Ja, sicher.  Genau diese mailcap-Geschichten demonstrieren
aber auch, daß solche Schachteleien in der Praxis mehr als
häufig vorkommen.  Zur Zeit beherrschen wir sie
einigermaßen.  Mit UTF-8 könnte es spaßig werden, wenn
etwa die Shell anfängt, es zu interpretieren - mir fällt
da auf Anhieb einiges lustige ein, was man machen könnte.

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

Welche iconv-Implementierung?  Ich frage, weil mutt die
zugrundeliegende iconv-Implementierung munter mit Daten
unbekannter Herkunft bewirft.

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

Danke.  Ich möchte Domains auch weiterhin per Telephon
buchstabieren können.  Und nein, ich habe keine Lust, aus
einer Tabelle mit 16000 Einträgen den richtigen
herauszuklicken, nur um dann zu erfahren, daß ich leider
die japanische Variante des gleichen Schriftzeichens
erwischt habe.

Aber wir schweifen ab.

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

Mit anderen Worten: Der Code ist Mist. :->

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