Chrome Native Message Host Security

883 views
Skip to first unread message

Rodrigo Passos

unread,
Apr 8, 2015, 1:55:05 PM4/8/15
to chromium-...@chromium.org

I'm developing an application using Chrome Native Messaging that starts through a Chrome Extension.

My question is: How can I ensure that host application is really the same supplied by me?

I need to ensure the authenticity the application called by extension. I asked about this problem and people told me to sign host files and check its authenticity within extension. But if somebody changes the chrome application target in registry, would be possible start another different application. 

Is there any way to get the path pointed ID supplied during extension connection recorded in the registry. If I had this path, I could validate the json file and ensure that real target is executing.

These problems refer to the same security problems faced by the NPAPI plugin, where it is not possible to determine the transaction's authenticity.

Reilly Grant

unread,
Apr 8, 2015, 2:02:58 PM4/8/15
to Rodrigo Passos, chromium-...@chromium.org
The simple answer is that you can't. A determined attacker can always disable any mechanism used by two local applications (the extension and the native message host) on a system that they have local control of. You can implement all the encryption and signing between the two halves of the application that you want but it will not be 100% secure.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/d6983ab1-13a3-4d26-a438-5af7079dff6e%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

Rodrigo Passos

unread,
Apr 8, 2015, 2:14:41 PM4/8/15
to chromium-...@chromium.org, barcel...@gmail.com
But the Chrome extension doesn´t run in a sandbox? If I change something in the extension it break, or not?


Em quarta-feira, 8 de abril de 2015 15:02:58 UTC-3, Reilly Grant escreveu:
The simple answer is that you can't. A determined attacker can always disable any mechanism used by two local applications (the extension and the native message host) on a system that they have local control of. You can implement all the encryption and signing between the two halves of the application that you want but it will not be 100% secure.

On Wed, Apr 8, 2015 at 10:55 AM Rodrigo Passos <barcel...@gmail.com> wrote:

I'm developing an application using Chrome Native Messaging that starts through a Chrome Extension.

My question is: How can I ensure that host application is really the same supplied by me?

I need to ensure the authenticity the application called by extension. I asked about this problem and people told me to sign host files and check its authenticity within extension. But if somebody changes the chrome application target in registry, would be possible start another different application. 

Is there any way to get the path pointed ID supplied during extension connection recorded in the registry. If I had this path, I could validate the json file and ensure that real target is executing.

These problems refer to the same security problems faced by the NPAPI plugin, where it is not possible to determine the transaction's authenticity.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

Matt Seil

unread,
Apr 8, 2015, 2:46:06 PM4/8/15
to Rodrigo Passos, chromium-...@chromium.org
Meant to share this with the list:

Rodrigo,

The condition you state here:  "But if somebody changes the chrome application target in registry, would be possible start another different application."

Alterations to the Windows registry can only be done by someone with admin-level access to the machine.  If they have access to alter the registry they also have access to alter your extension.  You can't defend against this. 

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/d6983ab1-13a3-4d26-a438-5af7079dff6e%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.



--
Matt Seil
Cyber Security Software Engineer
Member ACM/OWASP

Rodrigo Passos

unread,
Apr 8, 2015, 3:42:37 PM4/8/15
to chromium-...@chromium.org, barcel...@gmail.com, xeno...@gmail.com
Matt.

We are working in a financial application that uses a smart card to sign transactions and they involve money. Before using Chrome extension, we used Java/NPAPI plugin to communicate with smart card readers, but after it deprecated, the only alternative was Chrome Extension with Native Messaging.

We know that anything application is 100% secure, but we would like to ensure a mininum level of security, where it is not too easy for a attacker to modificate our application. Our current solution (Java/NPAPI) the JRE ensures that applets weren't modified, ok, teorically a attacker could change the JRE, but this is more difficult.

The new solution don't have something like JRE applet verification, we believe that is easier for a attacker compromised the application.

Therefore we would like of implementing a mechanism with the same Java securiry level or near.

Do you suggest anything?


Em quarta-feira, 8 de abril de 2015 15:46:06 UTC-3, Matt Seil escreveu:
Meant to share this with the list:

Rodrigo,

The condition you state here:  "But if somebody changes the chrome application target in registry, would be possible start another different application."

Alterations to the Windows registry can only be done by someone with admin-level access to the machine.  If they have access to alter the registry they also have access to alter your extension.  You can't defend against this. 
On Wed, Apr 8, 2015 at 12:55 PM, Rodrigo Passos <barcel...@gmail.com> wrote:

I'm developing an application using Chrome Native Messaging that starts through a Chrome Extension.

My question is: How can I ensure that host application is really the same supplied by me?

I need to ensure the authenticity the application called by extension. I asked about this problem and people told me to sign host files and check its authenticity within extension. But if somebody changes the chrome application target in registry, would be possible start another different application. 

