mjhjmtu

I have noticed that Firefox and Chrome have opened ports for unsolicited inbound traffic in the Windows firewall. This happened with Windows 7 x64 and Windows 10. (Here, I am talking about the standard firewall integrated in recent Windows versions, not some third-party product).

Normally, when a program tries to change the firewall configuration, I get a notification (dialog box) on the desktop asking me if I would like to allow that action. But with Firefox and Chrome, things are different:

I regularly delete all rules for Firefox and Chrome from the firewall configuration. However, each time those browsers update themselves (which is quite often), they re-create those rules without the usual confirmation dialog appearing.

I do not understand how this is possible. I currently suspect that the rules are recreated not by Firefox or Chrome themselves, but by their maintenance (update) services which are running in the background, probably with administrative rights.

I do not want Firefox to add rules to my firewall to let unsolicited inbound traffic pass to itself to any port from any address for TCP and UDP. Likewise, I do not want Chrome to add rules to my firewall which let unsolicited inbound UDP traffic pass to itself to a certain port, but also from any address. I am considering that a big security breach given the many security vulnerabilities of the browsers.

Hence the question: How do I prevent Firefox and Chrome and their maintenance / update services from silently adding rules to the Windows firewall?

I have seen that I could control the firewall by group policies, but this seems kind of extreme to me when the only reason would be the problem described above. My clients are not part of a domain, so I would have to do this on each of them. Furthermore, I am not sure if the browsers and their maintenance / update services are able to circumvent the group policies as well.

Steps to reproduce:

• Install Firefox




• Install Chrome




• Open the GUI for the Windows firewall management ("Windows Firewall with advanced security")




• On the left, select "Inbound rules"




• A list of rules appears on the right; notice two rules whose name begins with "Firefox" and one rule whose name begins with "Chrome"




• When you double-click one of the rules, a dialog box appears where the rule's properties, the ports being opened, the program which is allowed to receive that traffic and so on are detailed




• Note that the two rules for Firefox are nearly identical; the only difference is that one is for TCP, the other for UDP. Both allow unsolicited inbound traffic from any address to any port to Firefox.




• Note that the rule for Chrome lets pass UPD traffic from any address to port 5353 to Chrome.




• Delete the three rules mentioned above




• Wait until a Firefox update is available and install it




• Note that the two rules for Firefox are re-created when installing the update without any confirmation dialog appearing




• Wait until a Chrome update is available and install it




• Note that the rule for Chrome is re-created when installing the update without any confirmation dialog appearing

Hint: When testing, please be aware that you might need to right-click on "Inbound Rules" at the left and select "Refresh" from the context menu to actually see the newest updates to the rules which might have been done in the background by services or applications.

Hint 2: In fact, if you want to test this, you don't need to wait for the next Firefox or Chrome update. Just install an old version of the browsers and make sure that the firewall rules mentioned above have been created, then delete those rules. Because you have installed old versions, updates will be available immediately. Install the updates and note that the firewall rules have been silently re-created.

One option would be to use Windows access controls to prevent changes to the firewall rules. If you first set the rule to Disabled (or simply deleted it), and then changed the ACLs on the firewall rule storage, it should be possible to avoid the rules re-appearing. While any administrator account could overwrite or bypass your modified ACL, it is highly unlikely that an automated installer would endeavor to do so, and consequently the attempts to change the firewall would simply get "Access Denied".

The good news is that the firewall rules are stored in a predictable location, HKLMSYSTEMCurrentControlSetServicesSharedAccessParametersFirewallPolicyFirewallRules. They are even entirely human-readable, aside from their names, which are GUIDs; the actual rules are pipe-delimited English text (I am now curious what happens if I make a firewall rule with a pipe character in its description).

The bad news is that the rules are stored as values on a single key (the one given above), and registry ACLs are only available at the granularity of keys. This means that if you deny an account write access to that key, you deny that account the ability to change any firewall rule. This could impair functionality in a number of ways; in the extreme, you would need to manually change the ACL on that key before making any firewall rule changes yourself.

The ideal way to do it would be to use a Deny access control entry for the account that you want to block. Deny entries take precedence over Allow entries for a given specificity level (if an account is both allowed and denied an action, deny wins), and specific (account) similarly wins out over generic (Group). Thus, you can add a Deny entry for a specific account to block that account, without also doing something awkward like blocking the entire Administrators group. Unfortunately, all four Mozilla- or Google-related services installed on my machine (MozillaMaintenance, GoogleChromeElevationService, gupdate, and gupdatem) are configured to run as LocalSystem (a.k.a. SYSTEM). Blocking SYSTEM write access to that key might not be disastrous - in fact, blocking SYSTEM from writing to select registry keys is a common way to keep an admin from making specific changes to a machine via Group Policy - but it would probably break some things. If you end up needing to block actions which are elevated via normal UAC you would need to block either yourself or the Administrators group, and that's even more awkward than blocking SYSTEM.

A solution would be to create a new admin-level service account on the machine, and then modify the Google & Mozilla services to use that account and block that specific account at the registry key. This is not trivial - especially if the services rely on any of the special permissions of being SYSTEM, which by default even the Administrator account does not get all of (though this can, of course, be changed) - but it could be done.

You could also try removing the browsers (and any associated services, manually if needed) and re-installing them using unprivileged installers. This would limit their installer blast radius to your local account, and give them no way to elevate unprompted. Firefox supports portable installs, and Chrome actually used to by default install to your user profile (not your Program Files directory) using a per-user install, so in theory it should be possible to install either one without giving the installer admin rights. Nothing without admin rights can create a way to get admin rights (without a UAC prompt or an EoP vulnerability), so they would not have the ability to silently mess with your firewall, and they would probably not even try (after all, a program installed without Admin can be updated without Admin, and a non-Admin can't change the firewall).

You have reached one limit on computer security. Best practices ask to only allow elevated priviledges for so called trusted programs. But we all know that for common usage, we have to trust the OS and the browser^(*). The problem that your are facing is that is one of this products does something that you do not like, little can be done: once you have allowed elevated priviledges, the system offers no additional protection.

I can hardly imagine a truely preventive strategy here because it is hard to guess what an installation procedure could do, and I know nobody that could say that they can detect and understand any change on a windows system. But when one problem has been identified,
workarounds are often possible. Here I can imagine:

• group policies as you said. BTW, if you have many client machines, you should really considere using AD. You do not even need a AD server license for that because recent versions of SAMBA provide it. And AD can really add a lot when it comes to client machine security


• automate the process of detecting/resetting the firewall rules. Once automated it will appear as an additional step of the browser upgrade


• use a dedicated firewall (a dedicated machine) and implement the firewall rules there.


• maybe others I could not imagine...

Which one will be the more relevant will heavily depend on the real use case...

The best way would be to ask the editors to stop silently opening firewall rules, but I am afraid that this request is unlikely to succeed: there are certainly good reasons for those rules. That is the reason why I only searched for workarounds.

I do not mean here that the browser will run with evelated proviledges, but every updgrade does requires them. And for security reason we cannot use outdated software...