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

Thu Jan 24 03:41:40 CET 2019

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

On 23/01/2019 11.16 AM, Simon Gaiser wrote:
> 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
> 

Related issue:

"Mechanism to notify users when critical action is required"

https://github.com/QubesOS/qubes-issues/issues/3430

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

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

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxJJeMACgkQ203TvDlQ
MDD3bBAAm/VlNvXQTmA/apCk3ZwWzNWqKCdawiBzjebJTjg/UDabUaZDnvihdfdf
7VGRlJIUONq0k4ddpImxv89OiklRC/VWzK7d/2t1TW+ZerN24WqRQRfSfWg/uCIz
VqHj3WDJ3vPBAuBA9NqBjweisnsvi+nzvLeob/6xaYGk/Ch5Cluy2SKiNDDJip7n
OkLlDcT5jB32HTzT0fHSdh+VrLGIx2Ey5sQOke2xvbF22M6wyrgcbvNcNdI5SR3I
pfLP+XGrbwrhMDSZdhtGiWwaSYp77FYlcUqY2GC9IoyrjGg0pAyBDwpJSQqzVAFG
Zti+2sHaVqt9rVhc0JigcC96I4Z16xH7cmjQto9mtfTqCxUX0W0+zds0xiPOvuA3
342ZxHfbTIVfWWORbq9LYAdLCqHUyXRBKH7rqke8M0XMlRAMoUJ0OOsN5dLyR6JJ
ChiYCNlGpPQDOsHCKANR2fhEks1BxQJq7G3T4yHWd8cCITHhArty6A270aOO1H2v
O51jWRCd7WKPJXm4Z+EpDr+bqqRvzMv9RBQ/3i51sk0HocSBb6jJ3N9RzxlmVmOk
t5XTtY4X+aKrXScz4Z3v0AhgJDulqYhtelZ995B5WOh9F3+BwRQHgqwnHGx3C0dI
IqlpWxmKbJ4wAMbFWQDTJvDduupDqV/XL5eT5hYBKkZNFQGcZwM=
=J40i
-----END PGP SIGNATURE-----