Date: Tue, 12 Feb 2019 10:03:38 -0500 From: Steve Grubb <sgrubb@...hat.com> To: oss-security@...ts.openwall.com Cc: Florian Weimer <fweimer@...hat.com>, Aleksa Sarai <cyphar@...har.com>, dev@...ncontainers.org, Christian Brauner <christian.brauner@...ntu.com> Subject: Re: CVE-2019-5736: runc container breakout (all versions) On Tuesday, February 12, 2019 8:55:18 AM EST Florian Weimer wrote: > * Aleksa Sarai: > > + memfd = memfd_create(MEMFD_COMMENT, MFD_CLOEXEC|MFD_ALLOW_SEALING); > > + if (memfd < 0) > > + goto err_binfd; > > Is it really necessary to use a memfd_create here? Do you really need > sealing? It's a bit odd to add a new system call dependency in a > security update. That's along the lines of what I was thinking also. This looks like more of a workaround than a root cause fix. Without seeing the exploit or a full discussion of the theory of operation, we really can't pinpoint where the issue is. Was it because of CAP_DAC_OVERRIDE? Is there a missing permission check crossing a trust boundary? Was excessive permissions requested in a syscall? Given the patch, we can sort of see what the issue is but not the exact issue. > The ability fexecve a memfd descriptor is also rather > odd. I wouldn't have expected execute permissions on memfd descriptors, > so this sounds like a kernel bug (which now can't be fixed). I was thinking the same thing last week but for a whole different reason. Bash has tcp/ip. With it, you can create an in memory function, _wget. Using this, you can pull a python script off of the internet and pipe it into stdin of python. The python script can then pull an ELF shared object across the internet and stuff it into memory using memfd_create and then execute the shared object constructor using ctypes.CDLL() which points to the memfd. It's really quite slick. Using this technique, you can do everything in memory without ever touching disk. So, my thoughts were...why is this even permitted? Why should computer languages execute anything piped to stdin? Should execution of memory only objects be disallowed? Should the kernel have a 0111 umask for anything created by memfd_create? Why doesn't ctypes.CDLL() do a permission check to see if the execute bit is set before loading? Should descriptors that get created by memfd_create go to the fanotify interface for inspection/ permission? And now with this patch, how do you tell legitimate vs malicious use of memfd's? -Steve > I saw some other patch with a O_TMPFILE replacement. Does this really > work? It's possible to create a new name with linkat, so that's not a > real win security-wise. Could you just make a copy, under a different > owner, and not care how it is going to be modified? > > Thanks, > Florian
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.