Whonixcheck security considerations

Development
1

I try to think like an attacker constantly when looking at Whonix’s design and I factor in knowledge about sidechannel attacks to lead me to accurate conclusions. Please understand that I am not criticizing Whonix by any means, but hope to give constructive advice.

-Part of whonixcheck relies on curl to query the clearnet for certain information
-curl has a troubling history of security holes, some remotely exploitable.
-https connections are subject to MITM this includes requests made by whonixcheck/curl to the clearnet.
-having a massive 0day arsenal at their disposal, its highly probable that the adversary is capable of exploiting curl.

  • This could lead to both Whonix vms being compromised through these channels out of the gate.

Recommendation:
TBB already does the checks curl does but in a more secure way. Taking the points above into consideration, the hypothetical benefits of redundant checks for Tor usage does not justify the increased attack surface area.

For tor specific checks we can either rely on a mechanism that bootstraps off Torbutton* somehow or completely remove these specific operations that depend on curl from whonixcheck:

+Tor Bootstrap Status (if it only queries the gateway, then no risk)
+downloads https://check.torproject.org with curl through extra SocksPort
+downloads https://check.torproject.org with curl through TransPort
+Tor Browser version
+Whonix version and Whonix news

++ Pretty much anything curl/clearnet related that does not connect to Tor directory authorities/ signed Debian repos.

ref: systemcheck - Security Check Application

  • TBB never checks check.tpo directly but relies on the small, vetted code of Torbutton to do so. Its definitely safer than curl’s code.
2

Great!

