-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2018-15470 / XSA-272
oxenstored does not apply quota-maxentity
UPDATES IN VERSION 3
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
the order of evaluation of subexpressions is not specified. In
practice, different implementations behave differently.
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.
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
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!"
print_endline "This code is vulnerable!"
let () = main ()
$ ocamlc order.ml -o order.bytecode
This code is vulnerable!
$ ocamlopt order.ml -o 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.
There are no mitigations available.
This issue was discovered by Christian Lindig of Citrix.
Applying the appropriate attached patch resolves this issue.
xsa272.patch All versions of Xen
$ sha256sum xsa272*
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
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
(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:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
Xen-announce mailing list
|Free forum by Nabble||Edit this page|