[Whonix-devel] [qubes-devel] apt RCE

Simon Gaiser simon at invisiblethingslab.com
Wed Jan 23 18:16:40 CET 2019


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

Patrick Schleizer:
> Many users already upgraded APT in a vulnerable way without ever knowing
> about this issue.

That's probably true. OTOH if you count since the public announcement
from Debian it's only about 29 h. So I think there's also a significant
portion of users who didn't installed new packages in that time (While
apt-get update is also affected, AFAIU, unless you find another bug in
APT this does not enable code execution.).

For those affected we at least offer fresh templates. Of course
depending on the usage of those templates recovering might still require
significant work (sanitizing/recreating affected VMs).

And then there is of course always the possibility that somebody
discovered this bug much earlier.

> What about introducing a security on/off switch that a subset of Qubes
> developers can trigger?
> 
> Before apt-get (or other package manager) does actually anything, a
> simple script could fetch a file from Qubes clearnet domain (and/or
> onion) and ask "is it currently secure to update"?
> 
> In most cases, the server would provide a cryptographically signed file
> by a Qubes developer which says "ok". Otherwise in situations such as
> now with APT security vulnerability DSA 4371-1 a Qubes developer could
> put a cryptographically signed file saying "not safe" there. In such
> cases, updates would be blocked until a new file is provided.
> 
> Things to keep in mind related to such a file: man-in-the-middle attack
> - infinite freeze atttacks; rollback attacks; perhaps more. Can think
> about this more if this sounds interesting.
> 
> Of course there should be options to:
> 
> - disable this mechanism entirely
> - manually override by user
> 
> These override option is useful for:
> 
> - to stay flexible in case of bugs of this mechanism itself and,
> - to not give Qubes developers too much power. No advanced adversary
> should be able to ask Qubes developers to remotely brick all Qubes
> installations (mostly theoretic at this point and not important for now
> but still easy to implement and good to have),
> - other unforeseeable things.

I think blocking updates automatically is probably more problematic
than useful. But ...

> This idea could be seen as a subset of the emergency project news
> mechanism that is currently missing in all distributions. In short:
> distributions have no mechanism to communicate with their users
> effectively in situations such as this one. More info:
> 
> https://www.whonix.org/wiki/Dev/project-news

I think having something like qubes-announce directly integrated into
Qubes is a very interesting idea. (Of course implementing it safely is
tricky).

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

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlxIoXUACgkQkO9xfO/x
ly9Avw/7BqFwvZ/1N9WrWQGx3HTzg83ltMNdxq6/pnPCpYK9SgBzGl6b0jsdnTZH
sa7q4SXkDCSO9wyBkXMdgV89FS4ACc41gTocybUBpu7yXiTBSfFnWBNZku6WlfqC
v/th0zr2MNEQP2naV2lV1D4MXTHX5zUvX8hMvyAY6nDe6CxjEL+D3sqqlFE6YfKW
YsyRwGsynCFOsnYhMRHqLX/Y4Cp+baIMW0J1h1Ns1gtrlju8Kc7hI7kyNA3e8hzo
KW/gTJlj8Ug4jS6J/JMf0q2Xut+WWsnp6NkxMY/WD1y6IoxT9+u28pld8shHCsyu
m4/GsNe94F7uZlgHIgHto6hTRq619+0A3RoP36zrKFhUqLTVUVDN3wvY4HqZBUnF
b2IvslfDTy2bfHFPsNArWB3iVQoZlQq97fLg/q+SJ7bOkea0EvD9Ajy14V03cG1K
H7vrztcDDQmuar5Yzr1donXwRU1D57MFT/fHrJUZb5AzestfkCiQoe0iBdYzIBPq
FqY1hcoksKKyaym09GYZTQYZTPXe4CcM+Urz6Yjr1Q/Dm7YtiaBofxcjRfORJ2q9
atlc2Oz1SrVTogGWgHU7spnkZb42CErc1hh2dI0cH4A4nHiGKpNQstsCGEbYMOEE
sa/EnNRcZUfHbxOLSwwNSrqg+MSFAKuLeH+zxJBLqRDDfjo9Agw=
=jAwT
-----END PGP SIGNATURE-----


More information about the Whonix-devel mailing list