apt-get upgrading security issue CVE-2016-1252

[nurmagoz]

i couldnt add the result in the forum because it exceeds 40000 character

but there non-free package updating ? hmm thats weird

ok found the non-free packages , it came from debian.list which is found in ;-

/etc/apt/sources.list.d/debian.list

adding non-freedom (contrib, non-free) APT repositories by default is it safe?

is it safe to allow non-free packages from source.list ? u can find that it is allowed by default if u go for example in whonix-workstation-template then:- nano /etc/apt/sources.list.d/debian.list [image] non-free added there by default (this is also by default in debian template) Edit by Patrick to add: Remove Whonix non-free,contrib in the repository https://phabricator.whonix.org/T874

[Patrick]

@nurmagoz:

i couldnt add the result in the forum because it exceeds 400000 character

No need.

but there non-free package updating ?

https://forums.whonix.org/t/adding-non-free-packages-by-default-is-it-safe

[Patrick]

This bug is getting more and more obscure. debootstraping is no longer safe as Marek pointed out.

Asked on the debian-security mailing list about that. (My message has not yet appeared on debian-security mailing list archive but you can read my message here. Will keep you posted on replies.)

Translated into less obscure terms: no downloadable upgraded Qubes or Non-Qubes-Whonix templates can be created before a solution to this issue was found.

[Patrick]

Very intersting response by an apt developer that I am going to study closer:
https://lists.debian.org/debian-security/2016/12/msg00012.html

[Patrick]

Please review this alternative sanity check:
Operating System Software and Updates - Kicksecure

[Ego]

Good day,

Just checked it. Works as well.

Have a nice day,

Ego

[Patrick]

Thanks. Old workaround deprecated.

Operating System Software and Updates - Kicksecure

[eujan1]

@Patrick

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

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?

@Patrick

Please review this alternative sanity check: Operating System Software and Updates

1. Is there anyway to verify non compromise yet for users who had already upgraded to version 1.0.9.8.4 other than looking for “suspiciously extra long lines”? If not, how sure can one be of non compromise?

2. If running Qubes OS, could other VMs possibly be compromised?

3. What is best recommendation for user already upgraded to version 1.0.9.8.4?

[Patrick]

@eujan1

Is there anyway to verify non compromise yet for users who had already upgraded to version 1.0.9.8.4 other than looking for “suspiciously extra long lines”?

There is none. And there will very much likely none in the foreseeable future. This is due to the the nature of malware. Detailed explanation:
Computer Security Education - Whonix

@eujan1

If not, how sure can one be of non compromise?

Practically, you cannot.

@eujan1

If running Qubes OS, could other VMs possibly be compromised?

If the attacker used this exploit and then also was smart enough to have another exploit against xen and used that, then yes, also other VMs could possibly be comprised

@eujan1

What is best recommendation for user already upgraded to version 1.0.9.8.4?

Nothing. That is being discussed here:
https://forums.whonix.org/t/document-recovery-procedure-after-compromise

[eujan1]

That’s what I was afraid of.

@Patrick

Is there anyway to verify non compromise yet for users who had already upgraded to version 1.0.9.8.4 other than looking for “suspiciously extra long lines”?

There is none. And there will very much likely none in the foreseeable future. This is due to the the nature of malware. Detailed explanation: Computer Security Education - Whonix

Would you consider looking for “suspiciously extra long lines” and finding none, a reasonable confirmation of not having been compromised?
Following the directions, I didn’t see anything obviously suspicious.

Don’t believe I’m a target, just privacy conscious.
Going to put you on the spot. Sorry…
If it were you, what would you do in this situation?

[Patrick]

@eujan1

Would you consider looking for “suspiciously extra long lines” and finding none, a reasonable confirmation of not having been compromised?

No, because that is the first thing sophisticated malware would cover up after getting active on the system. And any attacker who exploited this vulnerability would certainly fit the definition of sophisticated.

[Patrick]

@eujan1

Is there anyway to verify non compromise yet for users who had already upgraded to version 1.0.9.8.4

Need to correct myself. As per Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252 actually might be.

If you remember running apt-get update and you remember it not taking unusually long, that is if it did take as long as to download a ~ 1.3 GB file, then chances are very good you have not been compromised.

[eujan1]

@ Patrick Thanks for the replies. Guess I was looking for professional confirmation of what I already knew.

Does anyone have thoughts as to the probability of malware being introduced because of this particular issue, especially considering many whonix users upgrade via exit nodes?

[Patrick]

I am not aware of any reports of active attempts of exploitation of this bug in the wild. So for now targeted attacks only if anything. I can’t calculate a probability from that.

During manual apt-get update it would look sketchy to fetch a > 1 GB file. So not that unlikely to be spotted, I would speculate.

Most at risk seem systems using unattended upgrades. (No, Whonix does not use that.) (Specifically if these are distinguishable from manual apt-get updates - they could be - if they are running at expectable times. I don’t remember / haven’t checked this.)

[HulaHoop]

Thank you Patrick for handling this well. Please let us know when debootstrap is safe for those of us who build our images.

[Patrick]

General usage of debootstrap [unrelated to Whonix]:
It will be safe out of the box after the next Debian point release when apt 1.0.9.8.4 moves into jessie stable repository (not only in security.debian.org). Should be when Debian 8.7 is released.

Generally [unrelated to Whonix], running build processes using debootstrap followed by apt-get should be save when apt-get is visually watched. If it finishes usually quickly and does not download a > 1 GB file, no exploit attempt has happened. If it takes too long and is manually aborted, nothing can happen.

Before the Debian point release, to make Non-Qubes-Whonix safe without visually watching apt-get, a fix for Non-Qubes-Whonix build script similar to this one is still TODO:
Check for CVE-2016-1252 · marmarek/qubes-builder-debian@d755d2d · GitHub

[eujan1]

@Patrick

I am not aware of any reports of active attempts of exploitation of this bug in the wild. So for now targeted attacks only if anything. I can’t calculate a probability from that.

Thanks Patrick. Will be interesting to see if there are any exploits reported because of this issue in the future.

[Patrick]

Whonix git tag 13.0.0.1.4-testers-only with CVE-2016-1252 workaround has been released. Building that should be safe. My build hasn’t finished yet, but I guess it’ll complete.

Downlandable Non-Qubes-Whonix 13.0.0.1.4-testers-only are probably soon available.

[Patrick]

Build succeeded. Testing and uploading is still todo.

[Patrick]

Upload finally done. Haven’t tested it myself yet. Release announcement coming later. https://download.whonix.org/13.0.0.1.4/