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

===========================================================================
             AUSCERT External Security Bulletin Redistribution

                               ESB-2016.2814
                Multiple vulnerabilities identified in Xen
                             28 November 2016

===========================================================================

        AusCERT Security Bulletin Summary
        ---------------------------------

Product:           Xen
Publisher:         Xen
Operating System:  Xen
                   UNIX variants (UNIX, Linux, OSX)
Impact/Access:     Execute Arbitrary Code/Commands -- Existing Account
                   Increased Privileges            -- Existing Account
                   Denial of Service               -- Existing Account
                   Access Confidential Data        -- Existing Account
Resolution:        Patch/Upgrade
CVE Names:         CVE-2016-9384 CVE-2016-9383 CVE-2016-9381
                   CVE-2016-9380 CVE-2016-9379 CVE-2016-9378
                   CVE-2016-9377  

Original Bulletin: 
   https://xenbits.xen.org/xsa/advisory-194.html
   https://xenbits.xen.org/xsa/advisory-195.html
   https://xenbits.xen.org/xsa/advisory-196.html
   https://xenbits.xen.org/xsa/advisory-197.html
   https://xenbits.xen.org/xsa/advisory-198.html

Comment: This bulletin contains five (5) Xen security advisories.

- --------------------------BEGIN INCLUDED TEXT--------------------

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2016-9384 / XSA-194
                              version 3

           guest 32-bit ELF symbol table load leaking host data

UPDATES IN VERSION 3
====================

Public release.

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

Along with their main kernel binary, unprivileged guests may arrange
to have their Xen environment load (kernel) symbol tables for their
use.  The ELF image metadata created for this purpose has a few unused
bytes when the symbol table binary is in 32-bit ELF format.  These
unused bytes were not properly cleared during symbol table loading.

IMPACT
======

A malicious unprivileged guest may be able to obtain sensitive
information from the host.

The information leak is small and not under the control of the guest,
so effectively exploiting this vulnerability is probably difficult.

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

Only Xen version 4.7 is affected.  Xen versions 4.6 and earlier are not
affected.

The vulnerability is not exposed to x86 HVM guests, unless the host
toolstack has configured to load the guest with a non-default loader,
rather than hvmloader.

MITIGATION
==========

There is no known mitigation.

CREDITS
=======

This issue was discovered by Roger Pau Monné of Citrix.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa194.patch           xen-unstable, Xen 4.7.x

$ sha256sum xsa194*
4dad65417d9ff3c86e763d3c88cf8de79b58a9981d531f641ae0dd0dcedce911  xsa194.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

iQEcBAEBAgAGBQJYNDLYAAoJEIP+FMlX6CvZqAoH/39GSWwDpYnflz3TcFyQUViM
j36XzzStWya71ewaXiguUbTHHg6mK47pK4EA/3zFwerczz/5yQzhlToitPkP/8WE
5Qbg9Wyg4STylzeKaiTvLzqUK6XSiJ4oKZwLsnU7tFPLcb6FBMm9t3bzg9NECaft
/6zYj1SVCvoLJB/gtgbwrz2MCjVZQZ9Q2+mpirvu0ePQRD73M0cwfj1ncqjUkFd9
ZNdk14gmxOk1/wWAm/oD1QKUWmjpzByT5dbGcMV3OxGs1V2Px+o4c1u1t/agldr0
wC2LvCK9IED9JcBaH/M85TTAGR7GqfU8l9x3ep97GkrUpquX4OGFt7na28M1YUQ=
=Gc8O
- -----END PGP SIGNATURE-----
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2016-9383 / XSA-195
                              version 3

           x86 64-bit bit test instruction emulation broken

UPDATES IN VERSION 3
====================

Public release.

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

The x86 instructions BT, BTC, BTR, and BTS, when used with a
destination memory operand and a source register rather than an
immediate operand, access a memory location offset from that specified
by the memory operand as specified by the high bits of the register
source.

