Re: Native Messaging (Was: Core API Proposal)

On 2016-05-04 14:38, Rob Wu wrote:
> 2016-05-04 8:44 GMT+02:00 Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>:

Hi Rob,

Than you very much for looking into the Web2Native Bridge proposal!

Anyway, although you don't not share my view of how Native Messaging
should be implemented, I take the liberty of commenting your comments :-)

First off, Android does not support Native Messaging and my interest is
primarily in that space.

>
>     Hi Guys,
>
>     This is another and implemented proposal for Native Messaging which you can test if you want.
>
>     It is based on the idea that a native extension is a standard executable augmented
>     with meta-data indicating for the Browser/OS platform that it is intended (maybe even
>     certified) for being callable from the "open Web":
>
>     https://github.com/cyberphone/web2native-bridge
>
>     That is, IMO, native messaging should be separated from "in-browser" extensions.
>
>
> Currently only Chrome extensions and apps can use nativeMessaging because
 > only the chrome-extension:-scheme is accepted in the allowed_origins list.
 > 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.


> 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

>
>     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?


> Now, how does your Web2Native system work (based on the Github page and web2native-bridge.pdf)?
> 1) The user installs a vetted native program (vetted = complete new infrastructure, TBD).
> 2) As a part of the installation, a the entry point is stored in proxy/install/apps/
> 3) Web pages can use the native code execution capabilities if the Web2Native proxy allows it.

See point #2 below


> 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"

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".

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


> 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!

>
> The Web2Native proposal also includes unnecessary parameters such as "coordinates of the calling web page".
 > If an application needs it, they can include it in the message.

Well, that is a fairly smallish issue.  Applications will need it if they want native extensions
to become a part of the Web like my demo application.  It must be possible to at least
float on the invoking page. Chrome's take on Native Messaging does not care about such details.


> 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

>
> 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


> and receptive to enhancementsif ever needed.

Great, can we have caller security context?


> 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...


> If you want to standardize native messaging,

I'm not alone, this is one of the goals with the browserext CG as well.


> 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.

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


> 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.


> This is a burden for reviewers,

Yes, it might not even be free.  This is up to each platform vendor to decide.


 > 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.

Google, Facebook and similar super providers will surely use this as well.

Kind regards
Anders


>
> Kind regards,
>  Rob
>  https://robwu.nl

Received on Wednesday, 4 May 2016 18:15:09 UTC