[PATCH libXdmcp] Use getrandom() syscall if available

Mark Kettenis mark.kettenis at xs4all.nl
Mon Apr 3 19:17:53 UTC 2017


> From: Benjamin Tissoires <benjamin.tissoires at gmail.com>
> Date: Mon, 3 Apr 2017 17:52:32 +0200
> 
> On Mon, Apr 3, 2017 at 4:02 PM, Alan Coopersmith
> <alan.coopersmith at oracle.com> wrote:
> > On 04/ 3/17 05:52 AM, Benjamin Tissoires wrote:
> >>
> >> This allows to fix CVE-2017-2625 on Linux platforms without pulling in
> >> libbsd.
> >> The syscall getrandom is available since kernel v3.17. The code first
> >> tries to use the syscall on a supported kernel. If the syscall fails,
> >> it falls back to the current (vulnerable) code.
> >> We do not implement the glibc getrandom() call given that it's only
> >> available in glibc 2.25, and the #if dance is already messy here.
> >>
> >> Signed-off-by: Benjamin Tissoires <benjamin.tissoires at gmail.com>
> >
> >
> > This is dangerous - Solaris <sys/syscall.h> defines SYS_getrandom, but
> > I don't know if our syscall arguments/semantics are the same, and we
> > only support applications calling the libc getrandom() function, not the
> > raw syscall.

Doesn't Solaris have a proper arc4random_buf(3) in libc now though?

> I see. In that case, would it help to use unconditionally the libc
> getrandom() function, and in case it's not there, provide a stub for
> it through the syscall or other emulation layer?
> 
> Matthieu, I am not 100% sure, but do you have the getrandom() libc
> call in BSD, and would it be OK to use it instead of arc4random_buf()
> when available?

OpenBSD does not have a getrandom(3) function in libc.  The OpenBSD
postion is that the arc4random(3) family of functions is always the
preferred way to get proper random numbers as all the other interfaces
have nasty corner cases that people shouldn't have to deal with.  In
your case for example, getrandom(2) may block and therefore could
return EINTR, a case which your patch doesn't handle.

So I'd argue that from a Linux distro point of view, making sure that
a proper arc4random_buf(3) implementation is available would be the
best way to fix this vulnerability.  Either by improving the version
provided in libbsd (feel free to take the code from libressl) or by
lobbying for its inclusion in glibc.  Adding more #ifdef spaghetti
everywhere isn't going to help.

Cheers,

Mark

> >> diff --git a/configure.ac b/configure.ac
> >> index 2288502..d0d4d05 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -63,6 +63,9 @@ case $host_os in
> >>          ;;
> >>  esac
> >>
> >> +# Checks for syscalls
> >> +AC_CHECK_DECLS([SYS_getrandom], [], [], [[#include <sys/syscall.h>]])
> >> +
> >>  # Checks for library functions.
> >>  AC_CHECK_LIB([bsd], [arc4random_buf])
> >>  AC_CHECK_FUNCS([srand48 lrand48 arc4random_buf])
> >>
> >
> > Could you move that check up into the case $host_os section above it
> > under a new case for *linux* perhaps?
> 
> Sure.
> 
> Cheers,
> Benjamin
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
> 


More information about the xorg-devel mailing list