Bugzilla Bug 225419

** 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 an attachment (id=155985) [edit]
cve-2008-1377

Created an attachment (id=155987) [edit]
cve-2008-1379

Created an attachment (id=155989) [edit]
cve-2008-2360

Created an attachment (id=155991) [edit]
cve-2008-2361

Created an attachment (id=155993) [edit]
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 an attachment (id=156325) [edit]
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