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

List:       oss-security
Subject:    [oss-security] Xen Security Advisory 272 v2 - oxenstored does not apply quota-maxentity
From:       Xen.org security team <security () xen ! org>
Date:       2018-08-14 17:19:35
Message-ID: E1fpcyl-0001qx-Dd () xenbits ! xenproject ! org
[Download RAW message or body]

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

                    Xen Security Advisory XSA-272
                              version 2

               oxenstored does not apply quota-maxentity

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

Ammend patch to reference XSA-272 in the commit message.

Public release.

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

The logic in oxenstored for handling writes depended on the order of
evaluation of expressions making up a tuple.

As indicated in section 7.7.3 "Operations on data structures" of the
OCaml manual:

  http://caml.inria.fr/pub/docs/manual-ocaml/expr.html

the order of evaluation of subexpressions is not specified.  In
practice, different implementations behave differently.

IMPACT
======

oxenstored may not enforce the configured quota-maxentity.

This allows a malicious or buggy guest to write as many xenstore entries
as it wishes, causing unbounded memory usage in oxenstored.  This can
lead to a system-wide DoS.

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

Xen 4.1 and later are potentially vulnerable.

Only systems using the OCaml xenstored implementation are potentially
vulnerable.  Systems using the C xenstored implementation are not
vulnerable.

Whether the compiled oxenstored binary is vulnerable depends on which
compiler was used.  OCaml can be compiled either as bytecode (with
ocamlc) or as a native binary (with ocamlopt).

The following OCaml program demonstrates the issue, and identifies
whether the resulting oxenstored binary will skip the quota enforcement.

  $ cat order.ml
  let check () =
    let flag = ref false in
    let update _ = flag := true; () in
    List.iter update [1;2;3], !flag

  let main () =
    let _, flag = check () in
    if flag then
    print_endline "This code is not vulnerable!"
    else
    print_endline "This code is vulnerable!"

  let () = main ()

  $ ocamlc order.ml -o order.bytecode
  $ ./order.bytecode
  This code is vulnerable!
  $ ocamlopt order.ml -o order.native
  $ ./order.native
  This code is not vulnerable!

To confirm whether an OCaml binary is bytecode or native, use file.

  $ file order.bytecode
  order.bytecode: a /usr/bin/ocamlrun script executable (binary data)
  $ file order.native
  order.native: ELF 64-bit LSB executable, ...

NOTE: These results are applicable to OCaml 4.01.0-5 as distributed in
Debian Jessie.  These results are not representative of other versions
of OCaml, or of other OS distributions.

MITIGATION
==========

There are no mitigations available.

CREDITS
=======

This issue was discovered by Christian Lindig of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa272.patch           All versions of Xen

$ sha256sum xsa272*
0da953ca48d0cf0688ecff6a074304a9d2217871809a76ef26b9addeb66ecb3e  xsa272.meta
6e0359d89bf65794f16d39198cc90f5c3137bce4eb850e54625ab00e2c568c2c  xsa272.patch
$

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

iQEcBAEBCAAGBQJbcw8fAAoJEIP+FMlX6CvZ1VYIALce26h9Sf0P0joLd/fhUwf4
JcCIaTWvHsy0ucJgpi7i+SCMa7Iz60CriK6dSYlwIuPvka8XU5MDmZ56gbENApDZ
ibWMwvyCrgb0BH3VIwJZfk7eaKM7OwKeEnnIrIWaVGsT2StwoZOHgdLRLCTSFJ/K
iss3ALSzZ8z7/WqEkBE3JeJ7skrh5nmNp428fJXWYhOyYbqkqyggn6XzBQg/EzGD
vabxz4CdYCr1ox7sq42Q/UFeLoWB6CKCLgRgqOGyCrm7K324ymBzRXtXpPUrLEaq
ugR27W/zr09e8N/fOhH4dBNCzkktuqclwrfMlFr1WUfiltSDmVwNZkURkvVGeu0=
=TPZD
-----END PGP SIGNATURE-----

["xsa272.meta" (application/octet-stream)]
["xsa272.patch" (application/octet-stream)]

From: Christian Lindig <christian.lindig@citrix.com>
Subject: tools/oxenstored: Make evaluation order explicit

In Store.path_write(), Path.apply_modify() updates the node_created
reference and both the value of apply_modify() and node_created are
returned by path_write().

At least with OCaml 4.06.1 this leads to the value of node_created being
returned *before* it is updated by apply_modify().  This in turn leads
to the quota for a domain not being updated in Store.write().  Hence, a
guest can create an unlimited number of entries in xenstore.

The fix is to make evaluation order explicit.

This is XSA-272.

Signed-off-by: Christian Lindig <christian.lindig@citrix.com>
Reviewed-by: Rob Hoes <rob.hoes@citrix.com>

diff --git a/tools/ocaml/xenstored/store.ml b/tools/ocaml/xenstored/store.ml
index 9f619b8fd5..8b0727f8a8 100644
--- a/tools/ocaml/xenstored/store.ml
+++ b/tools/ocaml/xenstored/store.ml
@@ -257,7 +257,8 @@ let path_write store perm path value =
 		Node.check_perm store.root perm Perms.WRITE;
 		Node.set_value store.root value, false
 	) else
-		Path.apply_modify store.root path do_write, !node_created
+		let root = Path.apply_modify store.root path do_write in
+		root, !node_created
 
 let path_rm store perm path =
 	let do_rm node name =


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