Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CVE-2019-5736]: fix only suit for kernel > 3.11 ? #1979

Closed
Ace-Tang opened this issue Feb 12, 2019 · 8 comments · Fixed by #1984
Closed

[CVE-2019-5736]: fix only suit for kernel > 3.11 ? #1979

Ace-Tang opened this issue Feb 12, 2019 · 8 comments · Fixed by #1984

Comments

@Ace-Tang
Copy link
Contributor

Ace-Tang commented Feb 12, 2019

0a8e411 is a good work to fix CVE-2019-5736, but I get some problem with the patch on kernel 3.10.

The background is that our production online use two major kernel 3.10 and 4.9. In patch, memfd_create supported until kernel 3.17, other method use O_TMPFILE, it is supported until 3.11.

the other confused me is that with these code

/* Use our own wrapper for memfd_create. */
#if !defined(SYS_memfd_create) && defined(__NR_memfd_create)
#  define SYS_memfd_create __NR_memfd_create
#endif
#ifdef SYS_memfd_create
#  define HAVE_MEMFD_CREATE
/* memfd_create(2) flags -- copied from <linux/memfd.h>. */
#  ifndef MFD_CLOEXEC
#    define MFD_CLOEXEC       0x0001U
#    define MFD_ALLOW_SEALING 0x0002U
#  endif
int memfd_create(const char *name, unsigned int flags)
{
    return syscall(SYS_memfd_create, name, flags);
}
#endif

even I run code on kernel 2.6, HAVE_MEMFD_CREATE always been defined, but memfd_create not work.

@cyphar
Copy link
Member

cyphar commented Feb 12, 2019

but I get some problem with the patch on kernel 3.10.

Yeah, this is going to be a problem. O_TMPFILE is already less-than-ideal (it's not really possible to check if something is an O_TMPFILE other than to count nlinks). The only way of doing this pre-3.11 is to create an actual file on /tmp -- which then just causes a whole bunch of other problems. I will look into it, but it's not going to be very fun.

even I run code on kernel 2.6, HAVE_MEMFD_CREATE always been defined, but memfd_create not work.

If your kernel doesn't have memfd_create (the syscall) then even if you compile it on a newer glibc that has SYS_memfd_create defined it still won't work. You need both an up-to-date glibc (or glibc headers) and an up-to-date kernel.

cyphar referenced this issue Feb 13, 2019
There are quite a few circumstances where /proc/self/exe pointing to a
pretty important container binary is a _bad_ thing, so to avoid this we
have to make a copy (preferably doing self-clean-up and not being
writeable).

We require memfd_create(2) -- though there is an O_TMPFILE fallback --
but we can always extend this to use a scratch MNT_DETACH overlayfs or
tmpfs. The main downside to this approach is no page-cache sharing for
the runc binary (which overlayfs would give us) but this is far less
complicated.

This is only done during nsenter so that it happens transparently to the
Go code, and any libcontainer users benefit from it. This also makes
ExtraFiles and --preserve-fds handling trivial (because we don't need to
worry about it).

Fixes: CVE-2019-5736
Co-developed-by: Christian Brauner <[email protected]>
Signed-off-by: Aleksa Sarai <[email protected]>
@kfox1111
Copy link

Is el7.6's kernel effected?

@Ace-Tang
Copy link
Contributor Author

@kfox1111 , check your kernel version uname -r to see if effect

@kfox1111
Copy link

el based systems are notorious for back porting lots of patches from newer kernels. the version number rarely reflects its actual functionality.

@giuseppe
Copy link
Member

Is el7.6's kernel effected?

el7.6 kernel has the memfd_create syscall.

@xiaoding945
Copy link

how to check kernel version 3.xx weather has the memfd_create syscall?

@giuseppe
Copy link
Member

@xiaoding945 the easiest way is to write a simple C program that uses memfd_create and check that it doesn't return any error

@kolyshkin
Copy link
Contributor

@giuseppe @xianlubird I learned it the hard way that the simple presence of memfd_create() syscall doesn't mean anything. More details here: #1984 (comment).

In short:

  • Ubuntu 16.04 (kernel 3.13) does not work, but the fix is easy, they have 4.4 lts kernel available (https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Server-2)
  • Debian Jessie (3.16-based kernels) should work
  • RHEL 7.x (3.10-based kernels) might or might not work (RHEL 7.2 does not, others, I'm not quite sure)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants