Opened 8 years ago

Closed 4 years ago

Last modified 4 years ago

#3861 closed enhancement (fixed)

begin signing Windows packages the Windows way

Reported by: erinn Owned by: gk
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Keywords: tbb-3.0, tbb-security, tbb-usability-stoppoint-app, tbb-4.5-alpha
Cc: shondoit+trac.torproject@…, Sherief, gk, tom@…, mcs, starlight.2015q1@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Right now we have no way to prove to users that we made the Windows packages we distributed, besides giving them signature files, which I feel extremely confident that 99% of them never check. We had a discussion at the Tor dev meeting in July about methods for using Microsoft's built-in signing tools. I have unfortunately forgotten the details of that discussion, but this ticket will serve as a place to dump any details we rediscover.

Child Tickets

Change History (29)

comment:1 Changed 8 years ago by mo

I think you should sign. What you need is the "Core SDK Tools" that ship with the Platform SDK. You can select to install only those, and AFAIK you don't need Visual Studio.

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11310 (web installer)
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24826 (ISO)

More info on how to perform it and screenshots comparing signed and unsigned executables: http://www.kinook.com/blog/?p=10

"get a code signing certificate (or digital ID) from a certification authority (CA) such as Comodo, Thawte, VeriSign, and others. You will need a Class 3 digital certificate for code signing."

comment:2 in reply to:  1 ; Changed 8 years ago by rransom

Replying to mo:

I think you should sign. What you need is the "Core SDK Tools" that ship with the Platform SDK. You can select to install only those, and AFAIK you don't need Visual Studio.

osslsigncode is a portable open-source alternative, although if we're planning to switch to Microsoft's toolchain anyway,

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11310 (web installer)
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24826 (ISO)

More info on how to perform it and screenshots comparing signed and unsigned executables: http://www.kinook.com/blog/?p=10

"get a code signing certificate (or digital ID) from a certification authority (CA) such as Comodo, Thawte, VeriSign, and others. You will need a Class 3 digital certificate for code signing."

Distributing all of our packages as .exe files signed in this manner will do more harm than good to our users unless they check that each package is signed by the exact certificate which we use to sign packages.

comment:3 in reply to:  description Changed 8 years ago by Sebastian

Replying to erinn:

We had a discussion at the Tor dev meeting in July about methods for using Microsoft's built-in signing tools. I have unfortunately forgotten the details of that discussion, but this ticket will serve as a place to dump any details we rediscover.

From what I remember we decided that we wouldn't bother, as the UI in windows isn't significantly different whether you have signed the package or not, and we'd rather spend the extortion fee elsehow.

comment:4 in reply to:  2 Changed 8 years ago by ioerror

Replying to rransom:

Distributing all of our packages as .exe files signed in this manner will do more harm than good to our users unless they check that each package is signed by the exact certificate which we use to sign packages.

As I understand this discussion, we are trying to augment our signature system to reach platform and feature parity without a bootstrapping problem.

gpg is the basic way signatures are created and verified on Free and Open source platforms such as Debian Gnu/Linux.

On Windows gpg signature verification requires clients to download gpg and as far as I understand gpg packaging on Windows, a new problem appears and it is the same: How does the user verify the download of gpg? Practically, most users don't get this far but if they did, I don't believe they have a trust path to gpg either.

The main goal here is to allow a potential user to find a trust path to *either* gpg or the win32 code signing valid key; in an ideal world they will verify the gpg signature - practically, they at least will have the ability to verify the windows signature if gpg is unavailable.

As I understand how the packages are built and will continue to be built, the gpg signature will still sign the packages and inside the packages we'll have some kind of native platform signature.

From where I stand, I think this only improves the security in theory and practically, we can now raise the bar for tampering with packages to owning a CA and/or faking a GPG trust path. This seems to be a much higher bar than is currently the case today.

Erinn, does that sound about right?

comment:5 Changed 8 years ago by erinn

Yes, that is a very good summary of the situation. I don't think I decided not to bother -- it was left as a 'controversial' issue, but I think we should explore it more. Right now when you install one of our Windows packages, it comes from an 'Unknown' publisher which is much more trivial to spoof than one that claims to be from Tor Project, Inc. and has a key/cert/whatever to prove it.

But to reiterate, I think we should explore this in more depth to see what the tradeoffs are. Because although it may be more difficult for someone to build a fake Windows bundle and then claim to be from us, it will also be much more convincing if they pull it off.

comment:6 in reply to:  5 Changed 8 years ago by ioerror

Replying to erinn:

Yes, that is a very good summary of the situation. I don't think I decided not to bother -- it was left as a 'controversial' issue, but I think we should explore it more. Right now when you install one of our Windows packages, it comes from an 'Unknown' publisher which is much more trivial to spoof than one that claims to be from Tor Project, Inc. and has a key/cert/whatever to prove it.

