1890954 - Applocker is preventing instances of firefox even when whitelisted

Status: ASSIGNED

(Core :: Security: Process Sandboxing, defect, P2)

Description

[roman.marik]

Attachment: Detail provided from MS Engineer

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 Edg/123.0.0.0

Steps to reproduce:

1. Setup a Windows 10 Enterprise 22H2 or Latest Windows 11 build.
2. Setup another remote machine to create SMB share where you need to place the Firefox program.
3. Use local group policy (gpedit.msc) to create Applocker policies. (Use publisher rule for Firefox.exe. There is no need to setup path rule as we are able to reproduce the issue using publisher policy itself)
4. Create two scenarios, working and non working. Running Firefox.exe from local folder will be working scenario. Running Firefox.exe from smb share will be non working scenario.
5. Firefox vendor can capture their own data and do the investigation, leveraging the inputs that we have given below.

Actual results:

There are prevented instances of firefox while it is whitelisted in applocker.

1. Using path rule breaks firefox, rendering it unusable.
2. Publisher rule doesnt affect functionality, but it is still filling logs with prevented executions.
   Firefox is launched from smb share.

Expected results:

Whitelisting firefox on network share should allow all instances. Applocker was troubleshooted from microsoft support - conclusion is in attached file. Analysis was done using symbols and and Firefox Public symbols/code.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Bob Owen (:bobowen)]

I'll take a look at this as soon as I have time to set things up for the testing.
As an aside, running from a network drive is already not totally ideal as we have to make changes to the sandbox for this, which is what the Microsoft engineers are seeing.

I believe Chromium (Chrome/Edge/etc.) based browsers don't run at all from a network drive, although I haven't tested this in a while.
The only way you used to be able to get them to work was to turn off the sandbox completely, which is definitely not advised.

Comment 3

[Bob Owen (:bobowen)]

Roman - could you provide a little more detail about steps 2 and 3 in you STR, please.
I've tried running Firefox from a network drive with AppLocker enabled and the rules you describe, but I don't see any issues or failures in the logs.

Comment 4

[roman.marik]

There are actually two scenarios, where we were able to reproduce this.

Our environment

1. Comptuer1 accesses firefox saved on DFS mapped as a letter. When i execute firefox.exe applocker generates few events that are \............\firefox.exe was allowed to run. But there is always single one that states \..........\firefox.exe was prevented from running.

MS Ticket case
2) Engineer simulated same issues using only two machines on same network. Specifically launching it on Computer1 from Computer2's UNC path - \Computer2\c$\firefox.exe

This issue happens in both rule types - Publisher, Path.
Please keep in mind that it is neccesary to have AppIDSvc service running for applocker to be active.

Thanks,
BR
Roman.

Comment 5

[Bob Owen (:bobowen)]

Thanks for the reply.
Setting to P2 while I investigate.

Comment 6

[Bob Owen (:bobowen)]

Got back to this and I've managed to reproduce now.
I was running as a user that was part of the Administrator group, which has a default blanket allow rule.
Running as a non-admin user, it looks like one of the utility processes is failing.

Comment 7

[roman.marik]

Hello,

is there any update in this ticket ?

Thanks.

Comment 8

[Bob Owen (:bobowen)]

(In reply to roman.marik from comment #7)

Hello,

is there any update in this ticket ?

Thanks.

Yes, sorry I've been tied up with other work.
Although I believe in that work I may have run into a similar issue and with any luck the fix there will work for this.

It won't land in Nightly until early August now, so I suspect it won't make it into Fx130 (Sept 3rd release) although it is possible that it would be fairly safe to uplift.
I'll try and reproduce again and then see if it seems to work and then I can split out that part to make it simpler to uplift.

Comment 9

[Bob Owen (:bobowen)]

Unfortunately, this is not the same issue.
The combination of a network drive and AppLocker rules are adding extra complications.
I'll have to look at this again when I return from PTO.