** 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:
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.
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.
All released X.Org versions are vulnerable to these problems. Other
implementations derived from the X11 sample implementation are likely
to be affected too.
* 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
On systems where the X SIGSEGV handler includes a stack trace, more
malloc()-type functions are called, which may lead to other
* 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
* 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
functions makes it possible for a specially crafted request to trigger
the swapping of bytes outside the parameter of these requests, causing
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
Option "MIT-SHM" "disable"
Option "RENDER" "disable"
Option "SECURITY" "disable"
Created attachment 155985 [details, diff]
Created attachment 155987 [details, diff]
Created attachment 155989 [details, diff]
Created attachment 155991 [details, diff]
Created attachment 155993 [details, diff]
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:
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]
This is a tarball of the xorg-server directory. Unpack it from x11-base/. It contains xorg-server-188.8.131.52-r6.ebuild and xorg-server-1.4.1.ebuild. (Sorry I didn't get to this last night.)
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 184.108.40.206-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-220.127.116.11-r6 and mark stable if possible.
As a local root vulnerability this should be dealt with quickly.
amd64, would you like me to stabilize this for you? I'm running ~amd64 so I don't have a pure stable setup, though.
Stable for HPPA.
Fixed in release snapshot.
This is GLSA 200806-07