Re: Native Messaging (Was: Core API Proposal)

2016-05-04 20:14 GMT+02:00 Anders Rundgren <anders.rundgren.net@gmail.com>:
>
> On 2016-05-04 14:38, Rob Wu wrote:
> > What advantages / disadvantages does your proposal have over using
> > nativeMessaging + allowing https: in the allowed_origins list? For
> > the syntax, see
> https://developer.chrome.com/extensions/nativeMessaging#native-messaging-host
>
> My primary (and rather big) "problem" with Chrome's native messaging is
> that such an
> extension consist of two separate software packages with no apparent (or
> secure) binding.
>

There is a binding: Only extensions in the allowed_origins list can use the
native app.
I re-iterate my question, can you state objective advantages/disadvantages
of your proposal over native messaging?


> Technically, it is possible to offer the
>> chrome.runtime.connectNative/sendNativeMessage
>>
> > to web pages. I guess that this was not allowed yet because of security
> concerns:
> > Extensions can be reviewed and approved/rejected, there is no such
> review process for web pages.
>
> After installing the by Google "approved" Web2Native Bridge extension, no
> such limitations exist:
> https://chrome.google.com/webstore/search/web2native
>

The extension itself cannot do anything harmful. Users have to install the
native component before anything bad could happen.
if users install the native app, which trusts the extension (via
allowed_origins), then the user trusts that the native app and its
corresponding extension behaves well.

If the native messaging component were to be bundled with the add-on,
manual review (like Firefox' add-on gallery) is required, because it's then
the galleries responsiblity to make sure that the offered
apps/extensions/add-ons are safe.

Manual review is not infallible, and mistakenly granting approval is not
specific to nativeMessaging - in fact, your proposal has the same problem
in the unspecified "vetting infrastructure".


>     A security review of Google's take on this matter:
>>
>> https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html
>>
>>
>> The main claim of your "security review" is that a native program can
>> enable
>>
> > any program to execute native code (without asking for permission)
> because
> > there is no vetting what a native extension actually does.
>
>> This scenario occurs when all of the following have happened:
>> 1) The user installs a malicious native program.
>> 2) The malicious native program is registered as a native messaging host.
>> 3) The user installs an extension that uses (Chrome's) native messaging
>> API.
>> 4) Web pages can use the native code execution capabilities if the
>> extension acts as a proxy between the web page and native program.
>>
>> Step 1 and 2 requires the user to put malicious files in specific
>> directories,
>>
> > and step 3 requires explicit user consent via a permission dialog upon
> installation.
>
>> If a user went through steps 1 and 2, odds are that an attacker can
>> already run
>>
> > arbitrary code (and compromise the user's computer). The presence of the
> native
> > messaging API does not degrade the security in this respect.
>
> You're right.  What my demo program shows is that the "approval" process
> is insufficient.
> And if it actually did work what would the result be?
>

If the review process did work, then in terms of security the result is
equivalent to extensions + properly functioning review process. To make a
fair comparison, either assume that both review processes are flawed, or
that they're both doing well.


> Compared to native messaging, I think that your Web2native proposal is
>> 1) more complex (new infrastructure for vetting, a new "AppStore")
>>
>
> It requires
> - a new infrastructure for wetting
> - an OS-dependent solution for adding needed meta-data to executables.
>
> But it should (hopefully) not require a new "AppStore"


New infrastructure for vetting is expensive. Let's think more concretely
what this would look like. After the vetting, there will be a cryptographic
signature that attests that the application is vetted and that it may run.
How is this any better than signed add-on packages that are only published
by the extension galleries once approved?

Yes, this is a lot of work.  Unfortunately there's no other way if we are
> talking about a "solution" rather than the current "workaround".
>

Can you elaborate, in what sense is native messaging a "work-around" and
your proposal a "solution"? What problems does your proposal solve that is
not already addressed by native messaging (with reasonable trade-offs)?


>
> Such a solution would also (depending on platform vendor
> cooperativeness...)
> also work with alternative browsers.
>

Only if they implement Web2Native and trust the vetting process. Different
platforms have different ideas about the kind of acceptable programs. For
instance, YouTube downloaders are allowed in Firefox but not in Chrome.


> 2) not more secure (native messaging requires user consent through an
>> install-time permission dialog)
>>
>
> The *emulator version* of the Web2Native Bridge "inherits" the following
> from Native Messaging
> - No native application vetting infrastructure
> - No HTTPS information
> - No site-blocking support and associated administration
>
> in addition to injecting JavaScript in every web-page visited!
>

