apt RCE
閲覧: 101 回
最初の未読メッセージにスキップ
Brendan Hoar
2019/01/22 11:03:022019/01/22
To: qubes-devel
https://justi.cz/security/2019/01/22/apt-rce.html
A patch is out to cover this vulnerability, but I'm of the opinion that it may be best to move the qubes-update-proxy worker VMs to a disposable VM model after reading up on this one.
Granted, at first glance it appears that the use of the qubes-update-proxy certainly helps, but using disposable VMs might provide an extra layer of protection.
Also a good reason to ensure all of the URLs used for repositories are HTTPS, of course.
Brendan
Radoslaw Szkodzinski
2019/01/22 11:38:282019/01/22
To: Brendan Hoar、qubes-devel
No it isn't. libcurl itself has had multiple CVEs related to its
HTTP(S) implementation as well, that's not even mentioning OpenSSL.
Have fun reading:
https://curl.haxx.se/docs/security.html
https://www.openssl.org/news/vulnerabilities.html
Compare to apt, where most of it would still affect it even if you use
HTTPS: (plus this new one)
https://www.cvedetails.com/vulnerability-list/vendor_id-23/product_id-17236/Debian-APT.html
apt + https is bigger attack surface than apt itself...
Most importantly, Qubes has an update proxy which should scrub this
silliness anyway with the tinyproxy.
https://www.qubes-os.org/doc/software-update-vm/#updates-proxy
This cannot work with https target at all.
--
Radosław Szkodziński
Marek Marczykowski-Górecki
2019/01/22 12:03:202019/01/22
To: Brendan Hoar、qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote:
> https://justi.cz/security/2019/01/22/apt-rce.html
>
> A patch is out to cover this vulnerability, but I'm of the opinion that it may be best to move the qubes-update-proxy worker VMs to a disposable VM model after reading up on this one.
>
> Granted, at first glance it appears that the use of the qubes-update-proxy certainly helps, but using disposable VMs might provide an extra layer of protection.
Updates proxy unfortunately does not help with this issue, but also is
not affected by it (at least not directly). It is only a http proxy, which
does not interpret content it receive, only pass it down to the VM that
requested it. Specifically, if remote server would send malicious
Location: header, it will be forwarded back to apt. While in theory that
proxy could perform some extra filtering on the response, it isn't used
for that right now. I don't think tinyproxy supports anything like this
(but we could change it to a different http proxy implementation).
When using https, updates proxy does even have a chance to do anything
about it, as it sees only encrypted traffic.
Using DisposableVM as updates proxy does not help here, because
even if someone would perform the attack, updates proxy itself would
remain unaffected (unless it's based on the attacked template, but then
being disposable also doesn't help). The only thing that would change is
if someone would successfully take over updates proxy using different
method, then could attack apt from there - and when updates proxy is in
DisposableVM, then it's easier to return such proxy to a clean state.
> Also a good reason to ensure all of the URLs used for repositories are HTTPS, of course.
Yes, that's right, at least when connecting outside. As mentioned in the
linked post, it's far easier to attack any intermediate network machine
or mirror server, than being limited only to mirror server. On the other
hand, handling HTTPS also bring its own complexity (all the OpenSSL
stuff and more).
Something that could _in theory_ be a good idea, is plain http
connection to updates proxy, then https connection to
download actual updates. This still allows compromised updates proxy to
attack the template, but on the other hand, we could perform more
filtering/caching on the updates proxy level. BTW it's worth checking if
apt-cacher-ng a) is vulnerable itself to the attack b) prevents it
spreading further (i.e. resolve redirects locally).
But keeping more complex updates proxy have also its own downsides.
First, it enlarges its attack surface (you trade some apt/dnf bugs for
updates proxy bugs). But also it's harder to maintain, as you need
to track various repository layout changes for multiple distributions.
Related:
https://github.com/QubesOS/qubes-issues/issues/4415 "Egypt and UAE HTTP
Repository Manipulation/Poison"
https://github.com/QubesOS/qubes-core-agent-linux/pull/150 "Switch to
HTTPS"
https://github.com/QubesOS/qubes-issues/issues/1957 "Cache updates"
https://github.com/rustybird/qubes-updates-cache
- --
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/THMrX1ywFAlxHTNAACgkQ24/THMrX
1yzVxAf/Q/wwsoJaqy92zY3oc6u78toh+JPHFc+ouMumhNLrymsJI3MyMVozRMPF
ac5Hc/PPU35y/P7TuZSQ27Uy/+GVcha6H4xZW0KZRJzxjsjHJNjlIgbDfaV1JLhL
8Ta83bTUtfJOgJ1AsD+3y6J3SLLXTEHBYhuZNmMqfzWq9SZcvsHahfhfySysskLr
N4ozVbI5wkOaFkSsC505pzcsxsGvuRH2in1CGN8zBgH08K50UrePxA1Aackn1/5p
jbApw7JJ8qn9RJYePZLyMLKNwNjL+JF9IN9ZC6yHc9Uk468He8ydpMTbSf3g3INV
fp61FHnsgdv15pG7fO3JIJLl6gFC3A==
=t6eI
-----END PGP SIGNATURE-----
Hash: SHA256
On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote:
> https://justi.cz/security/2019/01/22/apt-rce.html
>
> A patch is out to cover this vulnerability, but I'm of the opinion that it may be best to move the qubes-update-proxy worker VMs to a disposable VM model after reading up on this one.
>
> Granted, at first glance it appears that the use of the qubes-update-proxy certainly helps, but using disposable VMs might provide an extra layer of protection.
not affected by it (at least not directly). It is only a http proxy, which
does not interpret content it receive, only pass it down to the VM that
requested it. Specifically, if remote server would send malicious
Location: header, it will be forwarded back to apt. While in theory that
proxy could perform some extra filtering on the response, it isn't used
for that right now. I don't think tinyproxy supports anything like this
(but we could change it to a different http proxy implementation).
When using https, updates proxy does even have a chance to do anything
about it, as it sees only encrypted traffic.
Using DisposableVM as updates proxy does not help here, because
even if someone would perform the attack, updates proxy itself would
remain unaffected (unless it's based on the attacked template, but then
being disposable also doesn't help). The only thing that would change is
if someone would successfully take over updates proxy using different
method, then could attack apt from there - and when updates proxy is in
DisposableVM, then it's easier to return such proxy to a clean state.
> Also a good reason to ensure all of the URLs used for repositories are HTTPS, of course.
linked post, it's far easier to attack any intermediate network machine
or mirror server, than being limited only to mirror server. On the other
hand, handling HTTPS also bring its own complexity (all the OpenSSL
stuff and more).
Something that could _in theory_ be a good idea, is plain http
connection to updates proxy, then https connection to
download actual updates. This still allows compromised updates proxy to
attack the template, but on the other hand, we could perform more
filtering/caching on the updates proxy level. BTW it's worth checking if
apt-cacher-ng a) is vulnerable itself to the attack b) prevents it
spreading further (i.e. resolve redirects locally).
But keeping more complex updates proxy have also its own downsides.
First, it enlarges its attack surface (you trade some apt/dnf bugs for
updates proxy bugs). But also it's harder to maintain, as you need
to track various repository layout changes for multiple distributions.
Related:
https://github.com/QubesOS/qubes-issues/issues/4415 "Egypt and UAE HTTP
Repository Manipulation/Poison"
https://github.com/QubesOS/qubes-core-agent-linux/pull/150 "Switch to
HTTPS"
https://github.com/QubesOS/qubes-issues/issues/1957 "Cache updates"
https://github.com/rustybird/qubes-updates-cache
- --
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/THMrX1ywFAlxHTNAACgkQ24/THMrX
1yzVxAf/Q/wwsoJaqy92zY3oc6u78toh+JPHFc+ouMumhNLrymsJI3MyMVozRMPF
ac5Hc/PPU35y/P7TuZSQ27Uy/+GVcha6H4xZW0KZRJzxjsjHJNjlIgbDfaV1JLhL
8Ta83bTUtfJOgJ1AsD+3y6J3SLLXTEHBYhuZNmMqfzWq9SZcvsHahfhfySysskLr
N4ozVbI5wkOaFkSsC505pzcsxsGvuRH2in1CGN8zBgH08K50UrePxA1Aackn1/5p
jbApw7JJ8qn9RJYePZLyMLKNwNjL+JF9IN9ZC6yHc9Uk468He8ydpMTbSf3g3INV
fp61FHnsgdv15pG7fO3JIJLl6gFC3A==
=t6eI
-----END PGP SIGNATURE-----
Chris Laprise
2019/01/22 12:57:452019/01/22
To: Marek Marczykowski-Górecki、Brendan Hoar、qubes-devel
On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote:
>> https://justi.cz/security/2019/01/22/apt-rce.html
>>
>> A patch is out to cover this vulnerability, but I'm of the opinion that it may be best to move the qubes-update-proxy worker VMs to a disposable VM model after reading up on this one.
>>
>> Granted, at first glance it appears that the use of the qubes-update-proxy certainly helps, but using disposable VMs might provide an extra layer of protection.
>
> Updates proxy unfortunately does not help with this issue, but also is
> not affected by it (at least not directly). It is only a http proxy, which
> does not interpret content it receive, only pass it down to the VM that
> requested it. Specifically, if remote server would send malicious
> Location: header, it will be forwarded back to apt. While in theory that
> proxy could perform some extra filtering on the response, it isn't used
> for that right now. I don't think tinyproxy supports anything like this
> (but we could change it to a different http proxy implementation).
The proxy appears to be 'affected' in the sense that Debian's temporary
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote:
>> https://justi.cz/security/2019/01/22/apt-rce.html
>>
>> A patch is out to cover this vulnerability, but I'm of the opinion that it may be best to move the qubes-update-proxy worker VMs to a disposable VM model after reading up on this one.
>>
>> Granted, at first glance it appears that the use of the qubes-update-proxy certainly helps, but using disposable VMs might provide an extra layer of protection.
>
> Updates proxy unfortunately does not help with this issue, but also is
> not affected by it (at least not directly). It is only a http proxy, which
> does not interpret content it receive, only pass it down to the VM that
> requested it. Specifically, if remote server would send malicious
> Location: header, it will be forwarded back to apt. While in theory that
> proxy could perform some extra filtering on the response, it isn't used
> for that right now. I don't think tinyproxy supports anything like this
> (but we could change it to a different http proxy implementation).
update instructions from their security bulletin do not work in the
Qubes template.
So we are missing a straightforward resolution that Qubes users can follow.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Brendan Hoar
2019/01/22 17:17:352019/01/22
To: qubes-devel
On Tuesday, January 22, 2019 at 12:57:45 PM UTC-5, Chris Laprise wrote:
> On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote:
...
> On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote:
> The proxy appears to be 'affected' in the sense that Debian's temporary
> update instructions from their security bulletin do not work in the
> Qubes template.
Reminder to self: anytime I post a security statement to qubes-* mailing lists, I should prepare to be schooled by those who are actually on top of this stuff. :)
> update instructions from their security bulletin do not work in the
> Qubes template.
> So we are missing a straightforward resolution that Qubes users can follow.
Brendan
Marek Marczykowski-Górecki
2019/01/22 19:06:372019/01/22
To: Brendan Hoar、qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
- --
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-----
1yzndQf/Z/htHtj8iNOBYD6A9yAvzSNd2ZGSAi8aMsu6xFT76NnRuAhVcTQXQCnh
RmXkms9D0pSrNfmo8l8KCciX6h+27YTBpXhyhE6FqjfvjTVyWk2+j/DmvpyqkN0e
yO1OvsnMj0e5YVJVn5KMAptXqOO13qIzm/y3AUD81bTiu1RXDJQOXMGTKKDg5ylK
q8zDv0D1QtfLx7LtzQ5GrI52hctrGjzHzCJBofCciCzHGazobmg3EbnuHQ0AN9zo
Fk+rhBgJ60QE0NU6xkb0I6y+fzymZtZmE4iCdq1QoZa0IKCyP583uJ18n7y5vw9A
7QQrOD62vMP8grq5XF6kWI807/FkKg==
=G/1E
-----END PGP SIGNATURE-----
unman
2019/01/22 20:49:172019/01/22
To: qubes-devel
instruction *do* work in a template.
What makes you think they don't?
I use apt-cacher-ng with the templates configured with http://HTTPS///
scheme, which allows for caching *and* HTTPS to repos.
I'm checking to see how apt-cacher-ng is affected, but wont be able to
finish until this evening.
Chris Laprise
2019/01/22 21:44:372019/01/22
To: unman、qubes-devel
On 01/22/2019 08:49 PM, unman wrote:
> On Tue, Jan 22, 2019 at 12:57:37PM -0500, Chris Laprise wrote:
>> On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote:
>>>> https://justi.cz/security/2019/01/22/apt-rce.html
>>>>
>>>> A patch is out to cover this vulnerability, but I'm of the opinion that it may be best to move the qubes-update-proxy worker VMs to a disposable VM model after reading up on this one.
>>>>
>>>> Granted, at first glance it appears that the use of the qubes-update-proxy certainly helps, but using disposable VMs might provide an extra layer of protection.
>>>
>>> Updates proxy unfortunately does not help with this issue, but also is
>>> not affected by it (at least not directly). It is only a http proxy, which
>>> does not interpret content it receive, only pass it down to the VM that
>>> requested it. Specifically, if remote server would send malicious
>>> Location: header, it will be forwarded back to apt. While in theory that
>>> proxy could perform some extra filtering on the response, it isn't used
>>> for that right now. I don't think tinyproxy supports anything like this
>>> (but we could change it to a different http proxy implementation).
>>
>> The proxy appears to be 'affected' in the sense that Debian's temporary
>> update instructions from their security bulletin do not work in the Qubes
>> template.
>>
>> So we are missing a straightforward resolution that Qubes users can follow.
>>
>
> Can you explain this? As far as I can see, the temporary update
> instruction *do* work in a template.
> What makes you think they don't?
With normal update proxy settings (no cache), this happens:
> On Tue, Jan 22, 2019 at 12:57:37PM -0500, Chris Laprise wrote:
>> On 01/22/2019 12:03 PM, Marek Marczykowski-Górecki wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> On Tue, Jan 22, 2019 at 08:03:01AM -0800, Brendan Hoar wrote:
>>>> https://justi.cz/security/2019/01/22/apt-rce.html
>>>>
>>>> A patch is out to cover this vulnerability, but I'm of the opinion that it may be best to move the qubes-update-proxy worker VMs to a disposable VM model after reading up on this one.
>>>>
>>>> Granted, at first glance it appears that the use of the qubes-update-proxy certainly helps, but using disposable VMs might provide an extra layer of protection.
>>>
>>> Updates proxy unfortunately does not help with this issue, but also is
>>> not affected by it (at least not directly). It is only a http proxy, which
>>> does not interpret content it receive, only pass it down to the VM that
>>> requested it. Specifically, if remote server would send malicious
>>> Location: header, it will be forwarded back to apt. While in theory that
>>> proxy could perform some extra filtering on the response, it isn't used
>>> for that right now. I don't think tinyproxy supports anything like this
>>> (but we could change it to a different http proxy implementation).
>>
>> The proxy appears to be 'affected' in the sense that Debian's temporary
>> update instructions from their security bulletin do not work in the Qubes
>> template.
>>
>> So we are missing a straightforward resolution that Qubes users can follow.
>>
>
> Can you explain this? As far as I can see, the temporary update
> instruction *do* work in a template.
> What makes you think they don't?
> user@d9:~$ sudo apt -o Acquire::http::AllowRedirect=false update
> Ign:1 http://security.debian.org stretch/updates InRelease
> Hit:2 http://deb.qubes-os.org/r4.0/vm stretch InRelease
> Ign:3 http://deb.debian.org/debian stretch InRelease
> Err:4 http://deb.debian.org/debian stretch Release
> 302 Found
> Err:5 http://security.debian.org stretch/updates Release
> 302 Found
> Reading package lists... Done
> E: The repository 'http://deb.debian.org/debian stretch Release' does no longer have a Release file.
> N: Updating from such a repository can't be done securely, and is therefore disabled by default.
> N: See apt-secure(8) manpage for repository creation and user configuration details.
> E: The repository 'http://security.debian.org stretch/updates Release' does no longer have a Release file.
> N: Updating from such a repository can't be done securely, and is therefore disabled by default.
> N: See apt-secure(8) manpage for repository creation and user configuration details.
Did I miss something?
At this moment, I could try to gpg verify the DSA bulletin, then use the
hash from the bulletin to verify a manually-downloaded apt deb before
installing it.
Or, since I have Whonix installed, maybe look at the docs for enabling
.onion updates.
>
> I use apt-cacher-ng with the templates configured with http://HTTPS///
> scheme, which allows for caching *and* HTTPS to repos.
> I'm checking to see how apt-cacher-ng is affected, but wont be able to
> finish until this evening.
about your vuln review. However, I'm not sure how many other users will
want to setup a cache. And if it requires installing any packages, then
that leaves me in a catch-22.
Marek Marczykowski-Górecki
2019/01/22 21:51:352019/01/22
To: Chris Laprise、unman、qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
This is known to break some proxies when used against
security.debian.org. If that happens, people can switch their security
APT source to use:
deb http://cdn-fastly.deb.debian.org/debian-security stable/updates main
Anyway, a progress on automated fix:
https://github.com/QubesOS/qubes-issues/issues/4752
- --
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-----
1yyVFwf2OE5iwaUd5m0wKU7IKaB/PhmiOw6paUuHHU/u4gbpz1LjA46/HgJf+3i0
I2FcJuxSdHhpCEd9TX7hJq4DuS7MSR+OWPhKkZdRsCZoK7KrweRLqnty5/C+5FaQ
tu9wvqw1sZE82rAiDkxbAv6n0PS/HxkeKS/hNHFRRyXZNx+Degu4P8+Dvr++m10s
N4PB5luaw+3GPCJdp+hf3xhWqhnAR1s8/BBy4bLvIsd0PS9qjYPlSZx0bExTpHcI
WTuAg0FRImLhL7bELAxyPKbx0KhjAVs9ToJhRJDC8uTm4++ctAwUJDbwHSeEtSSk
zK44/+tc9RQnqt2rxCymE+P+EO+w
=7uDy
-----END PGP SIGNATURE-----
Chris Laprise
2019/01/22 22:06:062019/01/22
To: Marek Marczykowski-Górecki、unman、qubes-devel
disabled is the default) so at first I dismissed that advice. Then I
tried adding their source line anyway and got the same warnings.
I didn't realize, as Ilpo suggested, that I should comment-out the other
sources temporarily. That did the trick.
Patrick Schleizer
2019/01/23 5:02:322019/01/23
To: qubes...@googlegroups.com、Whonix-devel、Patrick Schleizer
Many users already upgraded APT in a vulnerable way without ever knowing
about this issue.
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.
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
Cheers,
Patrick
about this issue.
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.
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
Cheers,
Patrick
unman
2019/01/23 9:03:102019/01/23
To: qubes-devel
placeholder with SRV records pointing to repositories.
If the SRV doesn't work, then it provides a redirect function, which you
are obviously blocking, (as instructed).
The instructions aren't all that clear, since the problem will occur with
any use of deb.debian.org, not just for security repos.
Marek Marczykowski-Górecki
2019/01/23 9:29:572019/01/23
To: Patrick Schleizer、qubes...@googlegroups.com、Whonix-devel、Patrick Schleizer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
I think it makes more harm than good. Potential of breaking updates
completely is too big, either by a bug in such mechanism, or someone
attacking this mechanism itself. Having a single point of failure
blocking (potentially) all updates for all templates (and maybe even
dom0) doesn't sound good.
> 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
>
> Cheers,
> Patrick
>
- --
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/THMrX1ywFAlxIemAACgkQ24/THMrX
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-----
1yz4HQf/QEzPlS+WkX1kjF3xT7FRx273Aj8sJWBwncTNO6QTPk2dLO5Qyomfo4vi
7106DJa4iRcEBrRFU+rCsAoXYWAL/eFRCIVr6XxYLez3y4aX3qaF9aOfRV7PBKEg
FUZcTHvAsY980sYA1ZM7OEYwDXgxU4Jqo1HkVqFE5FjjmXUy7QEWBvDJWIbcOTBz
deEflNglvbsMvYsTe/TAEfJ4p34n7NsxzMZJWxZeOPATdZcr6zZYweBpp6heBqtS
LElp7/dtO0ac6p4PqSkfDbyXxPAe8Ucf14TSXY/2XnO/D8PJ1cqhG6LC0e6J+4ey
a03uzaxddh3Iv9DPrg+RpoQXpZkS/w==
=pPkF
-----END PGP SIGNATURE-----
unman
2019/01/23 9:43:012019/01/23
To: qubes...@googlegroups.com
On Wed, Jan 23, 2019 at 10:02:00AM +0000, Patrick Schleizer wrote:
> Many users already upgraded APT in a vulnerable way without ever knowing
> about this issue.
>
Yes, and many will have installed the update before Qubes is able to
> about this issue.
>
push out a resolution. So, not meaning to put down efforts, it seems to
me that working on a scripted solution is not the best way to go.
I dont know what is the readership of qubes-users, but should
announcements not be sent there for widest coverage? Particularly where
the fix is already available and could be installed by anyone capable of
copying commands. (Please, no adverse comments about our users.)
> 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.
wouldnt favour such a process.
Another major issue is that it relies on users responding to the
inability to update, and once the resolution is posted, updating as
instructed. As opposed to simply doing nothing and then updating as
normal. (Whatever the Qubes scripted solution may be it must rely on
users updating and installing it before using apt again.)
I'm generally not in favour of mechanisms that push to users. I have
seen these implemented in various networks and they sometimes work well.
I'm not convinced that they work any better than passing information by
posting messages on mail or website. Users who dont follow those are
likely also to ignore pushed messages - classic click through without
reading.
>
> 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.
>
> 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
>
> Cheers,
> Patrick
and response. I've had a quick look at the proposal and I cant see how
it will overcome the obstacles that bedevil existing schemes.
I have seen this sort of mechanism implemented on private networks,
where users HAD to perform certain actions before being able to access
company resources. Sometimes it worked; sometimes not. Only the threat
of the policy handbook would make some users do the right thing, and even
then there was considerable kick back. More effort went in to
circumventing controls than in to compliance - some people are like
that.
(I recognise that you mention an opt-out/override option.)
Simon Gaiser
2019/01/23 12:16:482019/01/23
To: Patrick Schleizer、qubes...@googlegroups.com、Whonix-devel、Patrick Schleizer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Patrick Schleizer:
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-----
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
> about this issue.
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.
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
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-----
Chris Laprise
2019/01/23 12:24:272019/01/23
To: unman、qubes...@googlegroups.com、Marek Marczykowski-Górecki、Patrick Schleizer
On 01/23/2019 09:43 AM, unman wrote:
> On Wed, Jan 23, 2019 at 10:02:00AM +0000, Patrick Schleizer wrote:
>> Many users already upgraded APT in a vulnerable way without ever knowing
>> about this issue.
>>
>
> Yes, and many will have installed the update before Qubes is able to
> push out a resolution. So, not meaning to put down efforts, it seems to
> me that working on a scripted solution is not the best way to go.
One more wrinkle to all this:
> On Wed, Jan 23, 2019 at 10:02:00AM +0000, Patrick Schleizer wrote:
>> Many users already upgraded APT in a vulnerable way without ever knowing
>> about this issue.
>>
>
> Yes, and many will have installed the update before Qubes is able to
> push out a resolution. So, not meaning to put down efforts, it seems to
> me that working on a scripted solution is not the best way to go.
People installing the debian-9 template fresh (or reinstall): How should
they update securely?
There is the install iso and also the repo package to consider. I
suppose the latter is relatively easy to update, but the iso not so much.
I wouldn't object to a dom0 solution that - at template install time -
tests a watchlist of package versions for that OS. This could be touted
as a form of VM hardening offered by Qubes.
Simon Gaiser
2019/01/23 12:36:202019/01/23
To: unman、qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
unman:
Hash: SHA512
> On Wed, Jan 23, 2019 at 10:02:00AM +0000, Patrick Schleizer wrote:
>> Many users already upgraded APT in a vulnerable way without ever knowing
>> about this issue.
>>
>
> Yes, and many will have installed the update before Qubes is able to
> push out a resolution. So, not meaning to put down efforts, it seems to
> me that working on a scripted solution is not the best way to go.
One of the main motivation for the scripted solution was to cover users
>> Many users already upgraded APT in a vulnerable way without ever knowing
>> about this issue.
>>
>
> Yes, and many will have installed the update before Qubes is able to
> push out a resolution. So, not meaning to put down efforts, it seems to
> me that working on a scripted solution is not the best way to go.
who don't read the announcements (Also it's reused for template builds).
> I dont know what is the readership of qubes-users, but should
> announcements not be sent there for widest coverage? Particularly where
> the fix is already available and could be installed by anyone capable of
> copying commands. (Please, no adverse comments about our users.)
Debian announcement? Something else?
We should consider some quicker reactions than a full QSB. But then you
also need to consider that creating such announcements in a hurry is
tricky, especially if you try to provide copyable command. I'm sure
Debian has put some thoughts into their message and still it wasn't that
clear to some users.
>> 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.
>
> I think that you have already identified many of the reasons why I
> wouldnt favour such a process.
> Another major issue is that it relies on users responding to the
> inability to update, and once the resolution is posted, updating as
> instructed. As opposed to simply doing nothing and then updating as
> normal. (Whatever the Qubes scripted solution may be it must rely on
> users updating and installing it before using apt again.)
is through the Qubes Manager they are covered.
> I'm generally not in favour of mechanisms that push to users. I have
> seen these implemented in various networks and they sometimes work well.
> I'm not convinced that they work any better than passing information by
> posting messages on mail or website. Users who dont follow those are
> likely also to ignore pushed messages - classic click through without
> reading.
something) would reach a lot more users than any MLs.
instructions than in a classic cooperate environment.
And if users intentionally ignore our advice, that's fine, I think. It's
their decision.
Simon
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlxIpg0ACgkQkO9xfO/x
ly/WXA/+IX6A5gpbPWdIgpUKTRcS77IYHR1Y2ibEJwKpFe8vHWicTG/QW+M6X+cz
fnKuZwKOjntVHKIflXELKmfybtRmizD8AMri342OsrYxD7qdG1KBnnP/XNzjwhz4
R6UKKm54evjaZbY4T9C0nh8nwqFdS52hXM3N+9swQ9GqYkiTh0P2CNMMW/KDRRSR
1RHQQCWkMTLb6rIu4z/MtluIAuOK2caAfZLJnGYmMi6KVsS+OK9rK/aOQtz/u1w8
IGnqxuwj7CI6Tk/rD0iAtR34zHxhGHPYTi9rNrvTXIVkD69FY8HlWbGZtheheLyn
SzocHaUib4oVXpRCc03N37TMMTQbmzvESqoOo+BRsVEkuXeP219S61gZPMHEqNFT
iTg/9oMXviDLIWykqitqhMh4r5DCHc02hcbEPFAdkiNHOQTa22+R2Adi9lRlIvuq
vvXNbKy5dO3gzYvFuhCDwV0szbp4F5xo7ljzdXzEQ6asGks8OifuKzFathR9HgCt
rBMdCNTQIhHTyyFp8l2PzZLcETc+qpETmW6Kbax3+ZtnM9C+tQu5SFIsSNtTzL7j
X+MmJ1hAhsBwe4VUMH9w8ICocVGittk6g7thclDCY582aaSYee53pj02MrvWXa1k
IBYmyIAoos8rbQCHrhl1h5F45BVj0OGPOIjGLRJPMCpYJLvHUx8=
=LjAK
-----END PGP SIGNATURE-----
Andrew David Wong
2019/01/23 21:42:022019/01/23
To: Simon Gaiser、Patrick Schleizer、qubes...@googlegroups.com、Whonix-devel、Patrick Schleizer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
"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-----
Chris Laprise
2019/01/24 15:14:012019/01/24
To: unman、qubes-devel
'jesse-backports' in sources.list.
Marek Marczykowski-Górecki
2019/01/24 15:33:452019/01/24
To: Chris Laprise、unman、qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Thu, Jan 24, 2019 at 03:13:54PM -0500, Chris Laprise wrote:
> On 01/23/2019 09:03 AM, unman wrote:
> > On Tue, Jan 22, 2019 at 10:06:01PM -0500, Chris Laprise wrote:
> > > I didn't realize, as Ilpo suggested, that I should comment-out the other
> > > sources temporarily. That did the trick.
> > >
> >
> > deb.debian.org, which you are using, isnt a repository. It's a
> > placeholder with SRV records pointing to repositories.
> > If the SRV doesn't work, then it provides a redirect function, which you
> > are obviously blocking, (as instructed).
> > The instructions aren't all that clear, since the problem will occur with
> > any use of deb.debian.org, not just for security repos.
>
> The new debian-9 template appears to have an extraneous line for
> 'jesse-backports' in sources.list.
Oh, indeed, fixed:
> On 01/23/2019 09:03 AM, unman wrote:
> > On Tue, Jan 22, 2019 at 10:06:01PM -0500, Chris Laprise wrote:
> > > I didn't realize, as Ilpo suggested, that I should comment-out the other
> > > sources temporarily. That did the trick.
> > >
> >
> > deb.debian.org, which you are using, isnt a repository. It's a
> > placeholder with SRV records pointing to repositories.
> > If the SRV doesn't work, then it provides a redirect function, which you
> > are obviously blocking, (as instructed).
> > The instructions aren't all that clear, since the problem will occur with
> > any use of deb.debian.org, not just for security repos.
>
> The new debian-9 template appears to have an extraneous line for
> 'jesse-backports' in sources.list.
https://github.com/QubesOS/qubes-builder-debian/commit/07c4621d992da8de2780e07098e9dcab6680e673
Will be in the next template build.
- --
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-----
1yxuywgAhCZ9en/IEIuqKzf0WQH7PF2FBFJpUG6SRb5SQ+4D1J3uLbq2chH0FanG
YvGCEMJZ0DJtEDlPJ6vZ35hbKAwSh68NZ+UAa9wX+ZQINrARoATT+O/yeiaLzyGV
A2SQ5lu8GKSTP8lAjPn77QOWC4EvIlWwtEeh5driyv+ThRRjt5WfeZGyU6ifxafe
63sTVRxKd3g+ds2/BbARH4ATnLN8MT6n2dIzvpX+yfOBzMe+awNrEw75OhmoUb5U
LCilB9VqhdzSrE2uGhFx5RaPBcCNtjjd+iycpZEe+1VsGKaRBynx017jAU1iqQJ0
JU9wMeNOlfFwPlDa0GPRH0rRaN1lVA==
=1QSY
-----END PGP SIGNATURE-----
Ilpo Järvinen
2019/01/25 22:26:512019/01/25
To: Chris Laprise、qubes-devel
"This is known to break some proxies when used against security.debian.org.
If that happens, people can switch their security APT source to use:
deb http://cdn-fastly.deb.debian.org/debian-security stable/updates main"
with this repo once?
--
i.
全員に返信
投稿者に返信
転送
新着メール 0 件