Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 615308 - <app-emulation/xen-4.7.2: xenstore denial of service via repeated update (XSA-206)
Summary: <app-emulation/xen-4.7.2: xenstore denial of service via repeated update (XSA...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL: https://xenbits.xen.org/xsa/advisory-...
Whiteboard: C3 [noglsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-11 18:47 UTC by Yury German
Modified: 2017-08-08 00:18 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yury German Gentoo Infrastructure gentoo-dev 2017-04-11 18:47:30 UTC
Xen Security Advisory XSA-206
                              version 9

            xenstore denial of service via repeated update

UPDATES IN VERSION 9
====================

More exhaustive testing discovered a further bug in the oxenstored
patches: if no transactions are performed (ie, only atomic writes),
the new in-memory history record can grow without bound.  This means
that an attacker could be able to render oxenstored slow and
eventually unuseable, and/or run dom0 out of memory.  Running any
transaction (even one which aborts) will clear the history, so
periodically running the command
   xenstore-write /xsa206-v7-leak 1 /xsa206-v7-leak 2
will mitigate the problem.

This bug is fixed in the new final patch attached to this version,
 "oxenstored: trim history in the frequent_ops function"
The other patches remain unchanged.

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

xenstored supports transactions, such that if writes which would
invalidate assumptions of a transaction occur, the entire transaction
fails.  Typical response on a failed transaction is to simply retry
the transaction until it succeeds.

Unprivileged domains may issue writes to xenstore which conflict with
transactions either of the toolstack or of backends such as the driver
domain. Depending on the exact timing, repeated writes may cause
transactions made by these entities to fail indefinitely.

IMPACT
======

Unprivileged guests may be able to stall progress of the control
domain or driver domain, possibly leading to a Denial of Service (DoS)
of the entire host.

In most systems, the impact is limited to the delay or prevention of
control operations (such as domain creation, reconfiguration,
configuration enquiry, or destruction).

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

All Xen versions are vulnerable.

Both "cxenstored" (the version of xenstored written in C) and
"oxenstored" (the version of xenstored written in ocaml) are
vulnerable.  oxenstored in Xen 4.7 and later is more difficult to
exploit because it has more fine-grained detection of conflicts.

MITIGATION
==========

If the rogue domain(s) can be identified, it will usually be possible
to pause them with "xl pause" and/or destroy them with "xl destroy".
Note that if the toolstack is not simply "xl", the toolstack may be
confused by use of "xl" to pause or destroy domains.

The output of commands such as "xl top" and "xenstore-ls -fp" may be
helpful to find the rogue domain(s).

When the rogue domain(s) are paused or destroyed, the stuck operations
will become unstuck.

CREDITS
=======

This issue was discovered by Jürgen Groß of SUSE.

RESOLUTION
==========

Applying the appropriate attached patches resolves this issue by
limiting the rate at which it is possible to invalidate transactions.

C xenstored
- -----------

Only the first of the patches is strictly necessary to solve the
issue; the second patch adds logging for when the situation occurs, so
may be useful in detecting attacks or debugging issues.

ocaml xenstored
- ---------------

The oxenstored patches depend on some patches to reduce false
conflicts in transactions that were introduced in Xen 4.7.  The
patches for 4.4-4.6 include backported versions of these patches in
addition to backported versions of the ratelimiting patches.

Xen 4.4 requires some further backports in order to allow the
ratelimiting patches to apply cleanly without significant reworking.
These have been kept to a minimum.

Identification of patch files
- -----------------------------

The patch number ranges are:
xen-unstable, 4.8, and 4.7:
  0001-0002: cxenstored
  0003-0016: oxenstored ratelimiting

4.6, 4.5:
  0001-0002: cxenstored
  0003-0010: oxenstored avoidance of needless conflicts
  0011-0024: oxenstored ratelimiting

4.4:
  0001-0002: cxenstored
  0003-0009: oxenstored further prerequisites
  0009-0017: oxenstored avoidance of needless conflicts
  0018-0031: oxenstored ratelimiting

xsa206-unstable/*.patch  xen-unstable
xsa206-4.8/*.patch       xen-4.8
xsa206-4.7/*.patch       xen-4.7
xsa206-4.6/*.patch       xen-4.6
xsa206-4.5/*.patch       xen-4.5
xsa206-4.4/*.patch       xen-4.4
Comment 1 Yury German Gentoo Infrastructure gentoo-dev 2017-05-15 16:17:41 UTC
Is this fixed in?
app-emulation/{xen-4.7.2-r1,{xen-pvgrub,sen-tools}-4.7.2}

But #615980
Comment 2 Yixun Lan archtester gentoo-dev 2017-05-15 21:45:03 UTC
yes, it's fixed at >=app-emulation/xen-4.7.2, >=app-emulation/xen-4.8.0-r4

commit 3e6792d0d92b550d270e66db7e426b82d83e1be2
Author: Yixun Lan <dlan@gentoo.org>
Date:   Sun Apr 9 08:04:26 2017 +0800

    app-emulation/xen: version bump, 4.7.2
    
    fix XSA-210 in version 4.8.0-r4
    fix XSA-206,212 in version 4.7.2, 4.8.0-r4