On Sun, Jan 27, 2019 at 02:37:16AM -0800, goldsm...@riseup.net wrote: > 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. > > Apologies. I've reposted this because the subscripts weren't clear in > the earlier post. Hopefully this will be clearer. > 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.
It's very late, so I wont be ale to give your post the attention it deserves, so apologies for that. Also, it's easier for me just now not to reply inline - again,apologies. Everything I say here is my personal opinion. 1. You're completely right. If Debian is exploited then all your templates may be compromised, and therefore all your qubes may be.No doubt. (You should probably be considering your service qubes compromised as a matter of course.) The QSB did not compare it to a firefox exploit: indeed it explicitly contrasted this with a Firefox exploit, and explained why it was different, and why it merited a QSB. If you reread the QSB you may find that you git angry a little too quickly. 2. I completely agree about the tardiness of the Qubes advisory, and have already raised this as an issue. BUT, if security is an issue for you , you should be reviewing the security advisories for Xen, Debian, Fedora , (and whatever key software you use), as a matter of course. Qubes does not pretend to offer an all in one solution, and it does not take the onus off the user to keep themselves protected. 3. I completely agree with you that it's a mistake to assume that there wasn't a 0-day circulating for this, although I haven't found any evidence that there was. It *is* possible that the vulnerability has been know and exploited for years. No doubt. I wont comment on the first of your replies to me. Doesn't seem fruitful. 5. Yes, I have discussed the shortcomings of that implementation, and work has been done to integrate https in to apt directly. I note that you haven't commented on the main issue - that https is not a magic bullet, and that switching to it would bring its own vulnerabilities. 6. Many users seem to think that Qubes provides a complete solution to security or privacy. It doesn't. Using Qubes does not take away the obligation on users to make sure that their templates and software are configured and updated to as secure a position as possible. Users should review the choices made by Qubes, and make sure that they are consistent with their needs. (You have done this by selecting all Debian templates.) For example, some users do not like passwordless root, and there are mechanisms to remove this. It's not feasible for Qubes to duplicate information provided for Xen, Fedora, Debian, Arch, and any other templates that people use. As I've said, if security is an issue for you then you should be keeping up to date with security bulletins from those sources, and any other key software that you use. That seems obvious to me. I don't think it's anywhere in the docs. Qubes provides a framework for using software - it doesn't take away the onus on users to use that software properly, and to ensure they are aware of good practice. (As an aside I'm always baffled by people querying how they can use Facebook under Tor or Whonix. What are they thinking?) I regularly audit templates with tripwire, running from an offline openBSD qube, and do standards checks with debsums. I do good deal of my work offline in openBSD and then transfer encrypted in to other qubes for transmission. That seems like overkill, and isn't for everyone: it might be for you. unman -- 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/20190127172159.whfbcmx4xvnya5ie%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
