Announcement regarding the Meltdown and Spectre attacks

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dear Qubes Community,

The Qubes Security Team is currently investigating the extent to which
[XSA-254] (and the [Meltdown] and [Spectre] attacks more generally)
affect the security of Qubes OS. The practical impact of these attacks
on Qubes is currently unclear. While the Qubes Security Team is a
member of the [Xen predisclosure list], [XSA-254] was disclosed on an
accelerated timetable ahead of schedule, so our team has not yet had a
chance to analyze these attacks, nor has the Xen Project released any
patches associated with [XSA-254]. We are continuing to monitor the
situation closely. Once the Security Team makes a determination about
the impact on Qubes, we will make another announcement, update the
[XSA Tracker], and, if appropriate, issue a [Qubes Security Bulletin]
with information about patching.

[XSA-254]: https://xenbits.xen.org/xsa/advisory-254.html
[Meltdown]: https://meltdownattack.com/
[Spectre]: https://spectreattack.com/
[Xen predisclosure list]: https://www.xenproject.org/security-policy.html
[XSA Tracker]: https://www.qubes-os.org/security/xsa/
[Qubes Security Bulletin]: https://www.qubes-os.org/security/bulletins/

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2018/01/04/xsa-254-meltdown-spectre/

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpOR88ACgkQ203TvDlQ
MDCJ4w//WNeEUpsJ77Lj4ld5+nhqbUEYymGRjMPQAFQBrgnwzl4e9B1XlSyiSgfE
/moCRziePUy3rbjxg9CQhYau2qWIFLtsxjPggM6t//dWOcQY1P9Agc0HWvNqOKLO
tetILbCD1ttz4/WdcRvJTBD7y4NbeCcdDguuPjXgVbA3pRZ2fewUhlQ8/cjS8xV3
/xJfUHNiV5iT9W7pWVMuz7Z79xpZB7Yz3ONAN5OqS0eXEG0M3k77VQfTLylPzuXR
L8suGjeyZeeuUVVCFxHCyHaPod+e8YvHsCmDZLiTUZQZew8teG2QrM4eMRHrCxfG
aJrApSTqBTr35YxopkjKLWeSUjj41sA1sLQv4dM0xCknXQmb9vS3YCL4oVde/Fmy
LhqXu1Y5jmFrkRdVggaDWfCziINwFR6aQ86JTH9JqXmPvlKcEq+lGfgloCVWvDwf
KfdTMXmrsRGH7aY/KpM8oVMhARTOf+JSaGTPmztyaPifNy0chdh/jFdnRFmhqa+x
uay7EAml9VmknmdYtp1iOv9xu1ZnPxW5X2Y6PvL5zpExOWJSA6PeapciW382RTds
dmNmp/ynyw98mm3VQA81yaSgHlRk5HEntW209dsuIgPWcws5eU+clUORnSaQWaK+
SffR4NeXsO3HkTddL6VmDsZv40mwmi5J8gtgGAlN5uBUZQASbJM=
=gdii
-----END PGP SIGNATURE-----

[Chris Drake]

It is very clear: https://xenbits.xen.org/xsa/advisory-254.html

IMPACT
======

Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.

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

Systems running all versions of Xen are affected.

MITIGATION
==========

There is no mitigation for SP1 and SP2.

RESOLUTION
==========

There is no available resolution for SP1 or SP3.

For those unaware - this is a hardware fault. CPUs make use of speculative execution (Spectre) or Pipelines (Meltdown) - both of which can be used to attempt to access illegal memory. The access fails, however, it's possible to use the "stolen" memory before the access-fail is enforced in a way that makes it available on a side-channel (cache in these exploits, but could be anything else like ports/dma) to any non-privileged process.

[Marco Giglio]

By reading that advisory and information posted here (
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/),
it seems that there are 2 possible short-term mitigations against
Meltdown for QubesOS 3.2 users.
-  Move PV VMs to HVM.
-  Move PV VMs to use 32-bit kernels. It should prevent to use
Meltdown/SP3 against the hypervisor, but it won't prevent it against the
kernel itself.  Then update when newer 32-bit kernel with KPIT are
available.

Qubes 4 users shouldn't be affected by SP3/Meltdown, but should be
affected from SP1/SP2/Spectre.

