-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 26/01/2019 7.34 PM, unman wrote: > On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net > wrote: >> >> Am I right in thinking that the recently discovered apt >> vulnerability (DSA 4371-1) in Debian based systems could and >> should have been mitigated against many years ago by downloading >> and activating an apt package; "apt-transport-https", which >> forces apt updates via https? The researcher (Max Justicz) who >> discovered the vulnerability has stated it couldn't have been >> exploited if https had been implemented. >> >> If "apt-transport-https" is the magic bullet, why in the past >> hasn't it been implemented by default? And, why for the future, >> is it not being implemented immediately by Qubes, Debian et al? >> >> During the past decade many people with good foresight had >> predicted the apt vulnerabilty and urged administrators to >> install the solution;"apt-transport-https". Regrettably, the >> vocal majority of so-called experts said that's unnecessary >> because the packages are signed. Was that incompetent advice? or >> was it a coordinated response from agents of State Actors to hide >> a deliberate backdoor? I've no idea, but given Snowdens >> revelations I would not rule anything out. > > No you're not right in thinking this. You seem to have missed the > section where Max explicitly say that "a malicious mirror could > still exploit a bug like this, even with https." So > apt-transport-https is no magic bullet, particularly as a cursory > glance suggests that it allows forcing SSL version to SSLv3, which > is known to be insecure. > > Imagine that apt-transport-https *had* been adopted - have you > actually looked at the list of vulnerabilities in libcurl, and the > various breakages in the TLS CA system? I can imagine some one > posting exactly like you: "Was the move to https incompetent > advice? or was it a coordinated response from agents of State > Actors to hide a deliberate backdoor? I've no idea, but given > Snowdens revelations I would not rule anything out." > > I would rule some things out. And in this case it looks like a > simple mistake. And if you read any of the arguments re http/https > you'd see that there are reasonable arguments on both sides, and > the "so called experts" took reasoned positions. > > It's always been open to you to install the package and switch to > https transport in your Debian templates, of course. And Qubes had > already started to use that by default too. Not to downplay the > importance of the bug, but let's not lose our heads. >
In addition, from a Qubes perspective, it's worth reiterating this part of the QSB: | Normally, we do not release Qubes Security Bulletins (QSBs) to address | vulnerabilities that only affect VMs internally without affecting the | rest of the Qubes system, i.e. vulnerabilities that do not undermine | the Qubes security model. | | For example, we do not release QSBs to address bugs in Firefox or | Linux kernel USB stacks, because Qubes OS was designed under the | primary assumption that in a typical desktop OS there will be | countless such bugs and that humankind will never be able to patch all | of them promptly (at least not as quickly as developers introduce new | bugs). This is, in fact, the very reason we designed Qubes OS as an | implementation of the security-by-compartmentalization approach. Whenever we're tempted to ask, "Why didn't Qubes secure X inside of a domU?" we should remember this. Not only is it unrealistic to expect the small Qubes team to fix vulnerabilities in software that many larger teams have failed to fix; it also misses the whole point of Qubes in the first place, which is to accept that such vulnerabilities are inevitable and protect ourselves from them by compartmentalizing them, limiting the damage they can do. [I can imagine a cynic responding, "Then why did you issue a QSB at all?" Even though there was no failure in the Qubes security model here (in fact, it did exactly what it was supposed to by limiting the damage this bug could do), we care far more about keeping users safe than about the "optics" of issuing a QSB. We would rather let some people misinterpret the situation and mistakenly think that this shows some flaw in Qubes if it means getting the word out so our users can secure their systems as quickly as possible.] - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxNHwUACgkQ203TvDlQ MDBzvhAAwRQ6ZjTY/dznI3o9fsR9ZSiv0gaCwZYRDqNwoUvXQqKlnqOLhV4Z8WuN 8F3Jcd812AcRIFmsmCXDiFQIW7SF59ywmtwRTukbpuVty+ZdxbIq5zo9WriZH93k 1P/91onvoCrtGI2CgTR8yb0PRF3xBhsKHwmFkKj4Kq1ablM2l1UYlN3VZ6GjxLlc TyXus26LChVm48jcoOB3PTMKpWw91LbTQPebl3OlwhpsilCWKSw0ge3MylLMFJLr q2MGmUxCtpJQTaoyMEAAReEEiV/UaytTJikDQcQ3YjiaCVqxodYqD5/dUfD5lFLp +o7a6wb//eHtwCMQG+RWWIlLaxNlPsUxT2BvujVmNeOn+e1z+jdktRxXK/Vknq8d a/eYui5SJdsVHQQAgkJgYPLaGFQqXg+2u+O8pgwZSoYXu63w7r2YCIB77LBmXumF 1u0JKMeX5NeP+1NyFPa4ELPiq07d+5FxEP47kzMpn83BFfQlPaQbur64st68iYbX wQFMX3Ro1kq/fMVTyH6gaIHmWNxjwrV5bcL5vTjessKKJScOFZigwK8ecHcGcbp5 nxo/l4Iy/ImsgvhT6XKDKWCk4QgrmGpM/XFfXLLx5m1T2hbz6iAvcMihOom85sOF oiAO+cowbZjYiYS+TxEgnVCTw1Ju086Fz9A72A/H4X7Y7RuHV8Y= =oKXP -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b5c71a74-ce48-3294-2b55-171ede5a111c%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