You didn't refute my claim that native messaging is at least as secure as
Web2Native. Maybe I was not clear - as an example, I showed that native
messaging has an extra requirement that Web2Native does not have, namely an
install-time permission dialog.

The four things that you mentioned are not a limitation of native
messaging, but rather your specific implementation. If you had enough time,
you could implement all of the four things on top of native messaging to
achieve what you want. And this is my main point: Except for the
inconvenience of separately installing native programs, native messaging is
a reasonably secure primitive that can be used as a foundation for other
programs (e.g. your Web2Native bridge). If you want to get your proposal to
succeed, you have to demonstrate that its added complexity is warranted by
its merits (or even better: that it does not add complexity).


> By design, the nativeMessaging API of Chrome may support more than one
>> communication
>>
> > protocol (as defined in the native messaging host manifest). So if it
> ever becomes
> > necessary to add this kind of information in the protocol, just define a
> new protocol.
>
> If the IPC mechanism for some reason would need to change, I don't think
> applications
> should be affected.  The Web2Native Bridge emulator [primitively]
> abstracts the channel:
>
> https://github.com/cyberphone/web2native-bridge/blob/master/proxy/src.java/org/webpki/w2nbproxy/StdoutJSONPipe.java
>

I showed the possiblity of adding new protocols *when necessary* (e.g. if
JSON is an ill-suited transport method). Adding a new protocol does not
change existing ones (currently "stdio" is the only protocol). Your Java
implementation abstracts by wrapping the message in another packet, this is
a way to use the existing protocol without changes.


> IMO, the nativeMessaging API is well-designed
>>
>
> The API (and associated "config") is pretty awkward to master compared to
> the Web2Native Bridge:
> https://github.com/cyberphone/web2native-bridge#api



The client API doesn't look that different from native messaging:
https://developer.chrome.com/extensions/nativeMessaging#native-messaging-client
I agree that the config is inconvenient for developers (and users who need
to install both components before they can use it), and that is where this
CG might bring some improvements.

and receptive to enhancementsif ever needed.
>>
>
> Great, can we have caller security context?
>

Although not documented, the origin of the caller is already passed as an
argument to the native application (
https://chromium.googlesource.com/chromium/src/+/c963c714c99f34bd80b392d9896ca9cecd66fb6d/chrome/browser/extensions/api/messaging/native_process_launcher.cc#192
).
But by receptive to enhancement, I was referring to the flexible stdio
protocol and the ability to define new protocols if needed.


> The main issue with using native messaging is deploying it, since users
>>
> > have to separately install an extension and native app.
>
> Indeed. And then there is the vetting...
>

... which can be integrated in extension stores and don't have to be a
separate infrastructure. See my previous comment about the single
cryptographic signature, and the deducation that the existing
infrastructure suffices.


If you want to standardize native messaging,
>>
>
> I'm not alone, this is one of the goals with the browserext CG as well.
>

"you" as in whoever who wants to turn a native messaging API into a
standard that gets implemented by more than one vendor.


> I suggest taking the nativeMessaging API as-is
>>
> > and specify a standard way to include the binary in the extension
> package.
>
> I think you should confront Google with this proposal, I'm not sure they
> would
> be entirely happy with it but I could be wrong.
>

If we demonstrate that the proposal is *at least as secure* and simpler
than the status quo, then I think that there is a reasonable chance of
adoption. It has to not only be simple for devs/users, but also for
(automated) reviewers in the Chrome Web Store.

BTW, Chrome for Android does not support any extensions AFAIK.
>

If Chrome Mobile doesn't support extensions, the odds of getting Web2Native
accepted is even smaller.
The closest alternative to running native code is Google's own
NativeClient, and that is not supported either.


> Editors of extension galleries MUST review sources for the binary and
>> confirm
>>
> > that the native component behaves well.
>
> Apple won't rely on that, and neither would I.
>

Apple is the editor of their extension gallery ("editor" as in "the one who
is in charge of the store"), so they do rely on the review process
(otherwise they could as well close down the store).
If you refuse to accept that the review process is reasonable, then your
own proposal also falls down because its security requires a properly
functioning vetting process, which is similar if not identical to the
app/extension review process.

> so the use of native messaging should not be encouraged unless absolutely
> necessary.
>
> Unfortunately it is currently not possible creating a useful Web payment
> systems
> for mobile phones (aka Wallets) so there will be a gazillion of such
> extensions.
>

And if Web2Native were to be implemented, then there will be "a gazillion
of such apps"...
Since your main objective is getting support for web payment systems in
browsers, maybe you should join the Web Payments CG?