[Steven Chamberlain]

Marco Giglio wrote:
> it seems that there are 2 possible short-term mitigations against
> Meltdown for QubesOS 3.2 users.
> -  Move PV VMs to HVM.

> [...]

> Qubes 4 users shouldn't be affected by SP3/Meltdown

It is really fortunate that Qubes OS 4.0 has moved to HVM-only domains.
I think an attacker is prevented from breaking out of a compromised
guest, into the host or other guests. It's exactly the worst-case
scenario that Qubes OS was engineered to mitigate.

But still, on vulnerable Intel hardware, when running an HVM guest OS
without the KPTI patches, malware running as a non-privileged user could
steal sensitive data from the kernel of that guest, or elevate
privileges. That requires HVM *and* updating the guest kernels (with
KPTI) in order to fix it, I think.

(I don't think replacing 64-bit PV guests with 32-bit is a good idea,
because KPTI is not implemented at all for Xen PV, or for any 32-bit
architectures yet.)

> but should be affected from SP1/SP2/Spectre.

These vulnerabilities might be exploited by JavaScript to break out of
the sandbox, for example. And then there is a potential to attack the
hypervisor or other guests by poisoning the branch prediction logic and
doing cache timing attacks. I don't think HVM helps here.

I notice that OpenSUSE is shipping CPU microcode for Intel and AMD,
disabling branch prediction completely. That sounds a bit extreme but
may be the only way to be safe against future exploits.

Regards,
--
Steven Chamberlain
ste...@pyro.eu.org

[Jim]

Retpoline: a software construct for preventing branch-target-injection appears to offer a possible mitigation of CVE-2017-5715 (Spectre).

https://support.google.com/faqs/answer/7625886

Allegedly Google have deployed Retpoline across their infrastructure.

"It is predicated on the fact that many CPUs implement a separate predictor for function returns. When available, this predictor is used with high priority, allowing for the construction of an indirect branch which is safe from speculation-based attacks...

“Retpoline” sequences are a software construct which allow indirect branches to be isolated from speculative execution. This may be applied to protect sensitive binaries (such as operating system or hypervisor implementations) from branch target injection attacks against their indirect branches."

Jim

> --
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ade43b3a-8050-df93-aa7c-d595cbb1a7cc%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Chris Drake]

Hi All,

My understanding of how these exploits work does not match most of the rhetoric surrounding "patching" them.

These are attacks that steal actual data by exploiting L1 cache side effects.

They are not attacks that steal or infer address mappings out of the TLB

Addresses are stored in data, not least including the stack, thus stealing them by way of the cache side channel is still possible (and achievable within 128 guesses even with ASLR according to the paper).

There are 2 different mechanisms by which the data gets inserted into the cache side channel; pipelines and speculative execution.

These mechanisms are attacker initiated - it's *their code* containing those pipelines and speculative exploits - not kernel etc code.

Thus - retpoline is irrelevant as far as I can tell?, as are (IMHO) many other weird proposed patch solutions - no amount of kernel tweaking is going to prevent a user process pipeline or speculation - we are dealing with a CPU architecture mistake, not anything easily (if at all) addressed in software.

Chris.

> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscribe@googlegroups.com.

> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ade43b3a-8050-df93-aa7c-d595cbb1a7cc%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-devel/oHk1o2rsX60/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-devel+unsubscribe@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/E1eXV6A-0005bR-Bu%40rmmprod07.runbox.

[Marek Marczykowski-Górecki]

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

On Fri, Jan 05, 2018 at 12:14:43PM +0000, Marco Giglio wrote:
> By reading that advisory and information posted here (
> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/),
> it seems that there are 2 possible short-term mitigations against
> Meltdown for QubesOS 3.2 users.
> -  Move PV VMs to HVM.

This option require VT-x support in the hardware. Something that wasn't
required by 3.2 before.

> -  Move PV VMs to use 32-bit kernels. It should prevent to use
> Meltdown/SP3 against the hypervisor, but it won't prevent it against the
> kernel itself.  Then update when newer 32-bit kernel with KPIT are
> available.

This option require replacing both VM kernel _and_ templates. Especially
painful for heavily customized templates.

