qemu-e2k/hw/9pfs/9p-util.c

/*
 * 9p utilities
 *
 * Copyright IBM, Corp. 2017
 *
 * Authors:
 *  Greg Kurz <groug@kaod.org>
 *
 * This work is licensed under the terms of the GNU GPL, version 2 or later.
 * See the COPYING file in the top-level directory.
 */

#include "qemu/osdep.h"
#include "qemu/xattr.h"
#include "9p-util.h"

ssize_t fgetxattrat_nofollow(int dirfd, const char *filename, const char *name,
                             void *value, size_t size)
{
    char *proc_path = g_strdup_printf("/proc/self/fd/%d/%s", dirfd, filename);
    int ret;

    ret = lgetxattr(proc_path, name, value, size);
    g_free(proc_path);
    return ret;
}
9pfs: introduce relative_openat_nofollow() helper When using the passthrough security mode, symbolic links created by the guest are actual symbolic links on the host file system. Since the resolution of symbolic links during path walk is supposed to occur on the client side. The server should hence never receive any path pointing to an actual symbolic link. This isn't guaranteed by the protocol though, and malicious code in the guest can trick the server to issue various syscalls on paths whose one or more elements are symbolic links. In the case of the "local" backend using the "passthrough" or "none" security modes, the guest can directly create symbolic links to arbitrary locations on the host (as per spec). The "mapped-xattr" and "mapped-file" security modes are also affected to a lesser extent as they require some help from an external entity to create actual symbolic links on the host, i.e. another guest using "passthrough" mode for example. The current code hence relies on O_NOFOLLOW and "l*()" variants of system calls. Unfortunately, this only applies to the rightmost path component. A guest could maliciously replace any component in a trusted path with a symbolic link. This could allow any guest to escape a virtfs shared folder. This patch introduces a variant of the openat() syscall that successively opens each path element with O_NOFOLLOW. When passing a file descriptor pointing to a trusted directory, one is guaranteed to be returned a file descriptor pointing to a path which is beneath the trusted directory. This will be used by subsequent patches to implement symlink-safe path walk for any access to the backend. Symbolic links aren't the only threats actually: a malicious guest could change a path element to point to other types of file with undesirable effects: - a named pipe or any other thing that would cause openat() to block - a terminal device which would become QEMU's controlling terminal These issues can be addressed with O_NONBLOCK and O_NOCTTY. Two helpers are introduced: one to open intermediate path elements and one to open the rightmost path element. Suggested-by: Jann Horn <jannh@google.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> (renamed openat_nofollow() to relative_openat_nofollow(), assert path is relative and doesn't contain '//', fixed side-effect in assert, Greg Kurz) Signed-off-by: Greg Kurz <groug@kaod.org> 2017-02-26 23:42:03 +01:00			`/*`
			`* 9p utilities`
			`*`
			`* Copyright IBM, Corp. 2017`
			`*`
			`* Authors:`
			`* Greg Kurz <groug@kaod.org>`
			`*`
			`* This work is licensed under the terms of the GNU GPL, version 2 or later.`
			`* See the COPYING file in the top-level directory.`
			`*/`

			`#include "qemu/osdep.h"`
9pfs: local: lgetxattr: don't follow symlinks The local_lgetxattr() callback is vulnerable to symlink attacks because it calls lgetxattr() which follows symbolic links in all path elements but the rightmost one. This patch introduces a helper to emulate the non-existing fgetxattrat() function: it is implemented with /proc/self/fd which provides a trusted path that can be safely passed to lgetxattr(). local_lgetxattr() is converted to use this helper and opendir_nofollow(). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> 2017-02-26 23:42:26 +01:00			`#include "qemu/xattr.h"`
9pfs: introduce relative_openat_nofollow() helper When using the passthrough security mode, symbolic links created by the guest are actual symbolic links on the host file system. Since the resolution of symbolic links during path walk is supposed to occur on the client side. The server should hence never receive any path pointing to an actual symbolic link. This isn't guaranteed by the protocol though, and malicious code in the guest can trick the server to issue various syscalls on paths whose one or more elements are symbolic links. In the case of the "local" backend using the "passthrough" or "none" security modes, the guest can directly create symbolic links to arbitrary locations on the host (as per spec). The "mapped-xattr" and "mapped-file" security modes are also affected to a lesser extent as they require some help from an external entity to create actual symbolic links on the host, i.e. another guest using "passthrough" mode for example. The current code hence relies on O_NOFOLLOW and "l*()" variants of system calls. Unfortunately, this only applies to the rightmost path component. A guest could maliciously replace any component in a trusted path with a symbolic link. This could allow any guest to escape a virtfs shared folder. This patch introduces a variant of the openat() syscall that successively opens each path element with O_NOFOLLOW. When passing a file descriptor pointing to a trusted directory, one is guaranteed to be returned a file descriptor pointing to a path which is beneath the trusted directory. This will be used by subsequent patches to implement symlink-safe path walk for any access to the backend. Symbolic links aren't the only threats actually: a malicious guest could change a path element to point to other types of file with undesirable effects: - a named pipe or any other thing that would cause openat() to block - a terminal device which would become QEMU's controlling terminal These issues can be addressed with O_NONBLOCK and O_NOCTTY. Two helpers are introduced: one to open intermediate path elements and one to open the rightmost path element. Suggested-by: Jann Horn <jannh@google.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> (renamed openat_nofollow() to relative_openat_nofollow(), assert path is relative and doesn't contain '//', fixed side-effect in assert, Greg Kurz) Signed-off-by: Greg Kurz <groug@kaod.org> 2017-02-26 23:42:03 +01:00			`#include "9p-util.h"`

9pfs: local: lgetxattr: don't follow symlinks The local_lgetxattr() callback is vulnerable to symlink attacks because it calls lgetxattr() which follows symbolic links in all path elements but the rightmost one. This patch introduces a helper to emulate the non-existing fgetxattrat() function: it is implemented with /proc/self/fd which provides a trusted path that can be safely passed to lgetxattr(). local_lgetxattr() is converted to use this helper and opendir_nofollow(). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> 2017-02-26 23:42:26 +01:00			`ssize_t fgetxattrat_nofollow(int dirfd, const char filename, const char name,`
			`void *value, size_t size)`
			`{`
			`char *proc_path = g_strdup_printf("/proc/self/fd/%d/%s", dirfd, filename);`
			`int ret;`

			`ret = lgetxattr(proc_path, name, value, size);`
			`g_free(proc_path);`
			`return ret;`
			`}`