[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Feb 2019 20:03:20 +1100
From: Aleksa Sarai <asarai@...e.de>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.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 2019-02-12, Solar Designer <solar@...nwall.com> wrote:
> static int proc_exe_link(struct dentry *dentry, struct path *exe_path)
> {
> struct task_struct *task;
> @@ -1628,10 +1780,15 @@ static int proc_exe_link(struct dentry *dentry,
> struct path *exe_path)
> exe_file = get_task_exe_file(task);
> put_task_struct(task);
> if (exe_file) {
> - *exe_path = exe_file->f_path;
> - path_get(&exe_file->f_path);
> + int result;
> +
> + result = path_in_ve(&exe_file->f_path);
> + if (result == 0) {
> + *exe_path = exe_file->f_path;
> + path_get(&exe_file->f_path);
> + }
> fput(exe_file);
> - return 0;
> + return result;
> } else
> return -ENOENT;
> }
> ---
>
> This uses Virtuozzo/OpenVZ specific APIs, so won't be directly usable
> elsewhere, but maybe a similar approach could be used upstream?
I have just sent v5 of my AT_THIS_ROOT patchset to LKML[1] -- which
allows userspace processes to block resolution of magic links. While
blocking access through /proc/self/exe helps block this issues, being
able to block (from userspace) resolution of all magic links would
massively help avoid problems like this.
[1]: https://marc.info/?l=linux-api&m=155002737629350&w=2
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
Download attachment "signature.asc" of type "application/pgp-signature" (834 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.
