Vulnerabilities in xorg (server, libXdmcp, libICE) were recently reported by Eric Sesterhenn of X41, and assigned CVEs by Red Hat. > CVE-2017-2624 xorg-x11-server: timing attack against MIT Cookie mitauth.c uses memcmp() to check the validity of MIT cookies, exposing a possible timing attack on some platforms. https://bugzilla.redhat.com/show_bug.cgi?id=1424984 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856398 https://bugzilla.novell.com/show_bug.cgi?id=1025029 > CVE-2017-2625 libXdmcp: weak entropy usage for session keys In the absence of arc4random(), xdmcp session keys are generated based on getpid() and time(), which may allow a local attacker to brute-force the key. https://bugzilla.redhat.com/show_bug.cgi?id=1424987 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856399 https://bugzilla.novell.com/show_bug.cgi?id=1025046 > CVE-2017-2626 libICE: weak entropy usage in session keys In the absence of arc4random(), the Inter-Client Exchange session keys are generated based on gettimeofday(), which may allow a local attacker to brute-force the key. https://bugzilla.redhat.com/show_bug.cgi?id=1424992 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856400 https://bugzilla.novell.com/show_bug.cgi?id=1025068 The first issue is mitigated with recent glibc's memcmp, particularly with -D_FORTIFY_SOURCE=2, and the other two by providing an implementation of arc4random at compile time, such as libbsd.
Splitting into multiple bugs. From $URL: 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 and fixed elsewhere 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() used. Other projects (e.g. openssl) use timing safe memcmp() implementations to compare cookies retrieved via the network.
xorg-server-1.19.2 will be released today with the fix. We should stabilize it. I'm not sure what I would like to do for older xorg-server versions.
Upstream's changelog: https://lists.x.org/archives/xorg-announce/2017-March/002779.html Ebuild already in repository. @ Maintainer(s): Can we already start stabilization?
Stabilization will be handled in bug 611056.
I have removed ati-drivers from the tree (bug 582406), which has now allowed me to remove xorg-server-1.17. Removal of xorg-server-1.18 is blocked on bug 611712. xorg-server 1.12 and 1.15 are only in the tree to support ancient versions of nvidia-drivers, which are themselves masked because of unfixed security vulnerabilities. I think it's appropriate to mask them for the same reason.
Added to an existing GLSA request.
This issue was resolved and addressed in GLSA 201704-03 at https://security.gentoo.org/glsa/201704-03 by GLSA coordinator Kristian Fiskerstrand (K_F).
This was never cleaned upped before closing Can we please revisit the cleanup stage of this and drop <x11-base/xorg-server-1.19.2
(In reply to Yury German from comment #8) > This was never cleaned upped before closing > Can we please revisit the cleanup stage of this and drop > <x11-base/xorg-server-1.19.2 Still waiting on bug 614308...
1.18 is now gone from the tree, and versions <1.19.2 are now package.mask'd. Please proceed.
(In reply to Matt Turner from comment #10) > 1.18 is now gone from the tree, and versions <1.19.2 are now package.mask'd. > Please proceed. Still have to hold, but thank you for masking. Once dropped we can close.
This issue was resolved and addressed in GLSA 201710-30 at https://security.gentoo.org/glsa/201710-30 by GLSA coordinator Aaron Bauman (b-man).