[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 2 Feb 2024 22:27:36 +1100
From: Aleksa Sarai <cyphar@...har.com>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com, dev@...ncontainers.org
Subject: Re: Re: runc: CVE-2024-21626: high severity container
breakout attack
On 2024-02-01, Solar Designer <solar@...nwall.com> wrote:
> 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?
I meant chdir(2), sorry. I had getcwd(3) on my mind.
> > 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?
That eventually became openat2(2) which was merged in Linux 5.6.
Somewhat ironically, the switch to openat2(2) in runc was the cause of
one of the fd leaks that made this issue exploitable in runc! 😅
However, I later discovered that execve-related attacks currently cannot
be defended against -- even with a safe file descriptor inside the
container from openat2(2) passed to exeveat(AT_EMPTY_PATH) you can still
escape because the binfmt loader can open files in a way you cannot
control (the ELF loader will load shared libs and binfmt_script will
happily open everything). It might be necessary to add resolution flagst
o execveat(2) as well as a result, but I haven't gotten around to
working on that yet.
There's also some more work to do with blocking certain tricks related
to magic-links used by exploits when breaking out of containers (such as
keeping a handle to /proc/self/exe and then re-opening it for writing
afterwards). I had a talk on this topic at the last LSF/MM/BPF summit[1]
-- I have since reworked the design to block operations in a far more
systematic manner but I'm still playing around with prototypes at the
moment.
[1]: https://www.youtube.com/watch?v=NjPjEcQzCMY
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
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.
