A héten minden nagyobb hírverés nélkül megjelent az Xfree86 4.2.1. Tulajdonképpen azért nem számoltak be róla nagy hírek közepette, mert semmi új dolgot nem hozott az XFree86 4.2.0-hoz képest. A release egy hibajavítás tulajdonképpen, amely a nemrégiben bejelentett Xlib biztonsági hibát javítja. Ezt a hibát elméletileg ki lehetne használni, bár egyelőre én nem tudok ismert exploitról. A hiba több hete ismert fejlesztői körökben, de eddig nagy titokban tartották. A hiba lényege, hogy moduláris i18n támogatást adtak a XFree86-hoz, és a 4.0.1 után megjelent kiadásokban elméletileg lehetővé válik, hogy nem kívánatos kódot lehessen feltölteni (és futtatni) a privilegizált klienseken.
Branden kitett egy állásfoglalást a saját XFree86 oldalára, az X Strike Force-ra, amelyben kijelenti, hogy a Debianban levő, és eddig megjelent X csomagok nem sebezhetők az Xlib buggal kapcsolatban. Nyilvánvalóan, Branden pre-release XFree86 4.2 csomagjainak felhasználói sebezhetők az elméletileg működő buggal, de Branden reméli, hogy minél előbb elkészülnek a 4.2.1-es csomagok.
Branden állásfoglalása:[5 September] There is a security flaw in the version of Xlib shipped with XFree86 4.2.0. The modularized i18n support that was added to XFree86 after version 4.1.0 was released made it possible to load (and execute) arbitrary code in priviledged clients. Before you panic, here are a few facts.
No released version of Debian is vulnerable to this exploit.
Not even Debian unstable is vulnerable, since XFree86 4.2.0 hasn't been released to it yet.
Anyone using my 4.2.0 pre-release xlibs package is potentially vulnerable.
If you are alarmed by this, downgrade xlibs to 4.1.0-17. You'll need to downgrade any packages that depend on version 4.2.0 or greater of xlibs as well. This should consist only of other packages built from the xfree86 source package, such as xbase-clients (and local or unofficial packages; nothing in Debian unstable should be declaring versioned dependencies on XFree86 4.2.0 yet).
The real-world (as opposed to theoretical) impact of this vulnerability hasn't been established yet. Unix experts have long known that setuid and setgid X clients are potentially dangerous, and should have their privileges removed where possible, and constrained as tightly as possible otherwise.
Debian doesn't ship any setuid root X clients to my knowledge.
Check the permissions and ownership on your screen locker programs, such as xlock and xscreensaver.
As long as any privileged X clients aren't coded to exploit this vulnerability, there is no problem. setuid and setgid X clients should be carefully scruntinzed anyway. In Debian, X terminal emulators (such as XTerm) are setgid utmp instead of setuid root, which greatly limits the impact of exploits of X terminal emulators.
This doesn't really disrupt my release plans at all. The next pre-release will be 4.2.1-0pre1v1 instead of 4.2.0-0pre1v5.
I knew about this vulnerability a couple of weeks ago, but was sworn to secrecy.