From: Greg Kurz <groug@kaod.org>
To: P J P <ppandit@redhat.com>
Cc: Qemu Developers <qemu-devel@nongnu.org>,
Felix Wilhelm <fwilhelm@ernw.de>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
"Michael S. Tsirkin" <mtsirkin@redhat.com>,
Prasad J Pandit <pjp@fedoraproject.org>,
qemu-stable@nongnu.org, peter.maydell@linaro.org
Subject: Re: [Qemu-devel] [PATCH] 9pfs: add check for relative path
Date: Thu, 18 Aug 2016 19:06:56 +0200 [thread overview]
Message-ID: <20160818190656.6c36f896@bahia.lan> (raw)
In-Reply-To: <1470892391-4917-1-git-send-email-ppandit@redhat.com>
On Thu, 11 Aug 2016 10:43:11 +0530
P J P <ppandit@redhat.com> wrote:
> From: Prasad J Pandit <pjp@fedoraproject.org>
>
> At various places in 9pfs back-end, it creates full path by
> concatenating two path strings. It could lead to a path
> traversal issue if one of the parameter was a relative path.
> Add check to avoid it.
>
> Reported-by: Felix Wilhelm <fwilhelm@ernw.de>
> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
> ---
With GDB attached to my QEMU, I could easily change the path names to have a
".." component just like a malicious guest would do, and cause the path traversal
issue to happen with renameat at least. And this patch indeed fixes the issue in
this case.
I'm still on holidays and I could not find time to do more testing and reviewing
though. But since the official linux 9p client does not send relative paths, I
don't expect any regression to happen if we apply the whole patch. I hence give:
Acked-by: Greg Kurz <groug@kaod.org>
Since this is a serious security issue, I shall send a pull request for this
patch tomorrow so that it gets into rc4. Also Cc'ing stable in case we deliver
another 2.6.x release one day.
If someone disagrees, please speak up ASAP.
Aneesh ? Michael ? Peter ?
> hw/9pfs/9p-local.c | 31 +++++++++++++++++++++++++++----
> 1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
> index 3f271fc..c20331a 100644
> --- a/hw/9pfs/9p-local.c
> +++ b/hw/9pfs/9p-local.c
> @@ -493,6 +493,9 @@ static int local_mknod(FsContext *fs_ctx, V9fsPath *dir_path,
> char *buffer = NULL;
>
> v9fs_string_init(&fullname);
> + if (strstr(name, "../")) {
> + return err;
> + }
> v9fs_string_sprintf(&fullname, "%s/%s", dir_path->data, name);
> path = fullname.data;
>
> @@ -554,6 +557,9 @@ static int local_mkdir(FsContext *fs_ctx, V9fsPath *dir_path,
> char *buffer = NULL;
>
> v9fs_string_init(&fullname);
> + if (strstr(name, "../")) {
> + return err;
> + }
> v9fs_string_sprintf(&fullname, "%s/%s", dir_path->data, name);
> path = fullname.data;
>
> @@ -663,6 +669,9 @@ static int local_open2(FsContext *fs_ctx, V9fsPath *dir_path, const char *name,
> flags |= O_NOFOLLOW;
>
> v9fs_string_init(&fullname);
> + if (strstr(name, "../")) {
> + return err;
> + }
> v9fs_string_sprintf(&fullname, "%s/%s", dir_path->data, name);
> path = fullname.data;
>
> @@ -734,6 +743,9 @@ static int local_symlink(FsContext *fs_ctx, const char *oldpath,
> char *buffer = NULL;
>
> v9fs_string_init(&fullname);
> + if (strstr(name, "../")) {
> + return err;
> + }
> v9fs_string_sprintf(&fullname, "%s/%s", dir_path->data, name);
> newpath = fullname.data;
>
> @@ -830,11 +842,14 @@ out:
> static int local_link(FsContext *ctx, V9fsPath *oldpath,
> V9fsPath *dirpath, const char *name)
> {
> - int ret;
> + int ret = -1;
> V9fsString newpath;
> char *buffer, *buffer1;
>
> v9fs_string_init(&newpath);
> + if (strstr(name, "../")) {
> + return ret;
> + }
> v9fs_string_sprintf(&newpath, "%s/%s", dirpath->data, name);
>
> buffer = rpath(ctx, oldpath->data);
> @@ -1059,6 +1074,9 @@ 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 (strstr(name, "../")) {
> + return -1;
> + }
> if (dir_path) {
> v9fs_string_sprintf((V9fsString *)target, "%s/%s",
> dir_path->data, name);
> @@ -1074,12 +1092,15 @@ static int local_renameat(FsContext *ctx, V9fsPath *olddir,
> const char *old_name, V9fsPath *newdir,
> const char *new_name)
> {
> - int ret;
> + int ret = -1;
> V9fsString old_full_name, new_full_name;
>
> v9fs_string_init(&old_full_name);
> v9fs_string_init(&new_full_name);
>
> + if (strstr(old_name, "../") || strstr(new_name, "../")) {
> + return ret;
> + }
> v9fs_string_sprintf(&old_full_name, "%s/%s", olddir->data, old_name);
> v9fs_string_sprintf(&new_full_name, "%s/%s", newdir->data, new_name);
>
> @@ -1092,12 +1113,14 @@ static int local_renameat(FsContext *ctx, V9fsPath *olddir,
> static int local_unlinkat(FsContext *ctx, V9fsPath *dir,
> const char *name, int flags)
> {
> - int ret;
> + int ret = -1;
> V9fsString fullname;
> char *buffer;
>
> v9fs_string_init(&fullname);
> -
> + if (strstr(name, "../")) {
> + return ret;
> + }
> v9fs_string_sprintf(&fullname, "%s/%s", dir->data, name);
> if (ctx->export_flags & V9FS_SM_MAPPED_FILE) {
> if (flags == AT_REMOVEDIR) {
next prev parent reply other threads:[~2016-08-18 17:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-11 5:13 [Qemu-devel] [PATCH] 9pfs: add check for relative path P J P
2016-08-11 6:17 ` no-reply
2016-08-11 6:27 ` Fam Zheng
2016-08-18 16:55 ` Greg Kurz
2016-08-11 6:31 ` Aneesh Kumar K.V
2016-08-18 15:19 ` Greg Kurz
2016-08-18 17:06 ` Greg Kurz [this message]
2016-08-19 14:55 ` Peter Maydell
2016-08-19 15:14 ` Peter Maydell
2016-08-19 16:37 ` Greg Kurz
2016-08-19 17:03 ` Peter Maydell
2016-08-19 17:30 ` Greg Kurz
2016-08-22 9:23 ` Peter Maydell
2016-08-22 10:07 ` P J P
2016-08-22 15:02 ` Michael S. Tsirkin
2016-08-22 15:07 ` Peter Maydell
2016-08-22 14:14 ` Michael S. Tsirkin
2016-08-19 16:24 ` Greg Kurz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160818190656.6c36f896@bahia.lan \
--to=groug@kaod.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=fwilhelm@ernw.de \
--cc=mtsirkin@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=pjp@fedoraproject.org \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.