1267362 - Provide code signature validation of native messaging host executable

Status: UNCONFIRMED

(WebExtensions :: General, defect, P3)

Description

[Jamie Phelps]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/601.5.17 (KHTML, like Gecko) Version/9.1 Safari/601.5.17

Steps to reproduce:

Following up on aswan's request for additional information on native messaging host security in Bug 1190682. The current situation in Chrome is that Chrome provides no validation of the native messaging host files. See this bug for a full description of the problem:  https://bugs.chromium.org/p/chromium/issues/detail?id=514936 Firefox can and should do better.

After discussing this with our security lead, we realized that something as simple as an (optional?) array of code signature strings in the manifest.json file could provide Firefox with enough information to validate the native messaging host. 

So, the flow would be:

0. Extension calls chrome.runtime.connectNative
1. Firefox locates the native messaging host manifest file for the request.
2. Firefox locates the executable file at the path specified by the native messaging host manifest file.
3. Firefox checks extension's manifest.json for the code signature validation key, e.g. nativeMessagingCodeSignatures.
4. Firefox computes the code signature with each given requirement string until a passing validation.
5. If the code signature cannot be validated, Firefox must not launch the executable.

An example of the strings that would be included would be:

    anchor apple generic and identifier com.agilebits.onepassword.nativemessaging

and then the command line validation of that would be:

   codesign -vvv -R="anchor apple generic and identifier com.agilebits.onepassword.nativemessaging" /path/to/host/from/json-file

On OS X, the validation can be achieved with SecCodeCheckValidity function from the Security framework. I know Windows has similar facility for validating code signatures as well. I have no idea about Linux's support for this.

[1]: https://developer.apple.com/library/mac/documentation/Security/Reference/CodeSigningRef/#//apple_ref/c/func/SecCodeCheckValidity

Comment 1

[Andrew Swan [:aswan]]

This seems reasonable on the face of it, but if an attacker can alter the host manifest or replace the executable, what stops them from also modifying the extension manifest to alter or remove the property that enables the signing check?

Comment 2

[Jamie Phelps]

Firefox requires signed xpi's, yes? And is it wrong to presume that Firefox will not load an xpi whose signature can't be validated? The difference between the host manifest and the extension manifest is that one is part of a codesigned bundle and the other is an arbitrary file on the filesystem.

I realize that if the attacker replaces Firefox, then it's turtles all the way down, but if Firefox is installed in /Applications (on Mac), then replacing it with another binary requires escalated privileges.

Comment 3

[Andrew Swan [:aswan]]

(In reply to Jamie Phelps from comment #2)
> Firefox requires signed xpi's, yes? And is it wrong to presume that Firefox
> will not load an xpi whose signature can't be validated? The difference
> between the host manifest and the extension manifest is that one is part of
> a codesigned bundle and the other is an arbitrary file on the filesystem.

Yes, of course, sorry I wrote the last comment to hastily.
Lets get feedback from somebody more qualified than me to evaluate this.

(to be clear, we're still doing the planning for connectNative, even if we have agreement from the security angle, we have to consider compatibility with chrome and the w3c webext group, and find time to do the actual work.  I think these things are all doable but just want to make sure we're clear on all the steps)

Comment 4

[Daniel Veditz [:dveditz]]

Looks like the original Chrome implementation restricted these to typically admin-controlled directories and windows registry keys. About a year later they added support for user-area native hosts, but they also have support for an admin setting to restrict it back to system-level native hosts. (They also support a blacklist and a whitelist for specific hosts which is a nice feature, but not relevant here.)
https://www.chromium.org/administrators/policy-list-3#NativeMessaging

We could ignore the user-area native hosts for now and require admin-installed ones, and still be more or less compatible with Chrome. That's not a lot of protection because users will generally grant admin privs to any installer they've launched on purpose, and then that installer could do whatever evil you're afraid of (including messing with Firefox or its ability to protect against dodgy native hosts).

Prior to WebExtensions how do you handle this with current add-ons or using the NPAPI plugin interface? Firefox will load plugins promiscuously and there's no guarantee you're talking to the one you think you are. Ditto ctypes.

Comment 5

[Jamie Phelps]

Currently, 1Password relies on WebSockets for the connection to the native applications. This has a few problems, and it is one of the reasons we are so keen to explore a more secure implementation of native messaging.

Comment 6

[Jamie Phelps]

I posted my previous comment too hastily…

We've discussed some of the problems from a security standpoint on our blog[1] and given what we know now about Firefox and Chrome's willingness to let add-ons of different kinds set forbidden headers[2], we know we need to move away from this approach.

In addition to security concerns, the WebSocket connection from the 1Password extension to the native application is frequently thwarted by various proxy configurations, flagged and blocked by antivirus software, and otherwise prevented from making the connection properly, and this accounts for a large portion of our support requests, especially on Windows and a significant portion of some of our team's time in talking to various security software vendors to explain why 1Password should not be flagged as malware.

[1] https://blog.agilebits.com/2015/06/17/1password-inter-process-communication-discussion/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1257989#c2

Comment 7

[Anders Rundgren]

The #1 problem is that the native messaging concept in Chrome is a "Workaround", not a solution.

http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/

Therefore Google will NOT implement this in Android so Mozilla is effectively building dead code.   I did several attempt raising this issue in W3C but nobody were "Brave" enough to continue:
https://lists.w3.org/Archives/Public/www-tag/2015Apr/0053.html
https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html

COMBINING the power of the Web and App worlds is not such a poor idea!  The war against "Apps" is of no interest to the market.

Comment 8

[Anders Rundgren]

Related: https://bugs.chromium.org/p/chromium/issues/detail?id=614658

Comment 9

[Anders Rundgren]

https://blogs.windows.com/msedgedev/2016/02/03/2016-platform-priorities/#extensions

  "Any browser extensibility is a potential vector for malicious software,
   and our extensions will be vetted, delivered, and managed through the Windows Store"

If this actually true, Edge cannot simply copy Chrome's Native Messaging since there is no secure binding between the extension and the native component.

Google do not even ask for the latter, I guess they are just hoping that developers are honest...