Die glibc-Locale-Helpersprachdatei für Kasmiri India (devanagari Variante) bietet in neueren glibc-Versionen einen Exploiteinsprungpunkt für Remoteattacken. Durch Ausnutzung von UTF-16 (interne 4-Byte Zeichenkodierung) auf die UTF-8 (interne 2-Byte Kodierung) sind vornehmlich Systeme betroffen, die diese Localeunterstützung *NICHT* aktiviert haben.
Ausgenutzt wird der Eintrag in der
/etc/locale.gen. Der dort angetroffene Byte-Code "#ks_IN@devanagarii UTF-8" kann durch Auslesen der Bytefolgen eben aus jener Datei für die Eskalation ausgenutzt werden. In normalem UTF-8 Zugriff werden die ersten Zeichen "#ks_" normal als 2 UTF-8 Charcodes interpretiert, wobei das erste hochwertige Byte("Highbyte") eben das #-Zeichen repräsentiert. Dieses ist das normale Kommentarzeichen um den Eintrag zu deaktivieren bzw. als nicht aktiv zu haben.
Durch Zugriff über UTF-16 Kodierung wird das hochwertige Byte nun zu "#ks_", was im vom Sender/Remote codierten Anfragen in der Landessprache-Locale aber genau zu "su" umgesetzt wird. Da die glibc-Funktion "determine_locale" aufgerufen wird bei nicht lokal aktivierter Localeunterstützung (z.B. hierzulande bei de_DE), diese aber im (Root)Ring-0-Bereich der gblic angesiedelt ist, wird das UTF-16 aufgelöste "su" ohne weitere Überprüfung ausgeführt. Die Privilegieneskalation beschränkt sich auf den jeweiligen Prozess über dessen glibc-Zugriff obige Funktion aufgerufen würde. Die superuser(su)-Funktionalität ist also in diesem Kontext erstmal nur PID-beschränkt, nicht sofort systemweit gültig.
Beipiel für einen Ablauf:
Eine Remote-Anwendung("Attacker") sendet die dort über Tastatur eingebene Bytefolge "बोà¤". Das kann über Webserver/Webbrowser erfolgen. Um die Bytefolge nun einer Locale zuordnen zu können wird die glibc-Funktion "determine_locale" bemüht - aber nur wenn eben ks_IN@devanagari *NICHT* die aktive Locale ist.
Durch die Interpretation kann es nun zu o.a. Prozess-su-Eskalation kommen.
Lokal kann das z.B. überprüft und demonstriert werden indem obige Zeichen über die Tastatur!(Kopieren reicht nicht, da im Xorg-Puffer befindliche Zeichenfolgen UTF-8 kodiert sind) eingeben werden, z.B. im URL- oder Suchfunktionsfeld des Browsers.
Abhilfe:
Betroffen sind alle glibc Versionen >= 2.15 resp. Kernelversionen >= 2.6.26. Siehe auch:
http://www.archlinux.org/news/minimum-kernel-requirement-2632/
Mit einem beliebigen Editor sollte die /etc/locale.gen bearbeitet werden und die Zeilen:
#ks_IN UTF-8
#ks_IN@devanagari UTF-8
gelöscht werden. Es genügt auch die Zeilen so abzuändern:
# ks_IN UTF-8
# ks_IN@devanagari UTF-8
also ein zusätzliches Leerzeichen einzufügen um die fehlerhafte UTF-16-Umwandlung zu umgehen.
Diese Änderung sollte umgehend erfolgen. Ein Neustart ist nicht erforderlich. Um bestehende PIDs sauber zu beenden empfiehlt sich ein Neuanmelden der User.
Weitere Infos:
http://en.wikipedia.org/wiki/Devanagari
http://de.wikipedia.org/wiki/UTF-8
http://de.wikipedia.org/wiki/UTF-16