[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240201004952.GA670@openwall.com>
Date: Thu, 1 Feb 2024 01:49:52 +0100
From: Solar Designer <solar@...nwall.com>
To: Aleksa Sarai <cyphar@...har.com>
Cc: oss-security@...ts.openwall.com, dev@...ncontainers.org
Subject: Re: runc: CVE-2024-21626: high severity container breakout attack
Hello Aleksa,
Thank you and others you credit for doing much more than fixing the
immediate issue, and for disclosing this in so much detail.
On Thu, Feb 01, 2024 at 07:33:01AM +1100, Aleksa Sarai wrote:
> This is a notification to vendors that use runc about a high-severity
> vulnerability (CVE-2024-21626) with several exploit methods which allow
> for full container breakouts due to an internal file descriptor leak.
> The core issue is a file descriptor leak, and while we do O_CLOEXEC all
> file descriptors before executing the container code, the file
> descriptor is open when doing setcwd(2) which means that the reference
> can be kept alive into the container by configuring the working
> directory to be a path resolved through the file descriptor (and the
> non-dumpable bit is unset after execve(2) meaning that there are
> multiple ways to attack this other than bad configurations).
What's setcwd(2)? Perhaps you meant something else?
> There is also an execve(2)-based attack that makes simple verification
> unworkable and was particularly hairy to fix (the patch involves doing
> //go:linkname to access Go runtime internals, because the only way to
> defend against it entirely is to close all unneeded file descriptors --
> for the same reason that #!-based tricks meant that CVE-2019-5736
> required drastic measures).
For reference, here are the threads you started on CVE-2019-5736 and its
exploit back in 2019:
https://www.openwall.com/lists/oss-security/2019/02/11/2
https://www.openwall.com/lists/oss-security/2019/02/13/3
In one of the messages:
https://www.openwall.com/lists/oss-security/2019/02/13/1
you mentioned having sent your "AT_THIS_ROOT patchset to LKML -- which
allows userspace processes to block resolution of magic links." What's
the current status of this effort, and does/would it help against this
new issue?
Alexander
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.
