Hello!
Is it possible to restrict the extension to communicate only with the native messaging host placed in the system-wide location?
For example, on macOS there is a global location /Library/Application Support/Mozilla/NativeMessagingHosts/name.json
and per-user ~/Library/Application Support/Mozilla/NativeMessagingHosts/name.json
What is going to happen when the same messaging host manifest is place in both user-specific and system-wide locations? Is there documentation which manifest takes prevalence?
As far as I can tell, the Chromium native messaging API does not let the extension decide to which native messaging to connect to. It manages the discovery part on its own.
BR, Arthur
1 Like
You should be able to set which extensions can communicate with Native Nessaging host using "allowed_origins"
key and value.
Hey,
Yes. That part is already configured exactly like that.
The problem is that if there is a messaging host “com.company.host” in the system-wide location and a messaging host “com.company.host” in the user-specific location, then Firefox connects to the one in the user-specific location.
I am wondering if there is a way to prevent that. This is a low risk due to the fact that the user specific location is accessible for the user. So you don’t need elevated privileges to create a fake/malicious messaging host in the user specific location and the browser will start using it instead of the correct/original one in the system-wide location.
So the flow looks like this:
- Extension asks native messaging API to connect to host “com.company.host”.
- Firefox find the malicious host In the user-specific location which has the same name and uses that.
What I would like to happen is to tell native messaging API to ignore user specific location and always use system-wide.
From what I saw so far, it is not possible which is not ideal
BR, Arthur
How is that possible? The Native Messaging host is located on the users’ machine, and thus cannot be malicious unless the user writes the code to make it so - then the user would be effectively malicious to themselves, nullifying any concern.
The simplest way to achieve the requirement is to name the hosts differently.
Yes. I agree that the exploitation of this behavior is not trivial. An attacker needs to have local code execution on the machine to trigger it.
Just to be clear, there is no business need to have a messaging host in the user-specific location. Especially a one different from the system-wide location.
I was just curious if there is an easy way to instruct the extension or the native messaging API to ignore contents of user-specific messaging host location.
But sounds like this is not possible.
Is the behaviour a macOS bug?
Why are there two (2) locations for Native Messaging hosts?
Why do they have the same name?
How do you know if you are logged in as user or system-wide (administrator)?
I do not understand how this case is an exploit.
User or administrator complicity is required for the user or administrator to exploit themselves.
How did you even conceive of this context (as an exploit)?
Is the behaviour a macOS bug?
no. this is an implementation detail of native messaging discovery
Why are there two (2) locations for Native Messaging hosts?
because native messaging api takes both into account. And moreover, it gives preference to the user specific one. Why? Is it possible to affect this behavior?
Why do they have the same name?
this is what an attacker will try to do to man-in-the-middle the communication
How do you know if you are logged in as user or system-wide (administrator)?
You don’t need to. You just need normal user rights to drop a malicious manifest to the user Library folder. No elevation is needed for that