Is there any way to get the path pointed ID supplied during extension connection recorded in the registry. If I had this path, I could validate the json file and ensure that real target is executing.

These problems refer to the same security problems faced by the NPAPI plugin, where it is not possible to determine the transaction's authenticity.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

Reilly Grant

unread,
Apr 8, 2015, 3:45:20 PM4/8/15
to Rodrigo Passos, chromium-...@chromium.org
Yes and no. The sandbox is designed to protect the system from the extension not the other way around. Chrome does validate that the extension has not been modified since it was downloaded from the Chrome web store but again, this is a mitigation not a guarantee in the face of a local attacker. I can run a modified Chromium build that disables these checks.

If you assume that the local system is secure then the protections against unauthorized modifications to the system registry are enough. Chrome does validate that the extension trying to contact the native messaging host is listed in the manifest file referred to in the registry.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

Rodrigo Passos

unread,
Apr 9, 2015, 12:36:27 PM4/9/15
to chromium-...@chromium.org, barcel...@gmail.com
Anybody have another sugestion to have more protection?


Em quarta-feira, 8 de abril de 2015 16:45:20 UTC-3, Reilly Grant escreveu:
Yes and no. The sandbox is designed to protect the system from the extension not the other way around. Chrome does validate that the extension has not been modified since it was downloaded from the Chrome web store but again, this is a mitigation not a guarantee in the face of a local attacker. I can run a modified Chromium build that disables these checks.

If you assume that the local system is secure then the protections against unauthorized modifications to the system registry are enough. Chrome does validate that the extension trying to contact the native messaging host is listed in the manifest file referred to in the registry.

On Wed, Apr 8, 2015 at 11:14 AM Rodrigo Passos <barcel...@gmail.com> wrote:
But the Chrome extension doesn´t run in a sandbox? If I change something in the extension it break, or not?


Em quarta-feira, 8 de abril de 2015 15:02:58 UTC-3, Reilly Grant escreveu:
The simple answer is that you can't. A determined attacker can always disable any mechanism used by two local applications (the extension and the native message host) on a system that they have local control of. You can implement all the encryption and signing between the two halves of the application that you want but it will not be 100% secure.

On Wed, Apr 8, 2015 at 10:55 AM Rodrigo Passos <barcel...@gmail.com> wrote:

I'm developing an application using Chrome Native Messaging that starts through a Chrome Extension.

My question is: How can I ensure that host application is really the same supplied by me?

I need to ensure the authenticity the application called by extension. I asked about this problem and people told me to sign host files and check its authenticity within extension. But if somebody changes the chrome application target in registry, would be possible start another different application. 

Is there any way to get the path pointed ID supplied during extension connection recorded in the registry. If I had this path, I could validate the json file and ensure that real target is executing.

These problems refer to the same security problems faced by the NPAPI plugin, where it is not possible to determine the transaction's authenticity.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsubscribe...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

Matt Seil

unread,
Apr 9, 2015, 1:30:00 PM4/9/15
to Rodrigo Passos, chromium-...@chromium.org
"The new solution don't have something like JRE applet verification, we believe that is easier for a attacker compromised the application.

Therefore we would like of implementing a mechanism with the same Java securiry level or near.

Do you suggest anything?"

You need to know what your threat model it is, and who you're trying to protect against with what level of financial resources.  If you're worried about a registry key, then you're defending against a sysadmin with physical control the machine. 

You're hosed at that point.  There's nothing you can do. 

If you're worried about someone modifying your native application, you have some choices, but it depends *heavily* on what kind of infrastructure and what technologies you're already using. 

I do this kind of work (attacking applications), and I'm going to tell you this:  Your company needs to hire a dedicated pentester and create its defenses with that level of professional input.  There are enough corner cases that can be uncovered here that to get the best solution you really have to have a dedicated SME who understands YOUR application and requirements enough to help you grow the best solution. 



Michael Geary

unread,
Dec 4, 2017, 9:00:12 PM12/4/17
to Chromium-Extensions-Announce, barcel...@gmail.com, xeno...@gmail.com
On Wednesday, April 8, 2015 at 11:46:06 AM UTC-7, Matt Seil wrote:

Alterations to the Windows registry can only be done by someone with admin-level access to the machine.

I'm jumping in late here, but for future readers, I wanted to note that this is incorrect. The HKEY_LOCAL_MACHINE (HKLM) registry hive does require administrator privileges, but HKEY_CURRENT_USER (HKCU) does not. Any user can write to their own registry hive.

This is commonly used to allow applications to be installed "per user" without requiring elevation. For example, Slack and other apps that use the Squirrel installer write their installation information to HKCU instead of HKLM, so any user can install and update them without UAC prompts.

The Native Messaging documentation notes that the manifest file registry value can be written either to HKLM or HKCU:

The application installer must create registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.my_company.my_application
or
HKEY_CURRENT_USER\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.my_company.my_application


Reply all
Reply to author
Forward
0 new messages