Have something to say?

Ready to be published? LXer is read by around 350,000 individuals each month, and is an excellent place for you to publish your ideas, thoughts, reviews, complaints, etc. Do you have something to say to the Linux community?

According the security advisory issued by X.org on May 2nd, Bart Massey reported a buffer overflow vulnerability in the Xrender extension of X.Org's X Server. Several versions are affected including X.org X11R6, 6.9, X.org X11R6, 6.8.1, X.org X11R6, 6.8, and X.org X11R6, 6.7.0. Additionally, the problem also affects all individual releases of the modular xorg-xserver package.

The announcement attributed the problem to a typo: the ampersand (&) operator was used instead of the asterisk (*) operator in an expression. According to Bart Massey, who originally discovered the flaw, when running rendertest from XCB xcb/xcb-demo, the server crashes part way through the process. The programming error causes the code to incorrectly calculate the size of the memory allocations in the XRenderCompositeTriStrip and XRendercompositeTriFan requests. Consequently, the buffer may be not large enough to the store the parameters of a request.

The problem manifests itself in two ways, depending on the platform. When the ALLOCATE_LOCAL() macro is using alloca(), the condition causes a stack overflow vulnerability. On all other platforms, the condition causes a heap overflow vulnerability.

When an X Server client uses the X render extension, it sends requests that cause a buffer overflow in the server side of the extension. A malicious local user could exploit the problem to execute malicious code inside the X Server. Since the X Server usually runs with root privileges, the attacker could escalate privileges and gain access to root.

Earlier this year, researchers also found another security vulnerability in the X.Org server. That problem affected version (xorg-server) 1.0.0 and later, as well as versions X11R6.9.0 and X11R7.0. According to the original security advisory issued on March 20, X.Org's security team discovered the problem while using Coverity's Prevent code audit tool during a code review.

The earlier problem was the result of a flaw in the way the server parses maliciously crafted arguments via the -logfile and -modulepath command line options. Under normal circumstances, the server checks that only users with root can pass the options -modulepath (where modules providing server functionality load) and -logfile (which determines the location of the logfile). To change the locations of the -modulepath and the -logfile options, users must hold the proper access privileges.

However, upon testing of the effective UID and the real UID in X.org, researchers found that the address of the geteuid function is tested, rather than the function itself. Consequently, since the address of geteuid() is always non-zero, a local user without the proper credentials can load modules from any location on the filesystem. Those modules could load with the privileges of the root user or overwrite critical system files with the server log.

A malicious local user could exploit the problem by creating special arguments and passing them to the -logile and -modulepath command line options. Consequently, the user could bypass security controls to load arbitrary modules, overwrite system files, or execute malicious commands with the privileges of the root user.

If you run X.org's X Server on affected distributions, please be sure to check the advisories and patch your systems.