** Please note that this issue is confidential at the moment and no information should be disclosed until it is made public ** from an upcoming X.org advisory: [...] Overview Several vulnerabilities have been found in the server-side code of some extensions in the X Window System. Improper validation of client-provided data can cause data corruption. Impact Exploiting these overflows will crash the X server or, under certain circumstances allow the execution of arbitray machine code. When the X server is running with root privileges (which is the case for the Xorg server and for most kdrive based servers), these vulnerabilities can thus also be used to raise privileges. All these vulnerabilities, to be exploited successfully, require either an already established connection to a running X server (and normally running X servers are only accepting authenticated connections), or a shell access with a valid user on the machine where the vulnerable server is installed. Affected versions All released X.Org versions are vulnerable to these problems. Other implementations derived from the X11 sample implementation are likely to be affected too. Vulnerabilities details * CVE-2008-2360 - RENDER Extension heap buffer overflow An integer overflow may occur in the computation of the size of the glyph to be allocated by the AllocateGlyph() function which will cause less memory to be allocated than expected, leading to later heap overflow. On systems where the X SIGSEGV handler includes a stack trace, more malloc()-type functions are called, which may lead to other exploitable issues. * CVE-2008-2361 - RENDER Extension crash Similarly, an integer overflow may occur in the computation of the size of the glyph to be allocated by the ProcRenderCreateCursor() function which will cause less memory to be allocated than expected, leading later to dereferencing un-mapped memory, causing a crash of the X server. * CVE-2008-2362 - RENDER Extension memory corruption Integer overflows can also occur in the code validating the parameters for the SProcRenderCreateLinearGradient, SProcRenderCreateRadialGradient and SProcRenderCreateConicalGradient functions, leading to memory corruption by swapping bytes outside of the intended request parameters. * CVE-2008-1379 - MIT-SHM arbitrary memory read An integer overflow in the validation of the parameters of the ShmPutImage() request makes it possible to trigger the copy of arbitrary server memory to a pixmap that can subsequently be read by the client, to read arbitrary parts of the X server memory space. * CVE-2008-1377 - RECORD and Security extensions memory corruption Lack of validation of the parameters of the SProcSecurityGenerateAuthorization SProcRecordCreateContext functions makes it possible for a specially crafted request to trigger the swapping of bytes outside the parameter of these requests, causing memory corruption. Workarounds The vulnerabilies described here can be avoided by disabling the corresponding extensions (at the cost of losing the functionalities offered by these extensions) in the /etc/X11/xorg.conf configuration file: Section "Extensions" Option "MIT-SHM" "disable" Option "RENDER" "disable" Option "SECURITY" "disable" EndSection Section "Module" Disable "record" EndSection [...]
Created attachment 155985 [details, diff] cve-2008-1377
Created attachment 155987 [details, diff] cve-2008-1379
Created attachment 155989 [details, diff] cve-2008-2360
Created attachment 155991 [details, diff] cve-2008-2361
Created attachment 155993 [details, diff] cve-2008-2362
Donnie, please prepare an updated ebuild and attach it here so we can have the arch security liaisons test it. Please do not commit anything to the tree yet as this is still confidential. and for the draft here is the credit section of the advisory: Credits These vulnerabilities were reported to iDefense by regenrecht.
Just for future reference, as X maintainer I am far too familiar with security vulnerabilities, so you don't need to walk me through the process. =) I also have access to the upstream security bugs, so I can follow things there. I'll see if I can get ebuilds up here later today.
(In reply to comment #7) > Just for future reference, as X maintainer I am far too familiar with security > vulnerabilities, so you don't need to walk me through the process. =) I also > have access to the upstream security bugs, so I can follow things there. While I don't doubt your full reliability when handling these kinds of issues, this is just what our template bugs look like. Also, there are other people reading these bugs (like arch liaisons and others in CC), and we just try to minimize errors by maximizing clarity. Thanks for speaking up, and sorry if this increases your effort in reading the bug.
Created attachment 156325 [details] xorg-server.tar.bz2 This is a tarball of the xorg-server directory. Unpack it from x11-base/. It contains xorg-server-1.3.0.0-r6.ebuild and xorg-server-1.4.1.ebuild. (Sorry I didn't get to this last night.)
thanks donnie Arch Security Liaisons, please test the attached ebuild and report it stable on this bug. CC'ing current Liaisons: alpha : yoswink amd64 : welp hppa : jer ppc : dertobi123 ppc64 : corsair release : pva sparc : fmccor x86 : opfer Quick handling of this would be appreciated, since this is rated A1 and supposed to be made public soon.
for ppc64: adding ranger to cc, as my internet connection is currently very limited...
x86 good to go for 1.3x series, I have no setup for 1.4, but it is ~arch anyway.
1.3 looks okay on alpha/ia64/sparc
These are now public and in the tree, and I've stabilized 1.3.0.0-r6 on the tested arches (x86/alpha/ia64/sparc). Other arches, please stabilize in the tree.
public via $URL removing arch liaisons and adding aliases please test and mark stable
really adding arch aliases now... Please test x11-base/xorg-server-1.3.0.0-r6 and mark stable if possible. As a local root vulnerability this should be dealt with quickly.
ppc64 done
ppc stable
amd64, would you like me to stabilize this for you? I'm running ~amd64 so I don't have a pure stable setup, though.
amd64 stable
Stable for HPPA.
Fixed in release snapshot.
This is GLSA 200806-07 thanks everyone