[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Xen Security Advisory 271 v2 (CVE-2018-14007) - XAPI HTTP directory traversal
From:       Xen.org security team <security () xen ! org>
Date:       2018-08-14 17:18:03
Message-ID: E1fpcxH-0007Gh-9J () xenbits ! xenproject ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2018-14007 / XSA-271
                               version 2

                     XAPI HTTP directory traversal

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

XAPI has an unauthenticated HTTP endpoint update/ which exports the
contents of /var/update for other hosts to use.

However, the resolution of . and .. in paths is performed before url
unquoting is performed.  This allows an attacker to traverse out of the
web root.

IMPACT
======

An unauthenticated user with access to the management network can read
arbitrary files from the dom0 filesystem.  This includes the pool secret
/etc/xensource/ptoken which grants the attacker full administrator
access.

VULNERABLE SYSTEMS
==================

All versions of XAPI since v1.13.0 are vulnerable.

If the directory /var/update doesn't exist, the vulnerability is not
exposed.

MITIGATION
==========

In the recommended configuration, the management network is isolated and
isn't reachable from untrusted hosts, or by general network traffic.

CREDITS
=======

This issue was discovered by Ronald Volgers of Computest
https://www.computest.nl/en/

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa271-xapi.patch

$ sha256sum xsa271*
ffefb71cd328e0ee5654c135bf9b08f48abedd013f1c68d5589132e2a03a01f8  xsa271-xapi.patch
$

REGENERATION OF POOL SECRET
===========================

There are no known exploits in the wild.  If there is a risk that
credentials could have been stolen, they should be reset.

Most credentials can be reset via normal administrative means, but the
pool secret doesn't have any mechanism to reset.  The following
instructions should be used:

 1) On all pool members, stop Xapi:
    # service xapi stop

 2) On the pool master:
    # rm /etc/xensource/ptoken
    # /opt/xensource/libexec/genptoken -f -o /etc/xensource/ptoken

 3) Copy /etc/xensource/ptoken to all pool slaves

 4) On the pool master, restart the toolstack:
    # xe-toolstack-restart

 5) On all pool slaves, restart the toolstack:
    # xe-toolstack-restart

Once the pool secret has been regenerated, the root password can be
changed with:
    # xe user-password-change

Furthermore, consideration should be given to other credentials, such as
(but not limited to) SSL keys, Storage SAN/iSCSI/NFS details, as well as
secrets contained within VMs disks/snapshots/etc.

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJbcw6vAAoJEIP+FMlX6CvZx6cH/0qaq4PDDHSrIONP7v35ZYWe
nZEoA+IWk0u35t4MwSRA8qcXZ9m+d7icHdE0c5Jwdh2sBOSFKzoehCuZOFXVpYTv
SHdr/J3ilZRN1KV7Zo/agZJFYClV5QxR118PnVYFqsAHVGjxh6RzazyBNPUTkoIa
qw/FBQwsib4Wkj5/RPympYscxetzAUoYiFeVtTgtqknXlt3UbXqzwg/lXTrMZwtG
nBSjFEW+EURlkKR0HF85mtFBmqA1I3xsKgJDaob5KWl+HmlIj0SY9knQ2le3lgxn
7zXiPSwOARg2E+vl3GB1Xd1fgcRGykBtjVWPX9uAgdb/C7qx6DN2PYEdyz1xZtI=
=5lIm
-----END PGP SIGNATURE-----

["xsa271-xapi.patch" (application/octet-stream)]

From: Rob Hoes <rob.hoes@citrix.com>
Date: Wed, 18 Jul 2018 11:18:27 +0100
Subject: Fix path verification in /update/ handler

The handler decoded the percent-symbols in the given path after resolving the .
and .. patterns. This meant that any "%2e%2e" strings in the path would still
result in .. strings in the validate path, which made it possible to download
files outside the designated directory for updates.

Reported-by: Ronald Volgers <rvolgers@computest.nl>
Signed-off-by: Rob Hoes <rob.hoes@citrix.com>

diff --git a/ocaml/xapi/xapi_pool_update.ml b/ocaml/xapi/xapi_pool_update.ml
index 275a8e5..ccc1d88 100644
--- a/ocaml/xapi/xapi_pool_update.ml
+++ b/ocaml/xapi/xapi_pool_update.ml
@@ -536,8 +536,8 @@ let path_from_uri uri =
   (* remove any dodgy use of "." or ".." NB we don't prevent the use of symlinks *)
   String.sub_to_end uri (String.length Constants.get_pool_update_download_uri)
   |> Filename.concat !Xapi_globs.host_update_dir
-  |> Stdext.Unixext.resolve_dot_and_dotdot
   |> Uri.pct_decode
+  |> Stdext.Unixext.resolve_dot_and_dotdot
 
 let pool_update_download_handler (req: Request.t) s _ =
   debug "pool_update.pool_update_download_handler URL %s" req.Request.uri;


[prev in list] [next in list] [prev in thread] [next in thread]