I worry that the attackers may beat us to the punch, what looks better a cert from "Tor Project, Inc." or a binary from "Unknown" parties?

Bah, bad news all around.

But to reiterate, I think we should explore this in more depth to see what the tradeoffs are. Because although it may be more difficult for someone to build a fake Windows bundle and then claim to be from us, it will also be much more convincing if they pull it off.

I'm not sure that I totally understand this argument. It seems to me that it is likely that someone can build our software and currently impersonate "Unknown" - worse, we see that people simply don't even fetch package signatures for most projects that release them. Users are fine with this and don't do any checking almost all of the time, each time they install, I believe they are at risk.

At least if we do Windows package signing, I believe that upgrades need to come from a valid cert chain - so you can't easily trick users into taking a backdoored package if they already had a good one. This is how android package signatures work. It doesn't prevent someone from making an identical app and marketing it but that is a separate issue, I think. I need to verify that it works similarly on Windows.

In any case, I still think that it's better for another reason: the bar for owning a CA to impersonate The Tor Project is a lot more than simply typing "make" and having a package for insertion at MITM or phishing time.

comment:8 Changed 8 years ago by Shondoit

Cc: shondoit+trac.torproject@… added

comment:9 Changed 6 years ago by mikeperry

Keywords: tbb-3.0 added

comment:10 Changed 5 years ago by erinn

Keywords: needs-triage added

comment:11 Changed 5 years ago by ericlaw

https://randomoracle.wordpress.com/2014/05/14/ explains exactly why TOR needs to start doing this.

On Twitter, various CAs have volunteered to donate a certificate and SmartCard so Tor can start signing properly.

Signing with Authenticode will also ensure that new builds of TBB stop getting blocked entirely by Windows SmartScreen (Win8+) and IE (v9+) as unknown/unsafe software; see https://trac.torproject.org/projects/tor/ticket/12678#comment:6

comment:12 Changed 5 years ago by ericlaw

Per this comment: https://trac.torproject.org/projects/tor/ticket/12678#comment:7 work on this bug is in-progress.

comment:13 Changed 5 years ago by Sherief

Cc: Sherief added

comment:14 Changed 5 years ago by cypherpunks_backup

Nothing

Last edited 5 years ago by cypherpunks_backup (previous) (diff)

comment:15 Changed 5 years ago by gk

Cc: gk added
Keywords: tbb-security added; needs-triage removed

As an update on this: we have an Aladdin eToken PRO 72K with a Digicert certificate we plan to use for this. The first problem is we need binary blobs to get the eToken going, something that is called SafeNetAuthentication client. I plan to only use the minimal amount of binary files we actually need and try to get some sha256 sums from some official people. I looked into using OpenSC but our token is not supported: https://github.com/OpenSC/OpenSC/wiki/Frequently-Asked-Questions#q-can-i-use-aladdin-etoken-with-opensc

The second problem is which software should we actually use for signing osslsigncode which would have been my favorite one cannot handle that token yet: http://sourceforge.net/p/osslsigncode/feature-requests/7/. I am not done with evaluating alternatives yet.

comment:16 Changed 5 years ago by mikeperry

Keywords: tbb-usability-stoppoint-app added

comment:17 Changed 5 years ago by tom

Cc: tom@… added

comment:18 Changed 5 years ago by mikeperry

Keywords: tbb-4.5-alpha added

comment:19 Changed 5 years ago by gk

I have not found a suitable tool nor did the DigiCert people (I asked them). Thus, we need some custom code. I guess using osslsigncode is the right decision which gives us two options: 1) We let some PKCS#11 tool do the signing passing it a proper blob and getting that one signed back or 2) We add the necessary PKCS#11 functionality to osslsigncode itself. I think I start with 1) which brings me back to looking for a proper tool. pkcs11-tool does not work with our token for some reason. The version in Ubuntu 12.04 breaks with:

Using signature algorithm RSA-PKCS-PSS
error: PKCS11 function C_SignInit failed: rv = CKR_MECHANISM_PARAM_INVALID (0x71)

and the one built from opensc master breaks with:

Using signature algorithm DES3-MAC
error: PKCS11 function C_SignInit failed: rv = CKR_KEY_TYPE_INCONSISTENT (0x63)

comment:20 Changed 5 years ago by mcs

Cc: mcs added

comment:21 Changed 5 years ago by starlight

A major benefit of signing binaries is that
TBB can be readily whitelisted in AppLocker
(and presumably other whitelist tools).
Please sign all the .DLLs, .PYDs and .EXEs as
well as the actual release bundle .EXE.

I've been experimenting with strict whitelisting
on a system and just upgraded to 4.5a4. Was
some trouble to add hashes for all the files!

