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



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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to