When Xen needs to emulate such an instruction, to efficiently handle
the emulation, the memory address and register operand are
recalculated internally to Xen.  In this process, the high bits of an
intermediate expression were discarded, leading to both the memory
location and the register operand being wrong.

The wrong memory location would have only a guest local effect (either
access to an unintended location, or a fault delivered to the guest),
whereas the wrong register value could lead to either a host crash or
an unintended host memory access.

IMPACT
======

A malicious guest can modify arbitrary memory, allowing for arbitrary
code execution (and therefore privilege escalation affecting the whole
host), a crash of the host (leading to a DoS), or information leaks.

The vulnerability is sometimes exploitable by unprivileged guest user
processes.

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

All Xen versions are affected.

The vulnerability is only exposed to x86 guests running in 64-bit mode.

On Xen 4.6 and earlier the vulnerability is exposed to all guest user
processes, including unprivileged processes, in such guests.

On Xen 4.7 and later, the vulnerability is exposed only to guest user
processes granted a degree of privilege (such as direct hardware
access) by the guest administrator; or, to all user processes when the
when the VM has been explicitly configured with a non-default cpu
vendor string (in xm/xl, this would be done with a `cpuid=' domain
config option).

The vulnerability is not exposed to 32-bit PV guests.

ARM systems are not vulnerable.

MITIGATION
==========

There is no known mitigation.

CREDITS
=======

This issue was discovered by George Dunlap of Citrix, using American
Fuzzy Lop v2.35b.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa195.patch       xen-unstable, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x

$ sha256sum xsa195*
6ab5f13b81e3bbf6096020f4c3beeffaff67a075cab67e033ba27d199b41cec1  xsa195.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

iQEcBAEBAgAGBQJYNDL4AAoJEIP+FMlX6CvZnzYH/RtmqS8kpqLKShvrQx5Ueh+M
LaHBWJiU0z1m9FaF9RvEgfvWpUCcD/qyC4rLHmkwhkyS6aIToh2XVXzQyebIqw/7
CCDXaY8TkYlLPYRdNseX5X5blpu1EnqW5yQMJz6QkgDK+Qu4F1jDimSd5JffrFkJ
WkpWwsoppNHwYyaENq59lg7R1WxNq0uSLxMPTnk/RpMmizKyU8gK7RrQWHJNoy6n
l3vSTKx9sCDo+AgMQgbDMdpvv1l1It+QcRXXBrBp7qAdz+0H7VRkUFOnBUFMQQo3
OjmjStKxnE9E7Uh6+373xj2Z6Nts+wkD72vRHHg/1KTZ5FN5XnS2CvPDNuGZD50=
=AtOu
- -----END PGP SIGNATURE-----
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

     Xen Security Advisory CVE-2016-9377,CVE-2016-9378 / XSA-196
                              version 3

             x86 software interrupt injection mis-handled

UPDATES IN VERSION 3
====================

Public release.

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

There are two closely-related bugs.

When Xen emulates instructions which generate software interrupts it
needs to perform a privilege check involving an IDT lookup.  This
check is sometimes erroneously conducted as if the IDT had the format
for a 32-bit guest, when in fact it is in the 64-bit format.  Xen will
then read the wrong part of the IDT and interpret it in an unintended
manner.  (CVE-2016-9377)

When Xen emulates instructions which generate software interrupts, and
chooses to deliver the software interrupt, it may try to use the
method intended for injecting exceptions.  This is incorrect, and
results in a guest crash.  (CVE-2016-9378)

These instructions are not ususally handled by the emulator.
Exploiting the bug requires ability to force use of the emulator.

IMPACT
======

An unprivileged guest user program may be able to crash the guest.

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

Xen versions 4.5 and newer are vulnerable.  Older versions are not
vulnerable.

The vulnerability is only exposed on AMD hardware lacking the NRip
feature.  AMD hardware with the NRip feature, and all Intel hardware,
is not vulnerable.

Xen prints information about CPU features on boot.  If you see this:
    (XEN) SVM: Supported advanced features:
    ...
    (XEN)  - Next-RIP Saved on #VMEXIT
then you are not vulnerable because you have an AMD CPU with NRip.
If you see this:
    (XEN) VMX: Supported advanced features:
then you are not vulnerable because you have an Intel CPU.

The vulnerability is only exposed on HVM guests.

ARM systems are NOT vulnerable.

MITIGATION
==========

Running only PV guests will avoid this issue.

CREDITS
=======

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==========

Applying the attached patches resolves this issue.

xsa196-000*.patch      xen-unstable, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x

$ sha256sum xsa196*
c4122280f3786416231ae5f0660123446d29e9ac5cd3ffb92784ed36edeec8b7  xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject.patch
25671c44c746d4d0e8f7e2b109926c013b440e0bf225156282052ec38536e347  xsa196-0002-x86-svm-Fix-injection-of-software-interrupts.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

iQEcBAEBAgAGBQJYNDMVAAoJEIP+FMlX6CvZZ7MH/36KnwbAxmRHtUDIpQF/Syoh
Lc8s6gNV1oOzcCpFgz+gSyIOMzp7KWieKQiVX1HbI0lnLYK/sRa77VNV/Y9bUt+Y
y9b9QOZRDHoO92dZ4Ym/hzdtaNkdOQX/JAfy+E5pCGuqPtH/Jy5NuwVL8W7V8PNM
QTHmvbgB4/Y2U6QqWpIP+S7oC0A9iuIf9eekd6ZTpqTadPFylTe2WX22mns1TEtN
3Z0NX737AjQLyUVnUoJ32sITCBk6tGutvvEmOc2Y+4eMrUvKSoafVy+5IZcTGwLp
3ke5sDNN1tOpzmqbXgWXBsVkpjWf2i0NW0dl5jh8/tN5FtrTuByd193dJGSKzEE=
=IE45
- -----END PGP SIGNATURE-----
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2016-9381 / XSA-197
                              version 3

             qemu incautious about shared ring processing

UPDATES IN VERSION 3
====================

Added email header syntax to patches, for e.g. git-am.

Public release.

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

The compiler can emit optimizations in qemu which can lead to double
fetch vulnerabilities.  Specifically data on the rings shared between
qemu and the hypervisor (which the guest under control can obtain
mappings of) can be fetched twice (during which time the guest can
alter the contents) possibly leading to arbitrary code execution in
qemu.

IMPACT
======

Malicious administrators can exploit this vulnerability to take over
the qemu process, elevating its privilege to that of the qemu process.

In a system not using a device model stub domain (or other techniques
for deprivileging qemu), malicious guest administrators can thus
elevate their privilege to that of the host.

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

All Xen versions with all flavors of qemu are affected.

Only x86 HVM guests expose the vulnerability.  x86 PV guests do not
expose the vulnerability.

ARM systems are not vulnerable.

MITIGATION
==========

Running only PV guests will avoid the vulnerability.

Enabling stubdomains will mitigate this issue, by reducing the
escalation to only those privileges accorded to the service domain.
In a usual configuration, a service domain has only the privilege of
the guest, so this eliminates the vulnerability.

The vulnerability can be avoided if the guest kernel is controlled by
the host rather than guest administrator, provided that further steps
are taken to prevent the guest administrator from loading code into
the kernel (e.g. by disabling loadable modules etc) or from using
other mechanisms which allow them to run code at kernel privilege.

CREDITS
=======

This issue was discovered by yanghongke of Huawei Security Test Team.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa197-qemuu.patch         qemu-upstream    xen-unstable, Xen 4.7.x
xsa197-qemut.patch         qemu-traditional xen-unstable, Xen 4.7.x, Xen 4.6.x
xsa197-4.6-qemuu.patch     qemu-upstream    Xen 4.6.x
xsa197-4.5-qemuu.patch     qemu-upstream    Xen 4.5.x
xsa197-4.5-qemut.patch     qemu-traditional Xen 4.5.x, Xen 4.4.x
xsa197-4.4-qemuu.patch     qemu-upstream    Xen 4.4.x

$ sha256sum xsa197*
a7d63958e3d3afc21c0585ec4690886a3191f01127583b4a29766c45fe4dd611  xsa197-4.4-qemuu.patch
56d037b3eaa0c3f5a7c474ad5087d8a41c2769d0d8b39c8f64699215a33e17a6  xsa197-4.5-qemut.patch
902836f0e5c6c46193c06f7c133a3bdd59f902ee490b962857640a6cd73e4be7  xsa197-4.5-qemuu.patch
20a418606f5536ac4fb009f21548a28b1b32dfb08fc97a259c40240d37a2abe8  xsa197-4.6-qemuu.patch
266996b2b5ac65ded76af63b3d57d4972ab95522b517e7bc9c5ff554d8c2d5e0  xsa197-qemut.patch
cd08b149c97b3f94dcda14b1f280dbb92911d93ffcd5dbcf5ee5ab2bebdc7878  xsa197-qemuu.patch
$

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

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

HOWEVER deployment of the stubdomain mitigation described above 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 in that case the configuration change may be visible
to the guest which could lead to the rediscovery of the vulnerability.

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

iQEcBAEBAgAGBQJYNDNLAAoJEIP+FMlX6CvZTvUIALi45XVEJv4ZqNsB1kX3mXIF
5ocmSFCrSDDIcKEg2xQ49PKwqE/ZwMLhKuX0dFi/inidqx7FynYknziaR3svIeir
ALTDP6Emsk/OB7T4epjGnuFW05RTfkQmwzEyY/XCAJVrJlkzKGh3WYVtwk+/PELT
3ab9dMEcziaUM+Ax3phJ4PHi315If2rLS4gNfqGO5jv/gnMyXk4DHQ8QZUHIGs4F
8tA/ATPaZxNK8OIwGEIz32PlLxwWHsQQz6JEAtvNwGDTNMDwlx3RzHSvjJSLOIKB
Aap6qw4c9olK172LQbvBqvP09Eupi3YSevx3AD0gmqKVwj8ql/lNUSNBf9CSfPc=
=SBVo
- -----END PGP SIGNATURE-----
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

     Xen Security Advisory CVE-2016-9379,CVE-2016-9380 / XSA-198
                              version 3

             delimiter injection vulnerabilities in pygrub

UPDATES IN VERSION 3
====================

Public release.

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

pygrub, the boot loader emulator, fails to quote (or sanity check) its
results when reporting them to its caller.

pygrub supports a number of output formats.  When the S-expression
output format is requested, putting string quotes and S-expressions in
the bootloader configuration file can produce incorrect output.
(CVE-2016-9379)

When the nul-delimited output format is requested, nul bytes in the
bootloader configuration file can produce an ambiguous or confusing
output file, which is interpreted by libxl in a vulnerable way.
(CVE-2016-9380)

The existing bootloader config interpreters all read input in a
line-based way from their bootloaders, and none of them support any
kind of escaping.  So the newline-delimited output format is safe.

The attacker can use this to cause the toolstack to treat any file
accessible to the toolstack as if it were the guest's initial ramdisk
file.  The file contents are provided to the guest kernel; also,
normally, these files are deleted by the toolstack as the guest starts
to boot; alternatively they may be deleted later.

IMPACT
======

A malicious guest administrator can obtain the contents of sensitive
host files (an information leak).

Additionally, a malicious guest administrator can cause files on the
host to be removed, causing a denial of service.  In some unusual host
configurations, ability to remove certain files may be useable for
privilege escalation.


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

Xen versions 2.0 and later are vulnerable.

The vulnerability is only exposed to guests configured by the host
administrator to boot using pygrub.  In the xl and xm domain
configuration file, this is typically achieved with
   bootloader="pygrub"
On x86 this would typically apply only to PV domains.

All systems using xl, libxl, or libvirt are vulnerable to pygrub-using
guests.

Systems using other (third-party) toolstacks may or may not be
vulnerable, depending on whether pygrub is configured, and what pygrub
output format they use.  Please consult your toolstack provider.


MITIGATION
==========

Configuring guests not to use pygrub will avoid the vulnerability.

For x86 PV guests currently using pygrub, booting the guest as HVM
is often a practical option to avoid pygrub.


CREDITS
=======

This issue was discovered by Daniel Richman and Gábor Szarka of
the Cambridge University Student-Run Computing Facility.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa198.patch           All Xen versions (at least Xen 4.4 and later)

$ sha256sum xsa198*
0e4533ad2157c03ab309bd12a54f5ff325f03edbe97f23c60a16a3f378c75eae  xsa198.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).

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


Deployment of the mitigations 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 switching away from the use of pygrub would reveal
where the vulnerability lies.

Deployment of mitigations is permitted only AFTER the embargo ends.


(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

iQEcBAEBAgAGBQJYNDN4AAoJEIP+FMlX6CvZX8AH/1FL3pw4RbbuFd/b23Qmo25U
F7qELx001C4C+uXtlxaIg6MT467pRphihSkLcLQ2vgIp57iVTXhufc4TVqhdADgp
bL3h1zd7Ot4f+iA5RYlGIJ4is3I2A6lNvLwydi2PIGgmalSad5B3Ed0vrvRwfLKY
qpsVm0LrM24aFX2IaygmmziQIQVeXSYpmKmVebOEAFL0uj9g8D3VhgWIMtZxW+9K
A6c2NTrt01ZbsVRx2wTcRdRhEJLeFbBZOPS9RrbjJzbuFcAzsGR8m/pS4hJBhik/
9MG4b7FBMYZTaBd4wcbbHM81py1KkcoreC2jL1qb1JMG7BQVP1USdz21rJ05DY8=
=P2XT
- -----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:

        http://www.auscert.org.au/render.html?cid=1980

===========================================================================
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

iQIVAwUBWDuBHYx+lLeg9Ub1AQiXlg//Qzrj6hFhamfw8xeJ1+7kD7iBDB9BWW7b
WgMEVAtQJq9LiYWbihYGsZSGFQ/CenZ3guBf9lwBuwMq21e1GlqBaH+9UOxUtEI9
TYc0VMiOALgars/w6VaiOftJhTgCsLMGstO9S5oQDc2lIcwbAjfwglfKaOC8blXu
/iYWTtFXSCyV4j1wJ72AhUfNHrph+StZ2H7uBsfxu7c+A9LRQX7v5D2F8g0A3K/F
uSofEVnGTCK9ZVP8anlFUGw3UJInHZRI/8/KOXoh21knoIaHs0rfx6+W8GYnFcA4
FwGdYO20eNuT0XVi6K2lunXsXFM1BYQrG4XYdfpraMkvYDBVRjQ94MEB0C+fTlsh
cTZZ9NAGgZAopTLP5vSdZkIqCRQzcGv9TPcxCmfCLD78MQjlHKpN3huQ5KGy3206
0g4Itw8EbfwJV5f0wCppd3hkY8Bag7z0bhLKAMX1+xdgQLRVxVPK/k3nrqvRNZ5L
dpY3Gk+9xsKeN7Tnbn0B0vHhps8czJlc9opVMhM5ve60JxZZ1hnnzP/B+MxlfIcU
gecEer8gecM6p85YCfdEOZz4b9xYz1FvUtjOgA9focUKWc6D531AbOy50Yen365r
yNQdfZtKzWwLZ6hJ/qsiyaYfpNos5OhhZCwuIvKxYpNSQ6w8jeoZ/JzokWexGoxZ
qkyAzNjvuGI=
=ObrJ
-----END PGP SIGNATURE-----