Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2020.3251
Multiple Xen vulnerabilities
23 September 2020
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: Xen
Publisher: Xen
Operating System: Virtualisation
Impact/Access: Increased Privileges -- Existing Account
Denial of Service -- Existing Account
Access Confidential Data -- Existing Account
Resolution: Patch/Upgrade
CVE Names: CVE-2020-25604 CVE-2020-25603 CVE-2020-25602
CVE-2020-25601 CVE-2020-25600 CVE-2020-25599
CVE-2020-25598 CVE-2020-25597 CVE-2020-25596
CVE-2020-25595
Original Bulletin:
http://xenbits.xen.org/xsa/advisory-340.html
http://xenbits.xen.org/xsa/advisory-334.html
http://xenbits.xen.org/xsa/advisory-337.html
http://xenbits.xen.org/xsa/advisory-344.html
http://xenbits.xen.org/xsa/advisory-338.html
http://xenbits.xen.org/xsa/advisory-342.html
http://xenbits.xen.org/xsa/advisory-336.html
http://xenbits.xen.org/xsa/advisory-343.html
http://xenbits.xen.org/xsa/advisory-339.html
http://xenbits.xen.org/xsa/advisory-333.html
Comment: This bulletin contains ten (10) Xen security advisories.
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2020-25603 / XSA-340
version 3
Missing memory barriers when accessing/allocating an event channel
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
Event channels control structures can be accessed lockless as long as the port
is considered to be valid. Such sequence is missing appropriate memory barrier
(e.g smp_*mb()) to prevent both the compiler and CPU to re-order access.
IMPACT
======
A malicious guest may be able to cause a hypervisor crash resulting in a
Denial of Service (DoS). Information leak and privilege escalation cannot be
excluded.
VULNERABLE SYSTEMS
==================
Systems running all versions of Xen are affected. Whether a system is
vulnerable will depend on the CPU and compiler used to build Xen.
For all the systems, the presence and the scope of the vulnerability
depends on the precise re-ordering performed by the compiler used to
build Xen.
We have not been able to survey compilers; consequently we cannot say
which compiler(s) might produce vulnerable code (with which code generation
options). GCC documentation clearly suggests that re-ordering is possible.
Arm systems will also be vulnerable if the CPU is able to re-order memory
access. Please consult your CPU vendor.
x86 systems are only vulnerable if a compiler performs re-ordering.
MITIGATION
==========
There is no known mitigation.
CREDITS
=======
This issue was discovered by Julien Grall of Amazon.
RESOLUTION
==========
Applying the attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa340.patch Xen 4.10 - xen-unstable
$ sha256sum xsa340*
72b75011b99e914ddb479082f88329063dcd1f55cc931059d950ecda276ee944 xsa340.meta
2bb088fcc1f8f79bf5ddb7b4e101cb1db76a343d2fb1cdafb7cd54612e4009da xsa340.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-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/ecMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZaBsH/RbQVpTAfl0zd7RyKXO34WZnWsYfwC+l8erEtf51
rmETfcqQP5rjNZZKEIDWcoYbJQU1DdC5tfVarUEYbGzCxPyBXlckcNKWmIVpkWnC
i+/XBALNjErN3AoJJOc8Tb3nfOZJlRrh3PXaqFo+xOqBn2vijgQJCXlpr1yRLDov
CatUy5DWmzVWVgByrkHs9Y+hsK7hb+DzxFvNiZUE7kv8a+R3F3smNgXDe/N7AasL
ZCJNVpfJGjqpk+EnffaTti9gd2aPxxzzmsWAoiW0C/6s/eJckhj/LxF7ZG5WbuVT
inhxm6zkQwBwvSTM7GLZpOuPXPegI8/RX+fO6lqsD0bcuQo=
=J1Xd
- -----END PGP SIGNATURE-----
- --------------------------------------------------------------------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2020-25598 / XSA-334
version 3
Missing unlock in XENMEM_acquire_resource error path
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
The RCU (Read, Copy, Update) mechanism is a synchronisation primitive.
A buggy error path in the XENMEM_acquire_resource exits without
releasing an RCU reference, which is conceptually similar to forgetting
to unlock a spinlock.
IMPACT
======
A buggy or malicious HVM stubdomain can cause an RCU reference to be
leaked. This causes subsequent administration operations, (e.g. CPU
offline) to livelock, resulting in a host Denial of Service.
VULNERABLE SYSTEMS
==================
The buggy codepath has been present since Xen 4.12. Xen 4.14 and later
are vulnerable to the DoS. The side effects are believed to be benign
on Xen 4.12 and 4.13, but patches are provided nevertheless.
The vulnerability can generally only be exploited by x86 HVM VMs, as
these are generally the only type of VM which have a Qemu stubdomain.
x86 PV and PVH domains, as well as ARM VMs typically don't use a
stubdomain.
Only VMs using HVM stubdomains can exploit the vulnerability. VMs using
PV stubdomains, or with emulators running in dom0 cannot exploit the
vulnerability.
MITIGATION
==========
Running only x86 PV or PVH VMs will avoid the vulnerability.
Reconfiguring x86 HVM guests to use a PV or no stubdom will also avoid
the vulnerability.
CREDITS
=======
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa334.patch Xen 4.13 - xen-unstable
xsa334-4.12.patch Xen 4.12
$ sha256sum xsa334*
80e7725a56c4244d860e9aebb56710a8165f7ffeae3fb67365cbc85b3b0518b3 xsa334.meta
323cd9d24b2e95643833865a9943172c56edd25dfd170e4741034d28dfd0d4bd xsa334.patch
85341ba6322ea6279c0851493ce61e822c8560850034f5f26cbcb26be85ca102 xsa334-4.12.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-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/eYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZV94H/jhwML6zObPz+zvjbwwAUoHsYiQ66CSUlxluqjN5
PXWpm56RzArptGIUakQyXKNI2Ht2fUn3Lu3w9JllujJRfmhbhiJJvI9Ar2QzOcri
+XylcK9rRspfmNUgXB629BTEcGUuo9/J+T+O4T544zfWUBncixyDq9/Q9SGAdz9c
kDZkL6UebpIFLtD6jrgYd4XAK9b1c6T7SmsGzq26m/zwGqJ1jol58kHl5GMXe7uX
rd9xZbERKIhaABbTQ10zY5IDIE4oplibSLOiJVSTz6KSyzD9by+M7oszqeIbIiRV
rY49lettdD4jfmzp5bbXQnf+9T31rG3AEHWaiOGdVcRFoq8=
=a23E
- -----END PGP SIGNATURE-----
- --------------------------------------------------------------------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2020-25595 / XSA-337
version 3
PCI passthrough code reading back hardware registers
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
Code paths in Xen's MSI handling have been identified which act on
unsanitized values read back from device hardware registers. While
devices strictly compliant with PCI specifications shouldn't be able to
affect these registers, experience shows that it's very common for
devices to have out-of-spec "backdoor" operations which can affect the
result of these reads.
IMPACT
======
A not fully trusted guest may be able to crash Xen, leading to a Denial
of Service (DoS) for the entire system. Privilege escalation and
information leaks cannot be excluded.
VULNERABLE SYSTEMS
==================
All versions of Xen supporting PCI passthrough are affected.
Only x86 systems are vulnerable. Arm systems are not vulnerable.
Only guests with passed through PCI devices may be able to leverage
the vulnerability.
Only systems passing through devices with out-of-spec ("backdoor")
functionality can cause issues. Experience shows that such out-of-spec
functionality is common; unless you have reason to believe that your
device does not have such functionality, it's better to assume that it
does.
REMINDER OF PCI PASSTHROUGH SUPPORT STATEMENT
=============================================
The security team wishes to reiterate our support statement for PCI
Device Passthrough (found in xen.git/SUPPORT.md):
"Because of hardware limitations (affecting any operating system or
hypervisor), it is generally not safe to use this feature to expose a
physical device to completely untrusted guests. However, this feature
can still confer significant security benefit when used to remove
drivers and backends from domain 0 (i.e., Driver Domains)."
The possibility of "backdoor" device functionality mentioned above is
one of the major reasons for this stance. We issue this XSA to help
maintain Driver Domains as a "defense-in-depth", and also on behalf of
those who may have done full security audits of their particular
hardware platform. It does not change our stance that passing through
PCI devices to untrusted guests is in general not safe.
MITIGATION
==========
Not passing through physical devices to untrusted guests will avoid
the vulnerability.
CREDITS
=======
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==========
Applying the appropriate pair of attached patches resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa337/xsa337-.patch Xen 4.14 - xen-unstable
xsa337/xsa337-4.13-.patch Xen 4.13
xsa337/xsa337-4.12-.patch Xen 4.10 - 4.12
$ sha256sum xsa337* xsa337*/*
f027d07fb307f5441ee9d19b6385e421bba745059667d181031b0bfd7047a15b xsa337.meta
98c48781dd46bf6ff6cc46246c6c9f2e2be6ec696c0e7918d4b82845588ce04e xsa337/xsa337-1.patch
9e8ae24222371379f2ea62e14fcc7f7282e01c356dff230c22c9ab1d2fb941e2 xsa337/xsa337-2.patch
a6744fdab01877e098f88dcd3bee10c3146aef66170a1422b3811cd09fc9faef xsa337/xsa337-4.12-1.patch
a091652f1a3c0bf851e35b61d338d53b4690fab828b3c30f354c28c377af2aee xsa337/xsa337-4.12-2.patch
fb27fd2508e017bf05131eb3d31bb8cc56c79690cbb7f1af76cb92fd568040a1 xsa337/xsa337-4.13-1.patch
a25bc70ad55716ce3a0d9435fa2b0a492420a0eabfb0e3f94cd27de10242d98b xsa337/xsa337-4.13-2.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.
HOWEVER, deployment of the mitigation is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List). Specifically, deployment on public cloud systems
is NOT permitted.
This is because removing of pass-through devices or their replacement by
emulated devices is a guest visible configuration change, which may lead
to re-discovery of the issue.
Deployment of this mitigation is permitted only AFTER the embargo ends.
AND: 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-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/ecMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZlcIIAKtn9RdA/CjIRcodtfxnnFPQu9SRtmHfLNQ2Vjmu
F1nIjjEklUNJSpGlEGjG1cq3oA/SZTm2jYXu2k4rcAyrl0bhaflSoL/N+Fmwo2Ym
898KA8gLdIckagxz5WKVv/vqc3x/h2IZgN4AUgt73buUOxEBFudqJKvnwtep5Z5R
60MDs+lp/5Mp6cXUukAWzPnmtJDWZ4s4QHXHNkKXTUpByZfmGJqqflL6yJDFHSxt
vvGpvElApkMP4Ks+rPoCrdG/ObbQvgwMgSJ//tnnWayfs1asOxrRbFlLAt4yVvdt
Y6Hi69hHB+ZWO36qy5dvjjKk0ftbrPAPDbDk27y/zuKXhko=
=TzZR
- -----END PGP SIGNATURE-----
- --------------------------------------------------------------------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2020-25601 / XSA-344
version 4
lack of preemption in evtchn_reset() / evtchn_destroy()
UPDATES IN VERSION 4
====================
Public release.
ISSUE DESCRIPTION
=================
In particular the FIFO event channel model allows guests to have a large
number of event channels active at a time. Closing all of these when
resetting all event channels or when cleaning up after the guest may
take extended periods of time. So far there was no arrangement for
preemption at suitable intervals, allowing a CPU to spend an almost
unbounded amount of time in the processing of these operations.
IMPACT
======
Malicious or buggy guest kernels can mount a Denial of Service (DoS)
attack affecting the entire system.
VULNERABLE SYSTEMS
==================
All Xen versions are vulnerable in principle. Whether versions 4.3
and older are vulnerable depends on underlying hardware characteristics.
MITIGATION
==========
The problem can be avoided by reducing the number of event channels
available to all guests to a suitably low limit. For example, setting
"max_event_channels=256" in the xl domain configurations may be low
enough for all hardware Xen is able to run on.
CREDITS
=======
This issue was discovered by Jan Beulich of SUSE.
RESOLUTION
==========
Applying the appropriate set of attached patches resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa344/xsa344-.patch Xen 4.14 - xen-unstable
xsa344/xsa344-4.13-.patch Xen 4.13
xsa344/xsa344-4.12-.patch Xen 4.12
xsa344/xsa344-4.11-.patch Xen 4.11
xsa344/xsa344-4.10-.patch Xen 4.10
$ sha256sum xsa344* xsa344*/*
74ae97a618a3680920bed131e69656d5a7c039efbbec99b55b99af772e3e87df xsa344.meta
5f9dbdc48bed502d614a76e5819afa41a72cec603c5a2c9491d73873a991a5ed xsa344/xsa344-1.patch
381ca5c51bc120bfd5c742be3988f570abb870c4b75c8a48cf49ae4fa1046d73 xsa344/xsa344-2.patch
b52e4ecd6db8c3c6ebc0ab6facbd0f4fa0859657d13491819c3279fe439f66ec xsa344/xsa344-4.10-1.patch
53ca9c954fd73344968f40689b0d0ea583bd19ece72166fd2d4eaa125b82f26f xsa344/xsa344-4.10-2.patch
7abea30b406b0a572f7cd76bd9768d12262344a8e255ddd29d2ad893724638a0 xsa344/xsa344-4.11-1.patch
f2b39146ac410154043efd09880277e4e821a1dd47a0bd3000545e5568253b97 xsa344/xsa344-4.11-2.patch
a654c99f5d1c25d9d12ba267d2db10b0a1e0da337ce334fb5aafa6b2061ebc3c xsa344/xsa344-4.12-1.patch
6af4e05f8536b11a3dc4c70620b8ed973ecf09efd4c64eb500f6363d5f0402e7 xsa344/xsa344-4.12-2.patch
9b81c7cf3cd33f9d43c43222a0434a8d4e0acff74f339a6842f16bfa2f304cb5 xsa344/xsa344-4.13-1.patch
80a41b7e08cdb54a28dfc82630a0d8d89fc25e381bc4505ed41017a760addf09 xsa344/xsa344-4.13-2.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-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/egMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ114H/2QrxpADKwxDb2+aL8fhf46AJYwgxDa8SoI18INd
IVeHs8Lq4CQsfSFxBbXOWDGo82bUg43kwcdZ3ToSaX2JSC4R3r0us6tSdaRIqpNj
sQo56ozFXH63v4zTlB8gF58skm2n+CZQ5nKccnTUsN7KuqfPWm/2LfBnqnHYkYQ9
CVHBG5YXMnrHbASo+HglGqjgu6GyEsLoJpSQEj6oYF/UW86OYeAwZ2TFAFVZ/T04
XtxnH7aYCSMOeQRPU6BnCdoVKg/wn4ilSKyqYAin8uNFf7af3OSSCR4FTYkLX+VG
WYJnc27SUAb28+l9f65r8cwzs2+O5SlqhpqyS6xcM3A1248=
=UYAk
- -----END PGP SIGNATURE-----
- --------------------------------------------------------------------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2020-25597 / XSA-338
version 4
once valid event channels may not turn invalid
UPDATES IN VERSION 4
====================
Public release.
ISSUE DESCRIPTION
=================
Logic in the handling of event channel operations in Xen assumes that an
event channel, once valid, will not become invalid over the life time of
a guest. However, operations like the resetting of all event channels
may involve decreasing one of the bounds checked when determining
validity. This may lead to bug checks triggering, crashing the host.
IMPACT
======
An unprivileged guest may be able to crash Xen, leading to a Denial of
Service (DoS) for the entire system.
VULNERABLE SYSTEMS
==================
All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and
earlier are not vulnerable.
Only systems with untrusted guests permitted to create more than the
default number of event channels are vulnerable. This number depends
on the architecture and type of guest. For 32-bit x86 PV guests, this
is 1023; for 64-bit x86 PV guests, and for all ARM guests, this number
is 4095. Systems where untrusted guests are limited to fewer than
this number are not vulnerable.
Note that xl and libxl limit max_event_channels to 1023 by default, so
systems using exlusively xl, libvirt+libxl, or their own toolstack
based on libxl, and not explicitly setting max_event_channels, are not
vulnerable.
MITIGATION
==========
The problem can be avoided by reducing the number of event channels
available to the guest to no more than 1023. For example, setting
"max_event_channels=1023" in the xl domain configuration, or deleting
any existing setting (since 1023 is the default for xl/libxl).
For ARM systems, any limit no more than 4095 is safe.
For 64-bit x86 PV guests, any limit no more than 4095 is likewise safe
if the host configuration prevents the guest administrator from
substituting and running a 32-bit kernel (and thereby putting the
guest into 32-bit PV mode).
CREDITS
=======
This issue was discovered by Jan Beulich of SUSE.
RESOLUTION
==========
Applying the attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa338.patch Xen 4.10 - xen-unstable
$ sha256sum xsa338*
56c322b89a96db6be40cf15fdb9303e24ff692aa5a6274b2d7718bfc05acf309 xsa338.meta
7345eac1cbad23b082523e9cbd0331f8a9f16c6e459fb2a686606253f5514c9b xsa338.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of the *patch* 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).
And: deployment of the event channel limit reduction mitigation is NOT
permitted (except where all the affected systems and VMs are
administered and used only by organisations which are members of the
Xen Project Security Issues Predisclosure List). Specifically,
deployment on public cloud systems is NOT permitted.
This is because such a change can be visible to the guest, so it would
leak the preconditions for the vulnerability and maybe lead to
rediscovery.
Deployment of this, or similar mitigations, is permitted only AFTER
the embargo ends.
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-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/ecMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZlToIAMY5ZvKvqVmLzy/UEZrq3lgf8DA2+n9BFnec+XlI
gDz7ssJNgwnkrrt7BF/XGeaAwly/pRACLapYd7hP8KNM3qPz/DG++S2FS/O44AkQ
7yjYRoEJRxFK1RnG3UeVw9S8aDrUrsTIoh7WFsX7rvEw6zg6o4kii4YSjvUSV5ug
uYh0p3i56CWqjlKd94ZQlESfacrl1wZd/AemdDbAzj/FMF0ZyQujQ3PHBAcLjbPR
jzE/EJRjpEPe9kMWKDWX06VlWja6cUDFIlaqZM9nlgiyI643y2iRSuilQbansMPA
zG6SXQOqzSWc+OQ3wUaf972mjNfiKiBSFo/hB95HdS5I2Pk=
=EzUa
- -----END PGP SIGNATURE-----
- --------------------------------------------------------------------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2020-25600 / XSA-342
version 3
out of bounds event channels available to 32-bit x86 domains
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
The so called 2-level event channel model imposes different limits on
the number of usable event channels for 32-bit x86 domains vs 64-bit
or Arm (either bitness) ones. 32-bit x86 domains can use only 1023
channels, due to limited space in their shared (between guest and Xen)
information structure, whereas all other domains can use up to 4095 in
this model. The recording of the respective limit during domain
initialization, however, has occurred at a time where domains are still
deemed to be 64-bit ones, prior to actually honoring respective domain
properties. At the point domains get recognized as 32-bit ones, the
limit didn't get updated accordingly.
Due to this misbehavior in Xen, 32-bit domains (including Domain 0)
servicing other domains may observe event channel allocations to succeed
when they should really fail. Subsequent use of such event channels
would then possibly lead to corruption of other parts of the shared
info structure.
IMPACT
======
An unprivileged guest may cause another domain, in particular Domain 0,
to misbehave. This may lead to a Denial of Service (DoS) for the entire
system.
VULNERABLE SYSTEMS
==================
All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and
earlier are not vulnerable.
Only x86 32-bit domains servicing other domains are vulnerable.
Arm systems as well as x86 64-bit domains are not vulnerable.
MITIGATION
==========
There is no known workaround for x86 32-bit Domain 0.
The problem can be avoided by reducing the number of event channels
available to 32-bit x86 guests to no more than 1023. For example,
setting "max_event_channels=1023" in the xl domain configuration, or
deleting any existing setting (since 1023 is the default for xl/libxl).
CREDITS
=======
This issue was discovered by Julien Grall of Amazon.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa342.patch Xen 4.14 - xen-unstable
xsa342-4.13.patch Xen 4.10 - 4.13
$ sha256sum xsa342*
8e85719f2783d5d0fc3da7a6aefb6c83717c7aa195d027b6aa52ff3a31c489aa xsa342.meta
060caee3fb5971fca0f2fbdef622c52d9bc6e0ed9efad33de5b6b504651c2112 xsa342.patch
ef34839148d33b8d9cb03d56ffafdcdcbe9641a737211a50343d019132b169dd xsa342-4.13.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-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/ecMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ+RAIAKhulm14Ze1LmVTCGKcTJ525DARSmzGdki4iX3ow
qvQkV1B8TacFnuzZp1VfRnm5vRGBY/uXaFORw21Z/rWSRQ3xjgcazTsG0jhNQ8QG
onH1JaxE26BfYu12oTSEKyTWWu1XSdrFTxWp07p79+qHvKGY6GtGRWGhkI6YNgkD
X2TwRtt6GF6wRTq3PCc+7CGnn5jp7FRyJpI/2uiNZC6cL6lGUYNl9wgujSnefqQO
1sAZSc3DmvIuvFl4XWUeU7mH/6xL93sDN4vIrVllvcI9nEswqFwju6+SP76Pnkoh
KBSYNk79QNlbBdXJwNmYxqp4sYpH/JYEm6+u2Zw1hxCMgM4=
=EebG
- -----END PGP SIGNATURE-----
- --------------------------------------------------------------------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2020-25604 / XSA-336
version 3
race when migrating timers between x86 HVM vCPU-s
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
When migrating timers of x86 HVM guests between its vCPU-s, the locking
model used allows for a second vCPU of the same guest also operating on
the timers to release a lock that it didn't acquire.
IMPACT
======
The most likely effect of the issue is a hang or crash of the
hypervisor, i.e. a Denial of Service (DoS).
VULNERABLE SYSTEMS
==================
All versions of Xen are affected.
Only x86 systems are vulnerable. Arm systems are not vulnerable.
Only x86 HVM guests can leverage the vulnerability. x86 PV and PVH
cannot leverage the vulnerability.
Only guests with more than one vCPU can exploit the vulnerability.
MITIGATION
==========
Running only PV and PVH guests will avoid the vulnerability.
CREDITS
=======
This issue was discovered by Igor Druzhinin of Citrix.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa336.patch Xen 4.12 - xen-unstable
xsa336-4.11.patch Xen 4.10 - 4.11
$ sha256sum xsa336*
6cb13a54c2b0fcb6948a1c4045095da4e43aad262a1dd8993ea2a3bd90d4c72d xsa336.meta
ecb59876fb92cfe0916ed5f3227a30efe038224c1f6ec36bc3706c4e2214552c xsa336.patch
c0c7983bfd70eb54277af9fddfcc3cc95bbd745d92d9ffb71d5b32281c437510 xsa336-4.11.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-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/eYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZe28H/3oTZLe4eVhykU7a+BbN7ENJ2WMYsj0VM5wUiQyK
ZrY3CnbO0ne6h0BeAgSNG1XRP9QvwJLOIm6gZkqoNCWyJK2IbCO/mlF4czBlpUBR
FtM2wJz4FLzkiYMozk8TOZk6pCW6gaqxNiYr2L/3ijh2PQCMwnte/u+T3mZAAWxB
nJbVnwux26nvRY/5XBZ7cZ/Qxi1DKed2cyf2A9oZ/AmGIMBT2r6SZ+arf+d4jHRG
yQok+7gdXr1lOL/pPZZWepHtbPJMrrYxQZN/zKGt20c9ksBLiOyyQxTO4tegLx7N
PxRgzy+DgY+xqYFA68xpM6jJxfWYmHpjAtbYtQoPvyPsIag=
=0Kkw
- -----END PGP SIGNATURE-----
- --------------------------------------------------------------------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2020-25599 / XSA-343
version 4
races with evtchn_reset()
UPDATES IN VERSION 4
====================
Fix build of backports of patch 3. Adjust affect versions.
Public release.
ISSUE DESCRIPTION
=================
Uses of EVTCHNOP_reset (potentially by a guest on itself) or
XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the
violation of various internal assumptions. This may lead to out of
bounds memory accesses or triggering of bug checks.
IMPACT
======
In particular x86 PV guests may be able to elevate their privilege to
that of the host. Host and guest crashes are also possible, leading to
a Denial of Service (DoS). Information leaks cannot be ruled out.
VULNERABLE SYSTEMS
==================
All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and
earlier are not vulnerable.
MITIGATION
==========
There is no known mitigation.
CREDITS
=======
Different aspects of this issue were discovered by Julien Grall of
Amazon and by Jan Beulich of SUSE.
RESOLUTION
==========
Applying the appropriate set of attached patches resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa343/xsa343-.patch Xen 4.13 - xen-unstable
xsa343/xsa343-4.12-.patch Xen 4.12
xsa343/xsa343-4.11-.patch Xen 4.11
xsa343/xsa343-4.10-.patch Xen 4.10
$ sha256sum xsa343* xsa343*/*
097d5fa32e22fc7a18fddd757f950699e823202bbae67245eece783d6d06f4eb xsa343.meta
d714a542bae9d96b6a061c5a8f754549d699dcfb7bf2a766b721f6bbe33aefd2 xsa343/xsa343-1.patch
657c44c8ea13523d2e59776531237bbc20166c9b7c3960e0e9ad381fce927344 xsa343/xsa343-2.patch
2b275e3fa559167c1b59e6fd4a20bc4d1df9d9cb0cbd0050a3db9c3d0299b233 xsa343/xsa343-3.patch
9aec124e2afcba57f8adaf7374ecebffc4a8ed1913512a7456f87761bb115f68 xsa343/xsa343-4.10-1.patch
54d9ce9acdb8dcc6aa81928037afbb081a6cd579127aa225833767e285e30ea2 xsa343/xsa343-4.10-2.patch
3801300cddd8d138c800dc45eeff111e313eb40cea3aa94e2e045ac8956ab9d3 xsa343/xsa343-4.10-3.patch
7abbec828f77c427a53182db820fc19bdf34e37882fc6ae51351ed6027c56da1 xsa343/xsa343-4.11-1.patch
5c90a53333e9c81ce938deddfc690f474d61e083d2a43b859d3227100f793aff xsa343/xsa343-4.11-2.patch
0e12cfe8e505b9685912c61a740b98084d62e4ba0670d51a47345739f463a039 xsa343/xsa343-4.11-3.patch
f3462b4e672f69a9fa951b1c04a50d754c64d18aadf444ef248587b3ac7f635a xsa343/xsa343-4.12-1.patch
d99cbbc3792755c4998b73460bbeaef5612a8942f98adcaea0762950e5a07c2a xsa343/xsa343-4.12-2.patch
cf23d3b61d4f07efc7057035c45e53e32a0b0f8fc3b9bc6c05f0f5bc71204914 xsa343/xsa343-4.12-3.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-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/k0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZQvkIAKG74lMZpma+6A2V3eZAWUFBWeUOXwgD9+UorfvT
01zdpXBcVh5alrZ+ZSzmuAa/3tREUOnJHIHJD8fBpg+Yywy3dMduuxvv6RWzuQGj
rnf0X4LNklQYzOQXsYO5HkF6hxkPyZsgJPnOO9Zwb8zB8nqpSQkq9NMJ2Ochgfmm
+aZqWe7YXCNReBfMUzqyEpSwK2tNPNNE29IerxwEooqwUV5i9mHX3lYh1UYjwush
7OrvZzTLl8csjWIenxNuXX+STxUGdS81UDAbxEENmqSLoG1djRrUkAkCu5pNphxK
dkgAk9k8wAs2fc1BOYabCNeatZEUJ11n0dxJ7nn+AsnQ5YY=
=rqkV
- -----END PGP SIGNATURE-----
- --------------------------------------------------------------------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2020-25596 / XSA-339
version 3
x86 pv guest kernel DoS via SYSENTER
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
The SYSENTER instruction leaves various state sanitization activities
to software. One of Xen's sanitization paths injects a #GP fault, and
incorrectly delivers it twice to the guest.
This causes the guest kernel to observe a kernel-privilege #GP fault
(typically fatal) rather than a user-privilege #GP fault (usually
converted into SIGSEGV/etc).
IMPACT
======
Malicious or buggy userspace can crash the guest kernel, resulting in
a VM Denial of Service.
VULNERABLE SYSTEMS
==================
All versions of Xen from 3.2 onwards are vulnerable.
Only x86 systems are vulnerable. ARM platforms are not vulnerable.
Only x86 systems which support the SYSENTER instruction in 64bit mode
are vulnerable. This is believed to be Intel, Centaur and Shanghai
CPUs. AMD and Hygon CPUs are not believed to be vulnerable.
Only x86 PV guests can exploit the vulnerability. x86 PVH / HVM
guests cannot exploit the vulnerability.
MITIGATION
==========
Running only x86 PVH / HVM guests avoids the vulnerability.
CREDITS
=======
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==========
Applying the attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa339.patch Xen 4.10 - xen-unstable
$ sha256sum xsa339*
5cece13878cc40b32bc5753c0ef64f989f9b1c7f9549d62ea4fcd06e9620de9e xsa339.meta
b6ffa7671d905aa12498ad64915be3b7cba74ce1c5bf6bce18b1f106ebf6d715 xsa339.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-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/ecMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZgEUH/1/5DUgXRKzwvYuERdBintUdCUaezYpjY0VEJ/v5
nPXEZDDkBFZZxtWmLg6gqMsJg4O6npTcZ6Z3ZpP8xTiRexr0fHHRY5FHqOCW0aS+
c0WYQzSvfDW1L/m9fjwsbFKKRCmrwE24L/Jc7GZJlpps22f1mZpn3cwsjidlofHi
WxqpdAPNDLsPDF3+iwt5a8gL3onyeo03MaBhO29UAJIKCo4hxiKu5/e3upXFBdN2
Z4Pyr79E51SiCGxZ/A1NTil9+FyYkP1DgBQdJ6pVrxMnZUhdcjbGLEbrUNaTfgox
yORU8rE3XS2ZajRpW3D2CIGnKJj3zGWaQqx+FufX1m6Y8qE=
=tkQp
- -----END PGP SIGNATURE-----
- --------------------------------------------------------------------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2020-25602 / XSA-333
version 3
x86 pv: Crash when handling guest access to MSR_MISC_ENABLE
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
When a guest accesses certain Model Specific Registers, Xen first reads
the value from hardware to use as the basis for auditing the guest
access.
For the MISC_ENABLE MSR, which is an Intel specific MSR, this MSR read
is performed without error handling for a #GP fault, which is the
consequence of trying to read this MSR on non-Intel hardware.
IMPACT
======
A buggy or malicious PV guest administrator can crash Xen, resulting in
a host Denial of Service.
VULNERABLE SYSTEMS
==================
Only x86 systems are vulnerable. ARM systems are not vulnerable.
Only Xen versions 4.11 and onwards are vulnerable. 4.10 and earlier are
not vulnerable.
Only x86 systems which do not implement the MISC_ENABLE MSR (0x1a0) are
vulnerable. AMD and Hygon systems do not implement this MSR and are
vulnerable. Intel systems do implement this MSR and are not vulnerable.
Other manufacturers have not been checked.
Only x86 PV guests can exploit the vulnerability. x86 HVM/PVH guests
cannot exploit the vulnerability.
MITIGATION
==========
Running only HVM/PVH guests avoids the vulnerability.
CREDITS
=======
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==========
Applying the attached patch resolves this issue.
Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball. Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.
xsa333.patch Xen 4.11 - xen-unstable
$ sha256sum xsa333*
3f3d974ede9fe80f4eb63640dce058cf9e2073cd79e4c085c944f3ca5e454e26 xsa333.meta
8edec914fbdf036fba8cb54a75d3a9b025fac936e0af35512954a2dc2b12a26f xsa333.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-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl9p/eUMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZu5EH/RAaLJocX5UJfEZ4QT2osvnc1aaZjBXNz4JN1HDj
46pGxBOv1kEDxBu/lqbbXEY2aLeBLder2nj0OHCYgDkPCh4fqaciBqCEO97COqzo
dFvN17dZ0pjyBUoSXs8mVPWjMblBjf6/Mt+/gh8speJQ32V3lHz6xYc9Nu0CVoL5
+RiaRVPGYOVndF5A0XK6UIiiMAOcVgPHpg485QFT2EIVPlKVu/jDrrsYep/9OrmP
bamEjKcYoFBBsMlpUNAtUK0QZGnSAe2vVtbUNeHgY5T5BDuJzLZXdMDGmBDXK2vV
0PNMOoIeFev6Pq7yuvvTqI0PKEBmO825hkbZ5sEva/7pZ60=
=zf3E
- -----END PGP SIGNATURE-----
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
https://www.auscert.org.au/bulletins/
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQIVAwUBX2rUi+NLKJtyKPYoAQgzXw//fnu91qpV2RGJ5+zlWiVlJs6TQWSUd/8D
vfqn0qRbHK0Ou5OeSNZlyh1kB7UvXR4t0cS2wMEnOaviiNvVQrmh/SKK3lm/Gbqm
PZ1NvpklHorUAwPxC2Yr9q6gaMny+mPhTchEzeJ1wvtBZKy014qNGyNRpyHy87Rs
SXmyawyk4fbrhC682D0tOr0HGUlblbIoZzFAt0w0sl4VGFTimmq22o3VfZ8OeGLl
dSjS3oj+4l6HR2myMzl5wBMVsIofWzUIBgLINSfWZ73xoZC432dYc+qKwo8tTKIo
5l4OyMq22dPRo/uGrQUZn6G3T5oRcOHkmynFMTXc8ui+1lL8UMg4g/7+VE/HQudH
aK8eITO8dtAM+Fv7PssC35Hrb32exHzRFoYDP5FxREbhMs57RJfq9fzx3Ej/SX7z
xJAJKI7kAtvR3marpixrN+AnSt4XVCurZaO+li+P0P1PvwegJizbnmHp3I/rDRWD
24kf6ECpVEo/NCGBl77sPxNMxqWfQK9sgcflRxD2qPGs/YWiiAzW4VZtRYs2Me7+
bS+Uhmu0bNidwabwrWE/bryCqWZ26nFD484eOe2cKNxWA7hLK/Lnxs+BC5rKmReK
9QRNMMm1TNAkPD8x/0tXWZ+0k7+ULK7JlhdH2RBsITLNoe2/15eW9vzYRc3sOz4m
laVCpnQAk3g=
=KHth
-----END PGP SIGNATURE-----