-curl has a troubling history of [url=https://security-tracker.debian.org/tracker/source-package/curl]security holes[/url], some remotely exploitable.
Any of that list that would have owned Whonix?

There are a lot ones such as this one…

CVE-2014-1263

curl and libcurl 7.27.0 through 7.35.0, when using the SecureTransport/Darwinssl backend, as used in in Apple OS X 10.9.x before 10.9.2, does not verify that the server hostname matches a domain name in the subject’s Common Name (CN) or subjectAltName field of the X.509 certificate when accessing a URL that uses a numerical IP address, which allows man-in-the-middle attackers to spoof servers via an arbitrary valid certificate.

Where I think “well, thanks for reporting, thanks for fixing, most interesting, but no immediate danger for Whonix”. I mean, using this very CVE as argument would be like saying “[hypothetical] don’t use Whonix Linux version because there was x CVE’s Whonix Windows version [/hypothetical]”.

I haven’t looked through the whole list of curl CVE’s if any of them would have applied to Whonix. Would you like to do this?

-https connections are subject to MITM this includes requests made by whonixcheck/curl to the clearnet.
whonixcheck has this in mind and uses results from these requests with care.
-having a massive 0day arsenal at their disposal, its highly probable that the adversary is capable of exploiting curl.
But with the 0 day it's getting very speculative.
rely on a mechanism that bootstraps off Torbutton* somehow
That sounds interesting, but this would require using Tor Browser + Tor Button because Tor Button is not supposed/supported to be run as standalone without Tor Browser. (It's a firefox add-on.) Seems also quite difficult. Perhaps it would require using some automation API such as http://www.seleniumhq.org to access Tor Browser using a program and perhaps would also require getting some patches merged into Tor Button.
+downloads https://check.torproject.org with curl through extra SocksPort +downloads https://check.torproject.org with curl through TransPort +Tor Browser version +Whonix version and Whonix news

These are usability and security features. Those are diagnosing, that connectivity is functional, check that the user has not shoot its own feet (by doing stuff like adding extra network adapters to Whonix-Gateway etc.) and inform the user about urgent news. I don’t think we’d be better off by disabling them by default.

By the way, any function of whonixcheck can be disabled using config:
https://github.com/Whonix/whonixcheck/blob/master/etc/whonix.d/30_whonixcheck_default#L90

So what could be done would be creating an optional settings file and package, that disables these features once applied, and document this in Security Guide - Whonix. Want to do this?

* TBB never checks check.tpo directly but relies on the small, vetted code of Torbutton to do so. Its definitely safer than curl's code.
That uses Firefox's code, which is not necessarily safer than curl's code? So rather than the unequal match curl vs Tor Button, this is rather a whonixcheck+curl vs TorButton+TorBrowser(Firefox) thing.
3
Where I think "well, thanks for reporting, thanks for fixing, most interesting, but no immediate danger for Whonix". I mean, using this very CVE as argument would be like saying "[hypothetical] don't use Whonix Linux version because there was x CVE's Whonix Windows version [/hypothetical]".

You are right there is a number of them that apply to curl on other OSs and proprietary security protocols like NTLM.

whonixcheck has this in mind and uses results from these requests with care.

Please tell me more about this. I think using SSL pinning would really go a long way in protecting users. The less curl features used the better too.

These are usability and security features. Those are diagnosing, that connectivity is functional, check that the user has not shoot its own feet (by doing stuff like adding extra network adapters to Whonix-Gateway etc.) and inform the user about urgent news. I don't think we'd be better off by disabling them by default.

Exactly. That’s why I’m not so eager to disable them by default an instead am looking at ways it can be hardened. Is there a way to distributed “signed” news text files that curl can fetch?

4

Using curl and results of curl with care:

  • using curl --max-time to defeat endless data attack
  • quoting variables
  • enforcing maximum string length
  • using shellcheck
  • making sure nothing is executed

SSL pinning:
https://github.com/Whonix/Whonix/issues/25
https://github.com/Whonix/Whonix/issues/24

Not sure what you mean. Maybe this is implemented:
Whonix News is gpg signed. When verification of Whonix News fails, user will be informed and the news will be rejected (not be shown).

Distributed not implemented yet:

5

https://github.com/Whonix/Whonix/issues/24

-Our only current option is the older idea.
-Have you found a successful way to do pinning? : Dev/SSL Certificate Pinning - Whonix
-I’ll assume you:
a. figured out that a local CA is needed since we want to not rely on a third-party
b. don’t know how to parse only the cert fingerprint using wget from the data fetched by openssl
c. still need some way to sign a key with no private key known or CSR available.
-The last part is what I concentrated on finding answers for since it may help solve the problem in b.
-wget cannot deal directly with SSL fingerprints but takes in certificates as a whole.
-I took a closer look at Monkeysphere and believe its relevant to this specific usecase. As it allows you to sign a the certificate with your keys and this information could be checked against the PKI and fed to wget in a way it readily understands when fecthing data from TPO.

web.monkeysphere.info/validation-agent/

The Monkeysphere Validation Agent (msva) is a daemon that provides a simple interface for any program to check the validity of an offered public key (or cryptographic certificate).
The Monkeysphere Validation Agent offers a local service for systems to validate certificates (both X.509 and OpenPGP) and other public keys in their proper contexts.

Among other reasons, having a validation agent is a good thing because:

Multiple tools can rely on the same PKI (e.g. the user's web browser and the user's ssh client).
A single validation agent can present a consistent UI to the user (when used in an end-user context), or provide a unified trust model to various services (when used in a server-side context).
Authentication/certificate validation code can potentially be isolated to a protected environment.</blockquote>

Details on how to use msva to query and validate the certificate in the local CA: http://web.monkeysphere.info/validation-agent/clients/

signing service keys you don’t have access to:
http://web.monkeysphere.info/doc/signing-service-keys/

If you are the person (or persons) that actually setup the service and configured Monkeysphere on the host, then you should sign the service key as part of that process. When the service is first set up, the administrators who set it up are the only ones who can actually vouch for the service key, so their signatures are necessary to get things going. Their signatures are also necessary so that they can validate the host key themselves.

If you did not set up the service initially, you do not have an accumulated full trust of the person(s) who did, or you do not have console access to the server directly, it’s hard to confidently verify the service identity and key ownership. You would like to be able to walk up to the server, log in at the console, and get the fingerprint of the service key directly, but this is usually impossible.

However, it is still possible to verify the service identity and service ownership of the key, even in this case.


It goes on to describe how this can be done with SSH keys as an example but is possible with x.509 certs.

Distributed not implemented yet: https://www.whonix.org/wiki/Dev/ptt

That was a typo, but that looks interesting. Would you say that you have metadata distribution all figured out but it needs time to materialize?

6

Found a useful list of OpenSSL commands, some dealing with validation:
http://redkestrel.co.uk/articles/openssl-commands/

Most probably you don’t need them but here they are.

7
[quote]Distributed not implemented yet: https://www.whonix.org/wiki/Dev/ptt[/quote]

That was a typo, but that looks interesting. Would you say that you have metadata distribution all figured out but it needs time to materialize?


It’s a lot implementation and probably maintenance effort. Maybe some day.

-Our only current option is the older idea.
Why?
-Have you found a successful way to do pinning? : https://www.whonix.org/wiki/Dev/SSL_Certificate_Pinning
Yes, the curl method on that page.
-I'll assume you: a. figured out that a local CA is needed since we want to not rely on a third-party
No local CA required.
b. don't know how to parse only the cert fingerprint using wget from the data fetched by openssl
No issue.
c. still need some way to sign a key with no private key known or CSR available.
Don't need that when using curl cert pinning.
-wget cannot deal directly with SSL fingerprints but takes in certificates as a whole.
Nevermind wget. Curl works fine for cert pinning.
8

Status update why there is no certificate pinning yet:
https://github.com/Whonix/Whonix/issues/24#issuecomment-54101846

9
[quote] -Our only current option is the older idea. [/quote] Why?

Because TPO shutdown their hs. I reaaly don’t get why. It could have been a simple workaround for this SSL pinning scheme.

10

I’ll reply to your suggestions on git. One last thing I wanted to ask about is how do you handle TOCTOU for curl?

11

[quote=“HulaHoop, post:9, topic:461”][quote][quote] -Our only current option is the older idea.
[/quote] Why?[/quote]

Because TPO shutdown their hs. I reaaly don’t get why. It could have been a simple workaround for this SSL pinning scheme.[/quote]
Sorry, there is a bit confusion here.

Old idea: wget.
New idea: hidden service.
Newer idea: curl

The curl / cert pinning implementation wouldn’t require a hidden service.

PIN Certificate Authority:
not using

PIN Certificate Directly - curl method:
current favorite as per Dev/SSL Certificate Pinning - Whonix

It’s not the CA. This is how this was found out:
http://sourceforge.net/p/curl/feature-requests/64/

I just was confused myself by Dev/SSL Certificate Pinning - Whonix because the instructions use “-CAfile”, I thought, “damn it, it’s just CA pinning, not cert pinning”, but wrong. It really is cert pinning. It is downloading torproject’s cert while pinning torproject’s CA for better security. “-CAfile” is only used for better security. It would work without and you’d end up with the same file unless another CA runs an attack at this moment. Updated Dev/SSL Certificate Pinning - Whonix, documented this a bit better to make this clear by showing the (non-)difference of using/not using “-CAfile”.

12

(As per http://en.wikipedia.org/wiki/Time_of_check_to_time_of_use.)

What specifically are you referring to? curl’s output is parsed right after running curl. If it fails, nothing gets parsed, user is informed. No idea how TOCTOU is relevant here. We’re not running curl on boot and parse it minutes later were things could be much different or something like that.

13
What specifically are you referring to? curl's output is parsed right after running curl. If it fails, nothing gets parsed, user is informed. No idea how TOCTOU is relevant here. We're not running curl on boot and parse it minutes later were things could be much different or something like that.

I see. It was something I stumbled upon earlier but its of no relevance since you made it clear we are not relying on wget.

It was th eOP’s complaint about script implmentations that made openssl and wget collaborate.

It's vulnerable to TOCTOU. [1] The MITM could let return a valid fingerprint for the openssl client request and tamper with the following wget request.
14

I see. It was something I stumbled upon earlier but its of no relevance since you made it clear we are not relying on wget.

It was th eOP’s complaint about script implmentations that made openssl and wget collaborate.

Yeah, that really doesn’t apply to curl. In that link, someone suggested “use openssl cmd line tool to check the fingerprint, then use wget to fetch”, but wget doesn’t look at the fingerprint. So a clever attacker could show the correct fingerprint to openssl cmd line tool, then use another fingerprint for wget. TOCTOU applies there, because it was suggested to use one tool that understands fingerprints combined with another one that does not understand fingerprints.

Doesn’t apply to curl, because curl understands this, and internally first checks the certificate, and if it works doesn’t work out, it stops, and if it works out, it continues to re-use the very same connection session, I assume [otherwise it would be a grave bug].

15

Summary of concerns. Please comment on this

-The worst that could happen to whonixcheck is that a MITM deceives curl in knowing if there is a new TBB version. Remote exploitation is a risk that you have considered and hardened curl against. Pinning is an upstream issue that is being addressed gradually but surely in the coming times.
16

Please let me know if this is how things are, because I’m trying to make an accurate assessment.

17
The worst that could happen [s]to[/s] [s]whonixcheck[/s] is that a MITM deceives [s]curl[/s] whonixcheck/tb-updater in knowing if there is a / there is no new TBB version. Remote exploitation is a risk that you have considered and hardened [s]curl[/s] whonixcheck/tb-updater against. Pinning is an upstream issue [s]that is being addressed gradually but surely in the coming times.[/s]
18

Since you’re open to suggestions let me put this out there and see what you think.

-The purpose of whonixcheck is to help the user know if they done a grave misconfiguration and to provide information about the whonix environment in general.

-whonixcheck is not a diagnostic tool to detect any hypothetical misconfiguration made by you in the codebase. (Not implying your skill is any less than excellent, just discussing hypotheticals)

Good security practice dictates that no functionality more than necessary should be enabled or used. And the remaining tools that are needed are hardened to the maximum extent possible. Even if the tools used have a high security assurance, its always best to not use anything in the first place when not needed - the enemy cannot exploit what is not there.

With these points in mind I suggest:

-Disabling the all cURL based requests on the gateway and here’s why:

  1. TBB checks for the gateway are unnecessary as there is no TBB supposed to be on there.
  2. While useful in the workstation, because the user might shoot themselves in the foot by configuring it to connect directly to the internet, checking that traffic goes through Tor on the gateway is of little utility as no user caused misconfiguration is relevant in that context.
  3. Whonixnews could be checked for and fetched via the Whonix repos, alleviating the need for cURL in this usecase. (Maybe this can be used for the ws version too)

-Even in the event that a trusted pinning system is figured out and deployed, it would not be good to have it on the gateway in case the user mistakenly runs Iceweasel on there.

  • Whonixcheck and its curl based functionality is vital and necessary to keep users safe from themselves. Therefore I am not advocating removing this needed functionality in its workstation counterpart.
19

Overlooked that sdwdate uses curl too, so that was pointles. Back to the drawing board…