When using the mapped-file security mode, we shouldn't let the client mess
with the metadata. The current code already tries to hide the metadata dir
from the client by skipping it in local_readdir(). But the client can still
access or modify it through several other operations. This can be used to
escalate privileges in the guest.
Affected backend operations are:
- local_mknod()
- local_mkdir()
- local_open2()
- local_symlink()
- local_link()
- local_unlinkat()
- local_renameat()
- local_rename()
- local_name_to_path()
Other operations are safe because they are only passed a fid path, which
is computed internally in local_name_to_path().
This patch converts all the functions listed above to fail and return
EINVAL when being passed the name of the metadata dir. This may look
like a poor choice for errno, but there's no such thing as an illegal
path name on Linux and I could not think of anything better.
This fixes CVE-2017-7493.
Reported-by: Leo Gaspard <leo@gaspard.io>
Signed-off-by: Greg Kurz <groug@kaod.org>
---
hw/9pfs/9p-local.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 56 insertions(+), 2 deletions(-)
I had already sent a similar fix as part of a bigger patchset 10 days ago,
but it turned out that a CVE got created since then for this specific issue.
I hence repost a standalone patch with some minor changes and an updated
changelog.
Eric,
I'd appreciate if you could review this, so that I can send a pull request
ASAP.
Thanks.
--
Greg
diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
index f3ebca4f7a56..a2486566afb7 100644
--- a/hw/9pfs/9p-local.c
+++ b/hw/9pfs/9p-local.c
@@ -452,6 +452,11 @@ static off_t local_telldir(FsContext *ctx, V9fsFidOpenState *fs)
return telldir(fs->dir.stream);
}
+static bool local_is_mapped_file_metadata(FsContext *fs_ctx, const char *name)
+{
+ return !strcmp(name, VIRTFS_META_DIR);
+}
+
static struct dirent *local_readdir(FsContext *ctx, V9fsFidOpenState *fs)
{
struct dirent *entry;
@@ -465,8 +470,8 @@ again:
if (ctx->export_flags & V9FS_SM_MAPPED) {
entry->d_type = DT_UNKNOWN;
} else if (ctx->export_flags & V9FS_SM_MAPPED_FILE) {
- if (!strcmp(entry->d_name, VIRTFS_META_DIR)) {
- /* skp the meta data directory */
+ if (local_is_mapped_file_metadata(ctx, entry->d_name)) {
+ /* skip the meta data directory */
goto again;
}
entry->d_type = DT_UNKNOWN;
@@ -559,6 +564,12 @@ static int local_mknod(FsContext *fs_ctx, V9fsPath *dir_path,
int err = -1;
int dirfd;
+ if (fs_ctx->export_flags & V9FS_SM_MAPPED_FILE &&
+ local_is_mapped_file_metadata(fs_ctx, name)) {
+ errno = EINVAL;
+ return -1;
+ }
+
dirfd = local_opendir_nofollow(fs_ctx, dir_path->data);
if (dirfd == -1) {
return -1;
@@ -605,6 +616,12 @@ static int local_mkdir(FsContext *fs_ctx, V9fsPath *dir_path,
int err = -1;
int dirfd;
+ if (fs_ctx->export_flags & V9FS_SM_MAPPED_FILE &&
+ local_is_mapped_file_metadata(fs_ctx, name)) {
+ errno = EINVAL;
+ return -1;
+ }
+
dirfd = local_opendir_nofollow(fs_ctx, dir_path->data);
if (dirfd == -1) {
return -1;
@@ -694,6 +711,12 @@ static int local_open2(FsContext *fs_ctx, V9fsPath *dir_path, const char *name,
int err = -1;
int dirfd;
+ if (fs_ctx->export_flags & V9FS_SM_MAPPED_FILE &&
+ local_is_mapped_file_metadata(fs_ctx, name)) {
+ errno = EINVAL;
+ return -1;
+ }
+
/*
* Mark all the open to not follow symlinks
*/
@@ -752,6 +775,12 @@ static int local_symlink(FsContext *fs_ctx, const char *oldpath,
int err = -1;
int dirfd;
+ if (fs_ctx->export_flags & V9FS_SM_MAPPED_FILE &&
+ local_is_mapped_file_metadata(fs_ctx, name)) {
+ errno = EINVAL;
+ return -1;
+ }
+
dirfd = local_opendir_nofollow(fs_ctx, dir_path->data);
if (dirfd == -1) {
return -1;
@@ -826,6 +855,12 @@ static int local_link(FsContext *ctx, V9fsPath *oldpath,
int ret = -1;
int odirfd, ndirfd;
+ if (ctx->export_flags & V9FS_SM_MAPPED_FILE &&
+ local_is_mapped_file_metadata(ctx, name)) {
+ errno = EINVAL;
+ return -1;
+ }
+
odirfd = local_opendir_nofollow(ctx, odirpath);
if (odirfd == -1) {
goto out;
@@ -1096,6 +1131,12 @@ static int local_lremovexattr(FsContext *ctx, V9fsPath *fs_path,
static int local_name_to_path(FsContext *ctx, V9fsPath *dir_path,
const char *name, V9fsPath *target)
{
+ if (ctx->export_flags & V9FS_SM_MAPPED_FILE &&
+ local_is_mapped_file_metadata(ctx, name)) {
+ errno = EINVAL;
+ return -1;
+ }
+
if (dir_path) {
v9fs_path_sprintf(target, "%s/%s", dir_path->data, name);
} else if (strcmp(name, "/")) {
@@ -1116,6 +1157,13 @@ static int local_renameat(FsContext *ctx, V9fsPath *olddir,
int ret;
int odirfd, ndirfd;
+ if (ctx->export_flags & V9FS_SM_MAPPED_FILE &&
+ (local_is_mapped_file_metadata(ctx, old_name) ||
+ local_is_mapped_file_metadata(ctx, new_name))) {
+ errno = EINVAL;
+ return -1;
+ }
+
odirfd = local_opendir_nofollow(ctx, olddir->data);
if (odirfd == -1) {
return -1;
@@ -1206,6 +1254,12 @@ static int local_unlinkat(FsContext *ctx, V9fsPath *dir,
int ret;
int dirfd;
+ if (ctx->export_flags & V9FS_SM_MAPPED_FILE &&
+ local_is_mapped_file_metadata(ctx, name)) {
+ errno = EINVAL;
+ return -1;
+ }
+
dirfd = local_opendir_nofollow(ctx, dir->data);
if (dirfd == -1) {
return -1;
On 05/15/2017 11:07 AM, Greg Kurz wrote: > When using the mapped-file security mode, we shouldn't let the client mess > with the metadata. The current code already tries to hide the metadata dir > from the client by skipping it in local_readdir(). But the client can still > access or modify it through several other operations. This can be used to > escalate privileges in the guest. > > Affected backend operations are: > - local_mknod() > - local_mkdir() > - local_open2() > - local_symlink() > - local_link() > - local_unlinkat() > - local_renameat() > - local_rename() > - local_name_to_path() > > Other operations are safe because they are only passed a fid path, which > is computed internally in local_name_to_path(). > > This patch converts all the functions listed above to fail and return > EINVAL when being passed the name of the metadata dir. This may look > like a poor choice for errno, but there's no such thing as an illegal > path name on Linux and I could not think of anything better. > > This fixes CVE-2017-7493. > > Reported-by: Leo Gaspard <leo@gaspard.io> > Signed-off-by: Greg Kurz <groug@kaod.org> > --- Reviewed-by: Eric Blake <eblake@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On Mon, 15 May 2017 12:37:08 -0500 Eric Blake <eblake@redhat.com> wrote: > On 05/15/2017 11:07 AM, Greg Kurz wrote: > > When using the mapped-file security mode, we shouldn't let the client mess > > with the metadata. The current code already tries to hide the metadata dir > > from the client by skipping it in local_readdir(). But the client can still > > access or modify it through several other operations. This can be used to > > escalate privileges in the guest. > > > > Affected backend operations are: > > - local_mknod() > > - local_mkdir() > > - local_open2() > > - local_symlink() > > - local_link() > > - local_unlinkat() > > - local_renameat() > > - local_rename() > > - local_name_to_path() > > > > Other operations are safe because they are only passed a fid path, which > > is computed internally in local_name_to_path(). > > > > This patch converts all the functions listed above to fail and return > > EINVAL when being passed the name of the metadata dir. This may look > > like a poor choice for errno, but there's no such thing as an illegal > > path name on Linux and I could not think of anything better. > > > > This fixes CVE-2017-7493. > > > > Reported-by: Leo Gaspard <leo@gaspard.io> > > Signed-off-by: Greg Kurz <groug@kaod.org> > > --- > > Reviewed-by: Eric Blake <eblake@redhat.com> > Thanks again for your help. Cheers, -- Greg
© 2016 - 2024 Red Hat, Inc.