Bugtraq: Advisory X41-2017-001: Multiple Vulnerabilities in X.org

X41 D-Sec GmbH Security Advisory: X41-2017-001

Multiple Vulnerabilities in X.org

=================================

Overview

——–

Vendor: X.org/Freedesktop.org

Vendor URL: https://www.x.org/wiki/

Credit: X41 D-Sec GmbH, Eric Sesterhenn

Advisory-URL: https://www.x41-dsec.de/lab/advisories/x41-2017-001-xorg/

Status: Public

Timing attack against MIT Cookie

================================

Vulnerability Type: Other

Affected Products: Xorg Server

Attack Type: Local

Impact: Escalation of Privileges

Severity Rating: low

Confirmed Affected Version: 1.19.0 and lower

Confirmed Patched Version: –

Vector: local

CVE: CVE-2017-2624

CVSS Score: 5.9

CVSS Vector: CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N

Summary and Impact

——————

The xorg-server uses memcmp() to check the received MIT cookie against a

series of valid cookies. If the cookie is correct, it is allowed to

attach to the Xorg session:

XID

MitCheckCookie(unsigned short data_length,

const char *data, ClientPtr client, const char **reason)

{

struct auth *auth;

for (auth = mit_auth; auth; auth = auth->next) {

if (data_length == auth->len &&

memcmp(data, auth->data, (int) data_length) == 0)

return auth->id;

}

*reason = “Invalid MIT-MAGIC-COOKIE-1 key”;

return (XID) -1;

}

Since most memcmp() implementations return after an invalid byte is

seen, this causes a time difference between a valid and invalid byte,

which in theory could allow an efficient brute force attack[1].

Analysis

——–

X41 was not able to measure a significant difference using the optimised

memcmp() version of a standard Linux system, but for a naive

implementation consisting of a loop comparing the bytes. Since timing

attacks against memcmp() have been successful in the past [2] and fixed

elsewhere [3][4] X41 would consider this an issue. If this would be

exploited, it would allow a local attacker to run code in the Xorg

session of another user.

In order to prevent this, MIT-COOKIES should be removed or a memcmp()

similar to timingsafe_memcmp()[5] used. Other projects (e.g. openssl)

use timing safe memcmp() implementations to compare cookies retrieved

via the network[6].

Workaround

———-

None

References

———-

[1]

https://cryptocoding.net/index.php/Coding_rules#Compare_secret_strings_i

n_constant_time

[2]

http://de.slideshare.net/cisoplatform7/defcon-22paulmcmillanattackingthe

iotusingtimingattac

[3] http://seb.dbzteam.org/crypto/python-oauth-timing-hmac.pdf

[4] https://bugs.ruby-lang.org/issues/10098

[5]

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/timingsafe_

memcmp.c

[6] https://github.com/openssl/openssl/blob/master/ssl/t1_lib.c#L1249

Potential Use after Free in Xorg Server

=======================================

Vulnerability Type: Other

Affected Products: Xorg Server

Attack Type: Local

Impact: –

Severity Rating: none

Confirmed Affected Version: 1.19.0 and lower

Confirmed Patched Version:

Vector: local

CVE: –

CVSS Score: –

CVSS Vector: –

Summary and Impact

——————

In XDM is a (currently non security) issue, regarding a potential use

after free.

The ToID() function in os/auth.c is not used anywhere, just defined in

the struct and filled by the protocols, but there are no users.

AuthToIDFunc ToID; /* convert cookie to ID */

X41 noticed that, XdmToID() frees the cookie argument in case it can

resolve the ID or on failure, but not if it can’t allocate memory for plain:

XdmToID(unsigned short cookie_length, char *cookie)

{

XdmAuthorizationPtr auth;

XdmClientAuthPtr client;

unsigned char *plain;

plain = malloc(cookie_length);

if (!plain)

return (XID) -1;

for (auth = xdmAuth; auth; auth = auth->next) {

XdmcpUnwrap((unsigned char *) cookie, (unsigned char *) &auth->key,

plain, cookie_length);

if ((client =

XdmAuthorizationValidate(plain, cookie_length, &auth->rho,

NULL,

NULL)) != NULL) {

free(client);

free(cookie);

free(plain);

return auth->id;

}

}

free(cookie);

free(plain);

return (XID) -1;

}

The same return value is given, whether no memory could be allocated or

it just failed to lookup the ID, so the caller cannot distinguish

whether this memory is freed or not, which might lead to double-free or

memory leaks. The other ToID functions do not free this parameter.

Weak entropy usage for session keys in libxdm

=============================================

Vulnerability Type: Other

Affected Products: libXdmcp

Attack Type: Local

Impact: Escalation of Privileges

Severity Rating: medium

Confirmed Affected Version: 1.1.2 and lower

Confirmed Patched Version:

Vector: local

CVE: CVE-2017-2625

CVSS Score: 7.1

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Summary and Impact

——————

To further explore the auth mechanism libXdmcp-1.1.2 was checked as well.

XDM uses weak entropy to generate the session keys on non BSD systems:

void

XdmcpGenerateKey (XdmAuthKeyPtr key)

{

#ifndef HAVE_ARC4RANDOM_BUF

long lowbits, highbits;

srandom ((int)getpid() ^ time((Time_t *)0));

lowbits = random ();

highbits = random ();

getbits (lowbits, key->data);

getbits (highbits, key->data + 4);

#else

arc4random_buf(key->data, 8);

#endif

}

On multi user systems it might possible to check the PID of the process

and how long it is running to get an estimate of these values, which

could allow an attacker to attach to the session of a different user.

Several checked Linux distributions (debian testing, archlinux and

Ubuntu) did not link against libbsd at the time this was found.

Workaround

———-

Compile against libbsd

