Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
On Sat, 17 Dec 2016, Hans-Christoph Steiner wrote: > One thing that would help a lot with future issues like this is to use > only encrypted connections in /etc/apt/sources.list. That can be either > HTTPS or a Tor Hidden Service .onion address. For in depth discussion > of this, see: You could bootstrap from one of the larger ISO media which have the entire standard system and you can sha256sum easily, and install without any networks connected. Then, manually install the updated .deb packages using an USB pendrive or something like that. You can also sha256sum these easily. Then enable the network, and update the whole system as usual, and run "tasksel" as root to ask for more package sets, etc. It is worth notice all this crazy dance is going to become unnecessary as soon as the next debian stable point release is issued [with an updated installer image], and new install media are made available. I will ask the stable release team to consider speeding up the next Debian stable point-release timeframe based on this. > https://guardianproject.info/2014/10/16/reducing-metadata-leakage-from-software-updates/ Yeah, right. However Debian 8 (jessie) and earlier, i.e. the current Debian stable, runs the apt transports as *root*, and *unjailed*. For that reason, you do *not* want a complex set of libraries with an history of being zero-day nurseries anywhere near APT in Debian 8 (jessie) and earlier. If you enable apt-transport-https in Debian 8 and earlier, you increase the chances of [eventually] being remote-exploited a great deal. So, please go with the bootstrap from an ISO media instead. NOTE: apt in Debian Stretch (Debian 9), runs the transports as an unpriviledged user, which is a lot safer. You should still avoid using apt-transport-https there unless required, it is much safer to have a local mirror [properly set up]. -- Henrique Holschuh
HTTPS needs to be implemented for updating
I know Micah Lee has been making the case for HTTPS connections for some time. Why can't Debian make this happen? This bug makes clear that relying on validating signatures is not foolproof 100% of the time and that additional layers of protection should be in place to try to mitigate weaknesses (even temporary ones). What with Let's Encrypt now active, there is no excuse to not move everything to HTTPS for updating. https://www.debian.org/security/2016/dsa-3733
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
Patrick Schleizer: > Julian Andres Klode: >> (2) look at the InRelease file and see if it contains crap >> after you updated (if it looks OK, it's secure - you need >> fairly long lines to be able to break this) > > Thank you for that hint, Julian! > > Can you please elaborate on this? (I am asking for Qubes and Whonix > (derivatives of Debian) build security purposes. [1]) > > Could you please provide information on how long safe / unsafe lines are > or how to detect them? > > Ideally could you please provide some sanity check command that could be > used to detect malicious InRelease files such as 'find /var/lib/apt > -name '*InRelease*' -size +2M' or so? > > The problem is, > > - debootstrap can only bootstrap from one source such as > 'http://ftp.de.debian.org/debian' - which still contains vulnerable apt. > (Correct me if I am wrong, I would hope to be wrong on that one.) > > - bootstrapping from 'http://security.debian.org' is not possible > [contains only security updates, not a complete repository]. > > - So in conclusion one has a chance to get compromised when > bootstrapping from 'http://ftp.de.debian.org/debian' and then apt-get > upgrading from 'http://security.debian.org'. > > Is there any way to break this cycle? > > Best regards, > Patrick > > [1] https://github.com/QubesOS/qubes-issues/issues/2520 > One thing that would help a lot with future issues like this is to use only encrypted connections in /etc/apt/sources.list. That can be either HTTPS or a Tor Hidden Service .onion address. For in depth discussion of this, see: * https://labs.riseup.net/code/issues/8143 * https://guardianproject.info/2016/07/31/howto-get-all-your-debian-packages-via-tor-onion-services/ * https://guardianproject.info/2014/10/16/reducing-metadata-leakage-from-software-updates/ For the official Debian Tor Hidden Service addresses including apt mirrors, see: https://onion.debian.org/ .hc
Re: [qubes-devel] Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
On Sat, 2016-12-17 at 04:42 +0100, Marek Marczykowski-Górecki wrote: > On Sat, Dec 17, 2016 at 02:47:28AM +0100, David Kalnischkies wrote: > > In terms of stable (which seems to be what you are asking about) there > > is a trivial 99,9% shortcut: stable has no InRelease file for technical > > reasons ATM, so something is fishy if you get one (aka apt should > > display Ign lines).² > > Not fully true: > http://security.debian.org/dists/jessie/updates/InRelease It _is_ correct. security.d.o/updates is not the stable distribution. The reasons that David mentioned specifically apply to the stable distribution in the main archive - i.e. stable - and the way that it's signed, not any other repositories or distributions that sit alongside stable and may have stable somewhere in their names. Regards, Adam
