[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

apt-get upgrading security issue CVE-2016-1252

Development
#1

I’ve been gladly pointed to very bad security issue.

Very short summary of the bug:

(my own words) During apt-get upgrading signature verification can be
tricked resulting in arbitrary package installation, system
compromise.

sources:

(Specifically dangerous when upgrading over Tor. Slightly less
dangerous when upgrading over onions mirrors [boils down to trust, i.e.
IF the onion mirror is not compromised by that time].)

The following bug report is for Qubes Debian, Whonix and Ubuntu templates, however it equally applies to Non-Qubes-Whonix. It’s a bug in Debian’s apt-get so all distributions are equally affected.

I guess Marek (Qubes lead developer) will soon reply to it. That will be great as confirmation if I am overexaggerating this or if it is as serious as I think. However, I am quite certain this is a serious security issue.

TODO:

  • A Whonix.org blog post to recommend holding with upgrading VMs until/if a workaround has been figured out?
  • Figure out a workaround to upgrade without getting compromised.
  • Release Whonix 13.0.0.1.2 downloadable VM images - probably no changes besides building the images with upgraded packages from Debian.
Ideas on Whonix Security Bulletins
No longer able to access the net via my VpnVM?
#2

Good day,

I might be reading something wrong here, but as far as I can tell, this seems to have already been fixed:

For the stable distribution (jessie), this problem has been fixed in version 1.0.9.8.4.

As mentioned here: https://www.debian.org/security/2016/dsa-3733

Or am I missing something?

Have a nice day,

Ego

#3

Right, but applying that upgrade through a regular apt-get dist-ugprade might get one compromised. So a special way to upgrade may be required this time.

1 Like
#4

Done:
https://www.whonix.org/blog/dont-apt-get-dist-upgrade-for-now

#5

Workaround:

Anyone can confirm the sha256 hashsums posted there?

Anyone wants to test?

1 Like
#6

Good day,

Am currently trying it for Non-Qubes-Whonix.

Have a nice day,

Ego

1 Like
#7

Good day,

The checksum is correct.

Have a nice day,

Ego

1 Like
#8

Checksum confirmed for Qubes-Whonix: apt_1.0.9.8.4_amd64.deb

If you are already using apt version 1.0.9.8.4 or higher, you can just do a regular upgrade.

Why is it not necessary for upgraded users to manually verify and re-install?

[OT: Forum timestamps are wrong by 8 mins]

#9

Good day,

After manually verifing it and running sudo dpkg -i sha256sum apt_1.0.9.8.4_i386.deb though, I get the following error:

dpkg: error processing archive sha256sum (--install):
 cannot access archive: No such file or directory
(Reading database ... 90685 files and directories currently installed.)
Preparing to unpack apt_1.0.9.8.4_i386.deb ...
Unpacking apt (1.0.9.8.4) over (1.0.9.8.3) ...
dpkg: dependency problems prevent configuration of apt:
 apt depends on libapt-pkg4.12 (>= 1.0.9.8.4); however:
  Version of libapt-pkg4.12:i386 on system is 1.0.9.8.3.

dpkg: error processing package apt (--install):
 dependency problems - leaving unconfigured
Processing triggers for man-db (2.7.0.2-5) ...
Errors were encountered while processing:
 sha256sum
 apt

Seems like libapt needs to be upgraded as well…

Furthermore, despite the error dpkg-query --show apt tells me that Apt is now 1.0.9.8.4.

Have a nice day,

Ego

#10

Here are all the packages that were updated with apt 2 days ago:

Upgrade: apt:amd64 (1.0.9.8.3, 1.0.9.8.4), apt-transport-https:amd64 (1.0.9.8.3, 1.0.9.8.4), apt-utils:amd64 (1.0.9.8.3, 1.0.9.8.4), libapt-inst1.5:amd64 (1.0.9.8.3, 1.0.9.8.4), libapt-pkg4.12:amd64 (1.0.9.8.3, 1.0.9.8.4)

Does sudo apt-get -f install correct the issue?

#11

It wouldn’t help to verify already upgraded users. It would be reasonable to assume, that the verification on the running system would show that everything is alright. If the system was compromised during a recent apt upgrade by a skilled adversary, then it would make a lot sense for the adversary the later install the non-comprised apt package and to hide as a rootkit elsewhere.

If considered compromised, a full compromise recovery procedure would be required. I don’t think we have documented a full compromise recovery procedure anywhere. Anyone know what I mean and can recommend a good link to some explanation of that?

Fixed time on the server just now.

Drop the sha256sum from that line. That’s a bug in documentation that I’ll be fixing now.

1 Like
Document recovery procedure after compromise
#12

Good day,

@entr0py: Yes, that does it. Now the question is whether this is safe to do, as while the system is telling me that 1.0.9.8.4 is already installed for apt, meaning the issue should be resolved, however, other packages relying on apt aren’t upgraded at that point.

Ok. That still leaves libapt. Is it reasonable to assume that it has no impact on this issue and thus running apt with it still under 1.0.9.8.3 is safe?

Have a nice day,

Ego

#13

Since I am not sure if just the upgraded apt package suffices: No (not safe).

One would have to manually download, verify and install all aptish packages with version from 1.0.9.8.3 to 1.0.9.8.4.

#14

If you want to have a look when you upgraded which package:

cat /var/log/apt/history.log

Updated https://www.whonix.org/wiki/CVE-2016-1252 to include all aptish packages. Should be no more need for apt-get -f install now.

#15

Good day,

Now it works without issue for all packages related to apt.

Have a nice day,

Ego

1 Like
#16

Since users who download Whonix images now are vulnerable and easily fall for regular upgardes, a warning for all supported Whonix platforms on their respective download pages has been added. Implemented just now in a form of a wiki template.

https://www.whonix.org/wiki/Template:Whonix_Current_Version_Maybe_Warning

The plan is that once Whonix images with fixed apt are released as stable, that template will be emptied (should then have the same effect as not being added). Should a similar situation arise, that template can be refilled.

2 Likes
#17

Good day,

I feel like this has already been discussed during the transitional phase from Whonix 12 to 13, though in the wake of this security issue, it might be a good idea to bring it up again. It would perhaps be a good idea to have an aditional field in Whonixcheck which informs users of imminent issues or events, like upgrading to a new version or a bigger security flaw which requires manual changes, like this, since a lot of users likely don’t read the blog or subscribe to a newsletter. Those things of course are still important though for emergencies like this, a seperate way of communcating might be a good idea.

Have a nice day,

Ego

#18

It would perhaps be a good idea to have an aditional field in Whonixcheck which informs users of imminent issues or events,

There is an insufficient one. Called Whonix News as part of whonixcheck. (old screenshot) Insufficient, because it gets hardly noticed by anyone ever. [At least the news files gpg verification stuff is done and hopefully solid, see source code.]

This is related to Whonix Upgrade Notification. The mockup by @entr0py in thread Whonix Upgrade Notification looks good.

[ ] Do not show again [ OK ]

Very true. Very much needed.

related:

Similarly a ticket for Emergency News Notification is does not yet exist. Ideally also a generic package that can enter packages.debian.org, where Debian and its derivatives such as Qubes and Whonix can drop .d style configuration snippets.

A generic package is better. Then Debian would have informed us about this CVE-2016-1252 earlier.

Ideally the Emergency News Notification tool would also have a Permanent Takedown Attack Defender feature. The initial version wouldn’t require that, but I would be good to plan ahead so it can be added in a later iteration.

Since this is a rather involved project, I suggest to start with a great description of the problems we are seeing, as well as with the solution we are proposing. And then post this on the debian-devel mailing list in the hope that people agree and $someone will implement it. [And even if there is no $someone, there will be hopefully a ton of feedback on how to get this right.] Anyone wanting to take the lead on that? :slight_smile:

3 Likes
#19

For an alternative way to check for being safe from CVE-2016-1252, critically review the following comment by me:
https://github.com/QubesOS/qubes-issues/issues/2520#issuecomment-267669095

#20

emergency news proposal (features, mockup, test cases, security, communications, etc.) can be added here:

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]