With a set of fully signed binaries, one
only has to add the rule to allow the Tor
Project certificate one time. MS's AppLocker
does not check certificate hashes (I'm not
sure if that's good design or not) so if the
attributes of a renewed certificate stay the
same, a TBB "publisher" rule should continue
to work through cert rollovers.

comment:22 Changed 5 years ago by starlight

Cc: starlight.2015q1@… added

comment:23 Changed 5 years ago by starlight

Forgot to mention that some installer
binaries that briefly existed in \Temp
were blocked by AppLocker. Had to
add a temporary "run *" rule to complete
the install. So please include installer
.EXEs and .DLLs, even ones that are
immediately deleted.

comment:24 Changed 5 years ago by mikeperry

Owner: changed from erinn to gk
Status: newassigned

comment:25 Changed 4 years ago by gk

Neither osslsigncode nor disitool get a .exe that matches the original, unsigned .exe (which got signed by signtool as a stopgap until we get our authenticode signing on Linux going) after I stripped the signature. The diff boils down to:

--- /dev/fd/63	2015-03-31 16:45:12.639747705 +0200
+++ /dev/fd/62	2015-03-31 16:45:12.647747512 +0200
@@ -11,7 +11,7 @@
 00000a0: 0050 0000 00ac 0100 2743 0000 0010 0000  .P......'C......
 00000b0: 00a0 0000 0000 4000 0010 0000 0002 0000  ......@.........
 00000c0: 0400 0000 0600 0000 0400 0000 0000 0000  ................
-00000d0: 0060 0400 0004 0000 41b6 0100 0200 0080  .`......A.......
+00000d0: 0060 0400 0004 0000 94b6 2202 0200 0080  .`........".....
 00000e0: 0000 2000 0010 0000 0000 1000 0010 0000  .. .............
 00000f0: 0000 0000 1000 0000 0000 0000 0000 0000  ................
 0000100: 0090 0200 0413 0000 00c0 0300 a894 0000  ................
@@ -2236612,4 +2236612,4 @@
 2220c30: 7d7b 4d5b 0d90 1b6d cff0 0563 5fb0 5f4a  }{M[...m...c_._J
 2220c40: 950a 1208 9218 b015 49a0 05f9 db75 391f  ........I....u9.
 2220c50: 855e 2cec 1272 e4ff ffb1 edbc b0b6 d819  .^,..r..........
-2220c60: f9                                       .
+2220c60: f900 0000 0000 0000                      ........

Smells like last-minute hackery...

Last edited 4 years ago by gk (previous) (diff)

comment:26 Changed 4 years ago by cypherpunks

Nothing

Last edited 4 years ago by cypherpunks (previous) (diff)

comment:27 Changed 4 years ago by gk

Resolution: fixed
Status: assignedclosed

Okay, we shipped 4.5a5 with the authenticode signatures and I guess we are done here. See #15538 and #15539 for some related follow-ups.

comment:28 Changed 4 years ago by starlight

Many file not signed. Does not run with AppLocker "publisher" rule.

Incomplete sample of unsigned files:

AppData\Local\Temp\nsf4B85.tmp\LangDLL.dll
AppData\Local\Temp\nsh8E95.tmp\nsDialogs.dll
AppData\Local\Temp\nsh8E95.tmp\System.dll

Tor_Browser-4.5a5\Browser\firefox.exe
Tor_Browser-4.5a5\Browser\mozalloc.dll
Tor_Browser-4.5a5\Browser\mozglue.dll
Tor_Browser-4.5a5\Browser\gkmedias.dll
Tor_Browser-4.5a5\Browser\mozjs.dll
Tor_Browser-4.5a5\Browser\xul.dll
Tor_Browser-4.5a5\Browser\browser\components\browsercomps.dll
Tor_Browser-4.5a5\Browser\TorBrowser\Tor\tor.exe

comment:29 in reply to:  28 Changed 4 years ago by gk

Replying to starlight:

Many file not signed. Does not run with AppLocker "publisher" rule.

Incomplete sample of unsigned files:

AppData\Local\Temp\nsf4B85.tmp\LangDLL.dll
AppData\Local\Temp\nsh8E95.tmp\nsDialogs.dll
AppData\Local\Temp\nsh8E95.tmp\System.dll

Tor_Browser-4.5a5\Browser\firefox.exe
Tor_Browser-4.5a5\Browser\mozalloc.dll
Tor_Browser-4.5a5\Browser\mozglue.dll
Tor_Browser-4.5a5\Browser\gkmedias.dll
Tor_Browser-4.5a5\Browser\mozjs.dll
Tor_Browser-4.5a5\Browser\xul.dll
Tor_Browser-4.5a5\Browser\browser\components\browsercomps.dll
Tor_Browser-4.5a5\Browser\TorBrowser\Tor\tor.exe

Hmm... Tor Browser does not work with the default AppLocker configuration either, see: https://bugzilla.mozilla.org/show_bug.cgi?id=902771. But it would work with the secure file hash configuration. Maybe that is a good idea anyway if one has high security in mind and is trying to get that via AppLocker. I created #15687 to think about what we want to support.

Note: See TracTickets for help on using tickets.