FreshPorts - VuXML

Alan Coopersmith reports:

Ilja van Sprundel, a security researcher with IOActive, has discovered a large number of issues in the way the X server code base handles requests from X clients, and has worked with X.Org's security team to analyze, confirm, and fix these issues.

The vulnerabilities could be exploited to cause the X server to access uninitialized memory or overwrite arbitrary memory in the X server process. This can cause a denial of service (e.g., an X server segmentation fault), or could be exploited to achieve arbitrary code execution.

The GLX extension to the X Window System allows an X client to send X protocol to the X server, to request that the X server perform OpenGL rendering on behalf of the X client. This is known as "GLX indirect rendering", as opposed to "GLX direct rendering" where the X client submits OpenGL rendering commands directly to the GPU, bypassing the X server and avoiding the X server code for GLX protocol handling.

Most GLX indirect rendering implementations share some common ancestry, dating back to "Sample Implementation" code from Silicon Graphics, Inc (SGI), which SGI originally commercially licensed to other Unix workstation and graphics vendors, and later released as open source, so those vulnerabilities may affect other licensees of SGI's code base beyond those running code from the X.Org Foundation or the XFree86 Project.

< 1.12.4_10,1

The X.org project reports:

Allocation for pixmap data in AllocatePixmap() does not initialize the memory in xserver, it leads to leak uninitialize heap memory to clients. When the X server runs with elevated privileges.

This flaw can lead to ASLR bypass, which when combined with other flaws (known/unknown) could lead to lead to privilege elevation in the client.

< 1.20.8_3,1

< 1.20.8_3,1

< 1.20.8_3,1

< 1.20.8_3,1

< 1.20.8_3,1

< 1.20.8_3,1

X.Org server security reports for release 1.20.11:

• Fix XChangeFeedbackControl() request underflow

.

< 1.20.11,1

< 1.20.11,1

le 1.20.0.877

Alan Coopersmith reports:

X.Org thanks Michal Srb of SuSE for finding these issues and bringing them to our attention, Julien Cristau of Debian for getting the fixes integrated, and Adam Jackson of Red Hat for publishing the release.

< 1.18.4_4,1

< 1.18.4_4,1

< 1.19.1_1,2

< 1.18.4_4,1

< 1.19.1_1,1

< 1.19.1_1

Peter Hutterer reports:

Olivier Fourdan from Red Hat has discovered a protocol handling issue in the way the X server code base handles the XkbSetGeometry request.

The issue stems from the server trusting the client to send valid string lengths in the request data. A malicious client with string lengths exceeding the request length can cause the server to copy adjacent memory data into the XKB structs. This data is then available to the client via the XkbGetGeometry request. The data length is at least up to 64k, it is possible to obtain more data by chaining strings, each string length is then determined by whatever happens to be in that 16-bit region of memory.

A similarly crafted request can likely cause the X server to crash.

< 1.14.7_2,1

ge 1.15.0,1 lt 1.16.4,1

Peter Hutterer reports:

Olivier Fourdan from Red Hat has discovered a protocol handling issue in the way the X server code base handles the XkbSetGeometry request.

The issue stems from the server trusting the client to send valid string lengths in the request data. A malicious client with string lengths exceeding the request length can cause the server to copy adjacent memory data into the XKB structs. This data is then available to the client via the XkbGetGeometry request. The data length is at least up to 64k, it is possible to obtain more data by chaining strings, each string length is then determined by whatever happens to be in that 16-bit region of memory.

A similarly crafted request can likely cause the X server to crash.

< 1.14.7_2,1

ge 1.15.0,1 lt 1.16.4,1

Daniel Stone of X.Org reports:

During the analysis of results from the Coverity code review of X.Org, we discovered a flaw in the server that allows local users to execute arbitrary code with root privileges, or cause a denial of service by overwriting files on the system, again with root privileges.

eq 6.9.0

Adam Jackson reports:

One regression fix since 1.19.4 (mea culpa), and fixes for CVEs 2017-12176 through 2017-12187.

< 1.18.4_5,1

< 1.18.4_5,1

< 1.19.1_2,2

< 1.18.4_5,1

< 1.19.1_2,1

< 1.19.1_2

The X.org project reports:

These issues can lead to privileges elevations for authorized clients on systems where the X server is running privileged.

Insufficient checks on the lengths of the XkbSetMap request can lead to out of bounds memory accesses in the X server.

Insufficient checks on input of the XkbSetDeviceInfo request can lead to a buffer overflow on the head in the X server.

< 1.20.9_1,1

< 1.20.9_1,1

< 1.20.9_1,1

< 1.20.9_1,1

< 1.20.9_2,1

< 1.20.9_1,1

Matthieu Herrb of X.Org reports:

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.

< 1.4.2,1

Matthieu Herrb reports:

It is possible to deduce if a file exists or not by exploiting the way that Xorg creates its lock files. This is caused by the fact that the X server is behaving differently if the lock file already exists as a symbolic link pointing to an existing or non-existing file.

It is possible for a non-root user to set the permissions for all users on any file or directory to 444, giving unwanted read access or causing denies of service (by removing execute permission). This is caused by a race between creating the lock file and setting its access modes.

< 1.7.7_3

Alan Coopersmith reports:

Pedro Ribeiro (pedrib at gmail.com) reported an issue to the X.Org security team in which an authenticated X client can cause an X server to use memory after it was freed, potentially leading to crash and/or memory corruption.

ge 1.7.0 lt 1.7.7_11

ge 1.12.0 lt 1.12.4_4

Allocating large pixmaps by a client can trigger an integer overflow in the X server, potentially leading to execution of arbitrary code with elevated (root) privileges.

< 4.5.0_2

< 6.8.2_5

gt 6.8.99 lt 6.8.99.12_1

xorg-server developers reports:

In the X.Org X server before 2017-06-19, a user authenticated to an X Session could crash or execute code in the context of the X Server by exploiting a stack overflow in the endianness conversion of X Events.

Uninitialized data in endianness conversion in the XEvent handling of the X.Org X Server before 2017-06-19 allowed authenticated malicious users to access potentially privileged data from the X server.

le 1.18.4_6,1

ge 1.19.0,1 le 1.19.3,1

Matthieu Herrb of X.Org reports:

Several vulnerabilities have been identified in server code of the X window system caused by lack of proper input validation on user controlled data in various parts of the software, causing various kinds of overflows.

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 succesfully, 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.

< 1.4_4,1

< 1.3.1_2,1

The X.org project reports:

All theses issuses can lead to local privileges elevation on systems where the X server is running privileged.

The handler for the XkbSetNames request does not validate the request length before accessing its contents.

An integer underflow exists in the handler for the XIChangeHierarchy request.

An integer underflow exist in the handler for the XkbSelectEvents request.

An integer underflow exist in the handler for the CreateRegister request of the X record extension.

< 1.20.8_4,1

< 1.20.8_4,1

< 1.20.8_4,1

< 1.20.8_4,1

< 1.20.8_4,1

< 1.20.8_4,1