Bugzilla – Bug 1025084
VUL-0: xorg-x11-server: Weak Entropy Usage in xorg server in GenerateRandomData()
Last modified: 2018-10-04 06:46:54 UTC
Embargoed until CRD 2017-02-28. Received via private discussion on mailing list: 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); } 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.
SLE-11 and SLE-12 codestreams contain the exact same code as in the description. SLE-10 still uses a home grown srand()/rand() approach based on gettimeofday(). Related to bugs 1025046, 1025068 we might need a sensible GetRandomData() function in SLE-10, anyway. All codestreams can be considered affected. There is no final patch available yet. We will give an update once we have one.
bugbot adjusting priority
public now
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.
Three related patches in git now: 957e8db38f27932d353e86e9aa69cf16778b18f1 2855f759b1e7bf7f5e57cac36c1f0d0e5ac1a683 386fbbe410a1168b724136e54cf3bd37fb64ad4e
Information by Michal Srb: Fixed by 957e8db38f27932d353e86e9aa69cf16778b18f1 and 386fbbe410a1168b724136e54cf3bd37fb64ad4e
Already fixed in factory/TW (xorg-server-1.19.3).
This is an autogenerated message for OBS integration: This bug (1025084) was mentioned in https://build.opensuse.org/request/show/502781 Factory / xorg-x11-server
Submitted to sle11-sp3: SR#133961 Submitted to sle11-sp1: SR#133962 Submitted to sle10-sp3: SR#133963 Reassigning to security team ...
This is an autogenerated message for OBS integration: This bug (1025084) was mentioned in https://build.opensuse.org/request/show/502874 42.2 / xorg-x11-server
Finally looking closer into this one. :-( getentropy() needs glibc 2.25, which is currently only provided by factory. Leap 42.2/42.3 doesn't fullfill this requirement, let alone sle12, sle11, sle10. arc4random_buf() needs libbsd. Do we really want to add this requirement for the Leap products (42.2/42.3)? On sle12, sle11, sle10 we apparently ship no libbsd. Matthias? Marcus?
An update workflow for this issue was started. This issue was rated as moderate. Please submit fixed packages until 2017-06-26. When done, reassign the bug to security-team@suse.de. https://swamp.suse.de/webswamp/wf/63669
openSUSE-SU-2017:1610-1: An update that solves one vulnerability and has two fixes is now available. Category: security (moderate) Bug References: 1025029,1025035,1025084 CVE References: CVE-2017-2624 Sources used: openSUSE Leap 42.2 (src): xorg-x11-server-7.6_1.18.3-12.15.2
see the other bug for a suggested dropin
SUSE-SU-2017:1675-1: An update that solves one vulnerability and has 7 fixes is now available. Category: security (moderate) Bug References: 1019649,1021803,1025029,1025035,1025084,1025985,1032509,1039042 CVE References: CVE-2017-2624 Sources used: SUSE Linux Enterprise Software Development Kit 12-SP2 (src): xorg-x11-server-7.6_1.18.3-71.1 SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src): xorg-x11-server-7.6_1.18.3-71.1 SUSE Linux Enterprise Server 12-SP2 (src): xorg-x11-server-7.6_1.18.3-71.1 SUSE Linux Enterprise Desktop 12-SP2 (src): xorg-x11-server-7.6_1.18.3-71.1
Reassigning to myself. Needs to be improved in the same way as bsc#1025068 and bsc#1025046.
Hmm. Usage of getentropy() as fallback for arc4random() has not been added to GenerateAuthorization() of Xserver in git master yet, let alone replacements for getentropy().
Matthias, shouldn't we push the usage of getentropy() upstream first?
(In reply to sndirsch@suse.com from comment #22) > Matthias, shouldn't we push the usage of getentropy() upstream first? I didn't realize that upstream didn't fully fix this situation yet. The severity of this particular defect is not so high, because the random data is only silently broken in rare situations like when no more file descriptors are available. We can try to provide patches to upstream that utilize getentropy() at least. It seems their approach is to rely on libbsd being used for building.
(In reply to Matthias Gerstner from comment #23) > (In reply to sndirsch@suse.com from comment #22) > > Matthias, shouldn't we push the usage of getentropy() upstream first? > > I didn't realize that upstream didn't fully fix this situation yet. > > The severity of this particular defect is not so high, because the random > data > is only silently broken in rare situations like when no more file descriptors > are available. > > We can try to provide patches to upstream that utilize getentropy() at least. > > It seems their approach is to rely on libbsd being used for building. Seems so, yes. Do you plan to work aon patch for usage of getentropy()?
Created attachment 730759 [details] Proposal for pure getentropy() patch (without fallbacks to getrandom() / dev/urandom) Patch doesn't contain fallbacks to getrandom() / dev/urandom yet.
Matthias, could you make a review of my getentropy() patch or provide your version? ;-) I can add the fallbacks then as before (my task).
I can try to get a patch into upstream. Do you know the proper way to pass them patches? It seems their git interface doesn't support pull requests on https://cgit.freedesktop.org/xorg/xserver/. Your proposed patch in attachment 730759 [details] is okay in regards to using getentropy(). The implementation of emulate_getrandom_buf() should ideally look just like what we did for libICE in bnc#1025068. There's one difference here, though, because arc4random_buf does not allow for error handling (that's actually what they wrote about in this very security advisory, but didn't improve on it). I suggest if we can't successfully read random data from /dev/urandom, we simply call OsAbort(). Better safe than sorry, this situation should never occur during normal operation. Something along the lines of: #if HAVE_GENTROPY // try getentropy() #endif #if HAVE_GETRANDOM // try getrandom() #endif if( emulate_getrandom_buf(auth, len) != 0 ) { OsAbort(); } I can try to write up a complete patch for you this afternoon.
I see. I haven't implemented the fallbacks for getentropy() to getrandom() and /dev/urandom yet. I wanted to have this separated for now, since upstream may not be interested in this. Patches need to be sent to xorg-devel@lists.freedesktop.org I don't know, whether security related patches need to be sent to somewhere different instead. I'm not on such a X.Org list. Since Matthieu Herrb <matthieu@herrb.eu> submitted the arc4randrom_bug() patch it may make sense to contact him directly about the getentropy() addition. I would appreciate, if you could work on a patch. Feel free to base it on mine, if this makes sense to you.
xorg-security@lists.x.org would be their security list.
Okay I will work on a patch, hopefully finishing it today. I will also suggest a patch for upstream via the mailing list.
Thanks a lot, Matthias!
Created attachment 730907 [details] complete patch proposal with backward compatibility for getrandom So this is my suggested patch. I've checked it compiles against the SLE-12-SP2 codestream. Runtime tests are a bit more difficult for me, but the core code is the same as for libICE. I've added a configure check for the sys/syscall.h so we can try and go for the getrandom() system call if getentropy() is not there. I've reworked the /dev/urandom processing, because the one from upstream is without any error handling and also without O_CLOEXEC. The only part that might be overhead for upstream is the getrandom() part. But I think this is still important, because getentropy() was only recently added to glibc, and many Linux systems before that time have a getrandom() system call instead. When you're fine with this patch then I will propose it to upstream via the security mailing list Marcus posted.
Thanks. Looks good. Just the close() calls in GetUrandom() are missing again.
SUSE-SU-2017:1741-1: An update that solves one vulnerability and has four fixes is now available. Category: security (moderate) Bug References: 1019649,1025029,1025035,1025084,981044 CVE References: CVE-2017-2624 Sources used: SUSE Linux Enterprise Software Development Kit 11-SP4 (src): xorg-x11-server-7.4-27.118.1 SUSE Linux Enterprise Server 11-SP4 (src): xorg-x11-server-7.4-27.118.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): xorg-x11-server-7.4-27.118.1
Created attachment 731000 [details] u_Use-getentropy-if-arc4random_buf-is-not-available.patch Added missing close() calls ... patch applies against Leap 42.2.
(In reply to Stefan Dirsch from comment #33) > Thanks. Looks good. Just the close() calls in GetUrandom() are missing again. Good catch. That's what I get from careless copy/pasting ... Thanks for adjusting the patch. I will suggest the patch to upstream then.
(In reply to Matthias Gerstner from comment #36) > (In reply to Stefan Dirsch from comment #33) > > Thanks. Looks good. Just the close() calls in GetUrandom() are missing again. > > Good catch. That's what I get from careless copy/pasting ... > > Thanks for adjusting the patch. I will suggest the patch to upstream then. Thanks a lot for pushing this! :-)
This is an autogenerated message for OBS integration: This bug (1025084) was mentioned in https://build.opensuse.org/request/show/510258 Factory / xorg-x11-server
This is an autogenerated message for OBS integration: This bug (1025084) was mentioned in https://build.opensuse.org/request/show/510283 42.2+42.3 / xorg-x11-server https://build.opensuse.org/request/show/510318 Factory / xorg-x11-server
This is an autogenerated message for OBS integration: This bug (1025084) was mentioned in https://build.opensuse.org/request/show/510391 42.3 / xorg-x11-server
openSUSE-SU-2017:1885-1: An update that fixes two vulnerabilities is now available. Category: security (important) Bug References: 1025084,1035283 CVE References: CVE-2017-10971,CVE-2017-10972 Sources used: openSUSE Leap 42.2 (src): xorg-x11-server-7.6_1.18.3-12.20.1
Created attachment 732617 [details] sle11-sp3.patch I've branched sle11-sp3, but I'm facing some weird file conflicts in specfile and can't submit it. Here is the patch, so my changes won't get lost.
sle11-sp1: # iosc branch SUSE:SLE-11-SP1:Update xorg-x11-server BuildService API error: failed to branch: branch target package already exists: home:sndirsch:branches:SUSE:SLE-11-SP1:Update/xorg-x11-server sndirsch@shannon:/test> iosc co home:sndirsch:branches:SUSE:SLE-11-SP1:Update/xorg-x11-server Server returned an error: HTTP Error 404: package 'xorg-x11-server' does not exist package 'xorg-x11-server' does not exist WTF ?!? I can't branch it, since it exists? When trying to check it out, it does not exist?
I've submitrequested sle12-sp2 --> SR#135946
Do I need to fix this also for sle10? Seems on sle10 random numbers are generated differently there. /* A random number generator that is more unpredictable than that shipped with some systems. This code is taken from the C standard. */ static unsigned long int next = 1; static int xdm_rand(void) { next = next * 1103515245 + 12345; return (unsigned int)(next/65536) % 32768; } static void xdm_srand(unsigned int seed) { next = seed; } void GenerateRandomData (int len, char *buf) { #ifdef HAVE_ARC4RANDOM_BUF arc4random_buf(buf, len); #else static int seed; int value; int i; seed += GetTimeInMillis(); xdm_srand (seed); for (i = 0; i < len; i++) { value = xdm_rand (); buf[i] ^= (value & 0xff00) >> 8; } /* XXX add getrusage, popen("ps -ale") */ #endif }
(In reply to sndirsch@suse.com from comment #45) > Do I need to fix this also for sle10? Yes SLE10 is also still maintained here. > Seems on sle10 random numbers are generated differently there. GetTimeInMillis() is also based on gettimeofday(), so the basic bug still applies. The part of the patch reading from /dev/urandom should suffice here, because none of the other system calls are implemented on SLE-10. I think even O_CLOEXEC won't be available. Using the home grown xdm_rand() and xdm_srand() can probably more safely be replaced by standard rand() and srand() calls, glibc in SLE-10 should already implement a sensible RNG.
Thanks, Matthias. Adjusted the patch accordingly. arc4random_buf() is not available for generating cookies on sle10: - try to read directly from /dev/urandom first - fallback: replaced home grown xdm_rand() and xdm_srand() by rand() and srand() from glibc, which should be safer SR#135983
I'm facing problems with sle11-sp3 and sle11-sp1 (see comments #42,43). Maybe there are already submit requests open? Mabye even by myself?
(In reply to Stefan Dirsch from comment #49) > I'm facing problems with sle11-sp3 and sle11-sp1 (see comments #42,43). > Maybe there are already submit requests open? Mabye even by myself? Ok. Could resolve the conflict in sle11-sp3 at least. :-)
sle11-sp3: SR#135990
Ok. For some reason I now can branch and checkout sle11-sp1 (again).
sle11-sp1: SR#135992
Reassigning to security team for doing the maintenance process.
openSUSE-SU-2017:1934-1: An update that contains security fixes can now be installed. Category: security (moderate) Bug References: 1025084,1047154 CVE References: Sources used: openSUSE Leap 42.3 (src): xorg-x11-server-7.6_1.18.3-22.1
An update workflow for this issue was started. This issue was rated as moderate. Please submit fixed packages until 2017-08-08. When done, reassign the bug to security-team@suse.de. https://swamp.suse.de/webswamp/wf/63797
SUSE-RU-2017:2322-1: An update that has two recommended fixes can now be installed. Category: recommended (low) Bug References: 1025084,1047154 CVE References: Sources used: SUSE Linux Enterprise Software Development Kit 12-SP3 (src): xorg-x11-server-7.6_1.18.3-76.6.1 SUSE Linux Enterprise Software Development Kit 12-SP2 (src): xorg-x11-server-7.6_1.18.3-76.6.1 SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src): xorg-x11-server-7.6_1.18.3-76.6.1 SUSE Linux Enterprise Server 12-SP3 (src): xorg-x11-server-7.6_1.18.3-76.6.1 SUSE Linux Enterprise Server 12-SP2 (src): xorg-x11-server-7.6_1.18.3-76.6.1 SUSE Linux Enterprise Desktop 12-SP3 (src): xorg-x11-server-7.6_1.18.3-76.6.1 SUSE Linux Enterprise Desktop 12-SP2 (src): xorg-x11-server-7.6_1.18.3-76.6.1
SUSE-SU-2017:3025-1: An update that fixes 13 vulnerabilities is now available. Category: security (moderate) Bug References: 1025084,1051150,1063034,1063035,1063037,1063038,1063039,1063040,1063041 CVE References: CVE-2017-12176,CVE-2017-12177,CVE-2017-12178,CVE-2017-12179,CVE-2017-12180,CVE-2017-12181,CVE-2017-12182,CVE-2017-12183,CVE-2017-12184,CVE-2017-12185,CVE-2017-12186,CVE-2017-12187,CVE-2017-13723 Sources used: SUSE Linux Enterprise Software Development Kit 11-SP4 (src): xorg-x11-server-7.4-27.122.16.1 SUSE Linux Enterprise Server 11-SP4 (src): xorg-x11-server-7.4-27.122.16.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): xorg-x11-server-7.4-27.122.16.1
released