> Qubes 4 users shouldn't be affected by SP3/Meltdown, but should be
> affected from SP1/SP2/Spectre.

Yes, that's correct.

We're still evaluating available options. For example there are three
alternative workarounds for SP3 developed in parallel on xen-devel, each
having own good and bad sides. And patches to mitigate SP1/SP2 are also
not ready yet.

For this reason, we're delaying Qubes OS rc4 (originally scheduled to be
released tomorrow), until we come up with final plan what to do about
those hardware issues.

> On 01/04/2018 10:53 PM, Chris Drake wrote:
> > It is very clear: https://xenbits.xen.org/xsa/advisory-254.html
> >
> > IMPACT
> > ======
> >
> > Xen guests may be able to infer the contents of arbitrary host memory,
> > including memory assigned to other guests.
> >
> > VULNERABLE SYSTEMS
> > ==================
> >
> > Systems running all versions of Xen are affected.
> >
> > MITIGATION
> > ==========
> >
> > There is no mitigation for SP1 and SP2.
> >
> > RESOLUTION
> > ==========
> >
> > There is no available resolution for SP1 or SP3.
> >
> >
> > For those unaware - this is a hardware fault. CPUs make use of speculative execution (Spectre) or Pipelines (Meltdown) - both of which can be used to attempt to access illegal memory. The access fails, however, it's possible to use the "stolen" memory before the access-fail is enforced in a way that makes it available on a side-channel (cache in these exploits, but could be anything else like ports/dma) to any non-privileged process.
> >
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpSZD0ACgkQ24/THMrX
1yyK9Qf/T5jG7zHPjwCmF4ztD2FRJoo0qJzWmtjgNz67V+tK1K/hQsTph3CMor5N
UCKSKqSXxRZVjTfgv4CW4SJqUfDk++aIs/lvdsAABOt25LU2nVOy9BwPSWVYZDs7
KqsERFSAaorNEzq0CftHVIDyvzOOtWRD/eGL4P5TlfTvCvv2HN2/Br9esItxF3CM
vzT/qGCnNpkhn9TIlVxK/JTeZ9t/krC1Z2/vaiU5h+noxv6LFvL4pZ5zILjNgcGu
BeeqymA1VrWijoRA2W+qdI3s3moCOQfWNvXxYujc/sAr/axVjqfdC4+qsL2h4pH2
OykhrEfRubAVSqyW4c/vYunT7ARY7A==
=00Sg
-----END PGP SIGNATURE-----

[bow...@gmail.com]

On Sunday, 7 January 2018 18:18:06 UTC, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Fri, Jan 05, 2018 at 12:14:43PM +0000, Marco Giglio wrote:
> > By reading that advisory and information posted here (
> > https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/),
> > it seems that there are 2 possible short-term mitigations against
> > Meltdown for QubesOS 3.2 users.
> > -  Move PV VMs to HVM.
>
> This option require VT-x support in the hardware. Something that wasn't
> required by 3.2 before.

Would it be possible to have a statement update on these 2 issues for 3.2 users. Ideally with 2 options:
paranoid: what to do to disable branch prediction (ala OpenSuSE)
best option with todays patch: upgrade to Q4? stay on 3.2 and patch/upgrade templates?

>
> > -  Move PV VMs to use 32-bit kernels. It should prevent to use
> > Meltdown/SP3 against the hypervisor, but it won't prevent it against the
> > kernel itself.  Then update when newer 32-bit kernel with KPIT are
> > available.
>
> This option require replacing both VM kernel _and_ templates. Especially
> painful for heavily customized templates.

out of topic but was very useful for my upgrade to fedora-26.

I use standard template and instead of customizing a clone template, I set-up on start up...

Here is an example for a postgresql server of my /rw/config/rc.local
rm -rf /var/lib/pgsql
ln -s /rw/var/pgsql /var/lib/pgsql
/usr/sbin/systemctl enable postgresql &
/usr/sbin/systemctl start postgresql &
/usr/sbin/iptables -I INPUT -j ACCEPT -i eth0 -s ... -p tcp --sport 1024:65535 --dport 5432 -m conntrack --ctstate NEW

To upgrade I just had to take the vanilla fedora-26 template and install postgresql in it.