On 2019-01-27 01:34, 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. Thank you for your responses. I appear to have prodded a hornets nest! I make no apology for that. It’s good and allows everyone an opportunity to express their views. Hopefully backed up by facts. Here's some background as to where I'm coming from: 1/ I use Debian based templates; including Whonix, exclusively (I do have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat, monetised etc). So, all my apps (including service apps like sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited. At this point for me its game over. I'm completely stuffed. Now when Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the vulnerability was publicly announced, saying its comparable to a firefox exploit: I get angry and say what complete and utter PR horsesh*t.
2/ Nobody's going to blame Qubes for an vulnerability like this in Debian etc. However, the least I'd expect from Qubes is a timely warning. Personally, I got a warning from Whonix a good 12 hrs before Qubes alerted us! 3/ Most people have made an assumption that the good guys i.e. Max Justicz found the vulnerability first. Personally I never assume anything and prefer to think "worst case scenario". In this case I have had no privacy or security whatsoever for possibly years. Whilst Dom0's been protected, I'm not - what use is that? Now turning to Unman's comments: 1/ 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. With respect Unman, you seem to have missed the section where Max explicitly says "Supporting http is fine. I just think it’s worth making https repositories the default the safer default and allowing users to downgrade their security at a later time if they choose to do so". Furthermore, The Guardian Project have been promoting the use of https for apt package retrieval for many years. Here's their latest statement; "There is a new vulnerability in Debian’s apt that allows anything that can Man-in-the-Middle (MITM) your traffic to get root on your Debian/Ubuntu/etc boxes. Using encrypted connections for downloading updates, like HTTPS or Tor Onion Services, reduces this vulnerability to requiring root on the mirror server in order to exploit it. That is a drastic reduction in exposure. We have been pushing for this since 2014". https://guardianproject.info/2019/01/23/use-onions-https-for-software-updates/ 2/ Imagine that apt-transport-https *had* been adopted - have you actually looked at the list of vulnerabilities in libcurlnd the various breakages in the TLS CA system? You appear to be saying that Debian have created a package; apt-transport-https which is not fit for purpose? Have you notifified them of this? and if so what was their response? 3/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. Most users like me would have had no inkling that the https option existed. Is that option, with its pros and cons explained, located anywhere in the qubes docs; Ive searched and can't find it. No one as far as I can tell is losing their heads. We're simply looking for a system that has a philosophy incorporating; "defence in depth" and continuous improvement. And, for the most part, Qubes delivers on that. Lets keep an open mind on these issues and not become entrenched in intractable positions. -- 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/ae1dc83adc6a2135c3bde03321730096%40riseup.net. For more options, visit https://groups.google.com/d/optout.