Weak Entropy Usage in Session Keys in libICE

============================================

Vulnerability Type: Other

Affected Products: libICE

Attack Type: Local

Impact: Escalation of Privileges

Severity Rating: medium

Confirmed Affected Version: 1.0.9 and lower

Confirmed Patched Version:

Vector: local

CVE: CVE-2017-2626

CVSS Score: 7.1

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Summary and Impact

——————

libICE depends on arc4random() as well to generate the session cookies,

thereby falling back to the same weak mechanism as libXdmcp:

IceGenerateMagicCookie (

int len

)

{

char *auth;

#ifndef HAVE_ARC4RANDOM_BUF

long ldata[2];

int seed;

int value;

int i;

#endif

if ((auth = malloc (len + 1)) == NULL)

return (NULL);

#ifdef HAVE_ARC4RANDOM_BUF

arc4random_buf(auth, len);

#else

#ifdef ITIMER_REAL

{

struct timeval now;

X_GETTIMEOFDAY (&now);

ldata[0] = now.tv_sec;

ldata[1] = now.tv_usec;

}

#else

{

long time ();

ldata[0] = time ((long *) 0);

ldata[1] = getpid ();

}

#endif

seed = (ldata[0]) + (ldata[1] << 16);

srand (seed);

for (i = 0; i < len; i++)

{

value = rand ();

auth[i] = value & 0xff;

}

#endif

auth[len] = ‘\0’;

return (auth);

}

For this issue a PoC is available which takes 2-3 seconds to retrieve

the key:

https://www.x41-dsec.de/lab/sources/icetest.c

Workaround

———-

Compile against libbsd

Weak Entropy Usage in xorg server

=================================

Vulnerability Type: Other

Affected Products: Xorg Server

Attack Type: Local

Impact: Unknown

Severity Rating: unclear

Confirmed Affected Version: 1.19.0 and lower

Confirmed Patched Version:

Vector: local

CVE: –

CVSS Score: –

CVSS Vector: –

Summary and Impact

——————

When looking at other places that use entropy, X41 also noticed

os/auth.c and hw/xwin/winauth.c providing GenerateRandomData()

void

GenerateRandomData(int len, char *buf)

{

int fd;

fd = open(“/dev/urandom”, O_RDONLY);

read(fd, buf, len);

close(fd);

}

When the call to open or read fails, the contents of buf might be

undefined. This should be handled more gracefully, it might fail in

chrooted environments (unlikely) or when file descriptors are exhausted.

Newer Linux Kernels provide getrandom() to protect against this and

OpenBSD provides getentropy().

This security impact of these functions has not been further inspected.

About X41 D-Sec GmbH

——————–

X41 D-Sec GmbH is an expert provider for application security services.

Having extensive industry experience and expertise in the area of

information security, a strong core security team of world class

security experts enables X41 to perform premium security services.

Fields of expertise in the area of application security are security

centric code reviews, binary reverse engineering and vulnerability

discovery. Custom research and a IT security consulting and support

services are core competencies of X41.

Timeline

——–

2017-01-17 to Report to xorg-security (at) lists.x (dot) org [email concealed]

01-23

2017-02-10 CVE Request at secalert (at) redhat (dot) com [email concealed]

2017-02-13 CVE IDs assigned

2017-02-16 Information of distros (at) vs.openwall (dot) org [email concealed]

2017-02-20 Patch for CVE-2017-2624 provided by Matthieu Herrb

2017-02-28 Advisory release

X41 D-SEC GmbH, Dennewartstr. 25-27, D-52068 Aachen

T: +49 241 9809418-0, Fax: -9

Unternehmenssitz: Aachen, Amtsgericht Aachen: HRB19989

Geschäftsführer: Markus Vervier

—–BEGIN PGP SIGNATURE—–

iQIzBAEBCAAdFiEEpwxVTgxAIcUvTugIo5Klpg50CxAFAli1fWMACgkQo5Klpg50

CxCI3BAAsavJ3UrGjjffZG1wjg0byircaYp/lqcyQApyFWXIYw29cA8YSVhw/RhV

+IebKitg+29h00H45vuBpr1pj/GzJyz5u1j6GL683HNnwwQB+D7Hk4uZHJ1ZSgyX

fKoIqYTdVgzSAr9M2uu9yHBdDAsm07uH6v3syxknApIn99qSMluNajxVECm6OqdH

7TsfDT+/FJAFEuKIADKU0tPofwHsgk33HxvHuFT1TgubmZNpUhvdWgx2sMnabL0G

sNS8siBFDbJh9I3LIzVxWlaJLe3FdqH1MnaaTL/ltJl31c1bo5L3JW2d/hLtc0Iu

VGfbUGDcinjYpxmrr7qf0yuF+S6ECkqN6HEVc2AbFA8PFZe3GD970rntUkd3HFAq

kuAPA6wYYFhy3JUg2TGESZri8X+CmC48iKOndnkjd+9SFtlyN3X/9U30+Neolk5P

8sBJLNX0xHi8N7u8upSXYFoQvjzqhEYlj2agSz0tkfK0uyDl1BhwbzbDYWUzbHxB

EPIKESYU+X2k+UeArP7IE4pRXELPB/xadxFmFwKzsQ35Vi2lZerOdBFgebJFCwLr

Fh3M2eeZNCuF6AMWwL4Qh98Rp2y0dqpC0lUIDhYHI9D5usa77C36DCBCV+HLaOIB

swg4Ew964uMW+UEI2rR4y2ASVa57x0DuFbEvY+B25uhQmrtzQl0=

=2Q19

—–END PGP SIGNATURE—–

[ reply ]

Source: SecurityFocus Vulnerabilities @ February 28, 2017 at 09:07AM

0
Share