Repository navigation
Discussion: AppLocker Startup Performance Impact Mitigations #11074
Description
Background
AppLocker doesn't have an API to see if it is on or not, so we have to call it every startup which causes significant delays.
In the cited case, the system was air gapped, and this lead to a 9-14 second delay in my testing.
Possibile Mitigations
- Add a PowerShell policy that is required to be enable, before PowerShell checks AppLocked
- We would not back port this to Windows PowerShell to avoid breaking that large user-base.
- I propose that this would only happen in vNext and not be back-ported to any PowerShell Core version either.
- Add telemetry to see how many people are using this
- Pros
- This would solve the lack of API in AppLocker to see if AppLocker in enabled.
Only, system that explicitly say they want PowerShell to use AppLocker would see any significant delay. - We can measure the problem this way with telemetry
- This would solve the lack of API in AppLocker to see if AppLocker in enabled.
- Cons
- This would be a breaking change and AppLocker user would have to know they need to do this.
- Add a message when we see more that a 10 second delay in the API, that points to a document, for troubleshooting.
- Pros:
- This would not be a breaking change
- Cons:
- This does not improve the actual performance, only tells users how to improve performance in the worst case.
- Because the problem occurs in air gapped system, this solution does not help provide telemetry
- Pros:
- Remove AppLocker support
- AppLocker is a Defense in Depth feature which has numerous bypasses and users should move to WDAC.
- Pros:
- Completely solves the problem
- Simplifies the code base
- Cons
- This would be a big breaking and change and AppLocker users would need to learn to use WDAC.
Poll
Please vote for the solution that you think works the best
Other solutions
- Checking for internet connectivity and disable AppLocker
- This is basically the what the Windows Certificate verification code is doing and we would be duplicating their code.
- That is a very complex solution. We don't know what host they will want to connect to and there could be a firewall with access rules that allow Microsoft hosts, but not the host where your CRL is hosted.
- This could introduce a very easy security bypass if we cache the result
Activity
SteveL-MSFT commented on Nov 14, 2019
We should probably do the first and second mitigations where the message in the second one points to a aka.ms link describing what is happening and shows how to enable the first
TravisEz13 commented on Nov 14, 2019
Steve Lee (@SteveL-MSFT) If the first was enabled, the message for 2 would never show up.
SteveL-MSFT commented on Nov 15, 2019
Travis Plunk (@TravisEz13) yes, I was thinking it was opt-out, not opt-in
iSazonov commented on Nov 15, 2019
If AppLocaker is turned off no delay is in the call and so we have no need in the API to see if AppLocker on or off.
In the referenced case the environment was broken and as result AppLocker is delayed. In broken environment any service may not work properly including WDAC. Also there are many alternative AV in world.
We actively use AppLocker in our environment. It very helps us.
Removing AppLocker support violates a principle that PowerShell is secure OOB.
We can not disable PowerShell at whole but we can control what scripts to enable to run and it is great feature.
Before 7.0 GA I suggest:
Also we could add special trust for PSReadline dll to address startup scenario.
TravisEz13 commented on Nov 15, 2019
This is not true, I have verified
TravisEz13 commented on Nov 15, 2019
How was the reference environment broken?
TravisEz13 commented on Nov 15, 2019
AppLocker is a defense in depth feature with known bypassed that require WDAC to mitigate.
TravisEz13 commented on Nov 15, 2019
Telemetry would not work, because the problem occurs in an air gapped system.
Updated: Updated pros and cons
TravisEz13 commented on Nov 15, 2019
This is essentially the same as proposed solution 2
iSazonov commented on Nov 15, 2019
From the issue:
Bad DNS config can kill any service. DNS timeout is 2-3 seconds per request and 3 attempts = 6-9 seconds delay.
I saw AppLocker delays in my environment and removing rules or disabling AppLocker removes the delays. Notice,after GPO update it is necessary to wait (or reboot) 5-20 minutes while AppLocker update its cache.
This is a special case in the original issue. We don’t even know all the options when a problem may arise and telemetry will show the scale of the disaster.
TravisEz13 commented on Nov 15, 2019
I would not call a delay when it cannot find a record broken, but just slow.
The system I repro'ed on never had any AppLocker rules enabled
Since all cases reported to the PowerShell team have been in air gapped systems. This is flatly false
dragonwolf83 commented on Nov 15, 2019
Is there a quick way to check that the internet is not connected at startup? That would be ideal for disabling telemetry, updater checks, and AppLocker since they can't function without internet anyway.
TravisEz13 commented on Nov 15, 2019
That is a very complex solution. We don't know what host they will want to connect to and there could be a firewall with access rules that allow Microsoft hosts, but not the host where your CRL is hosted.
I added an other solutions section with additional reasons why this is not a viable solution.
iSazonov commented on Nov 16, 2019
If no rules what does AppLocker? Trying load CRL? This looks like bug.
TravisEz13 commented on Nov 16, 2019
Even if this is a bug, there is no intent to service AppLocker, see
https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria
Although, I have already reported this issue to the AppLocker team (we have in previous years as well.) I'll update this issue if we get another answer from AppLocker this time.
The advice from AppLocker is to apply the policy in #10983.
iSazonov commented on Nov 28, 2019
JasonFossen commented on Feb 8, 2020
So we're just a few days from GA now and the 9-second startup delay remains in the latest release candidate. Is it accurate to summarize the situation like this?
"The AppLocker people don't intend to update AppLocker anymore, we're not willing to refactor this part of PowerShell Core to be like Windows PowerShell (which doesn't suffer this problem), but we want you to switch to PowerShell 7 anyway despite the 9-second startup delay. If this is not acceptable, please make a system-wide change to how Windows checks CRLs, or disable recursion on your DNS servers, or don't use air gaps for security, testing or training purposes when you also need to run PowerShell."
Is this an accurate summary?
iSazonov commented on Feb 8, 2020
Jason Fossen (@JasonFossen) Your comment add nothing new. You could share your experience with AppLocker, maybe business cases as requested in the issue.
TravisEz13 commented on Feb 10, 2020
Jason Fossen (@JasonFossen) As Ilya (@iSazonov) said, this is a topic that has been asked and answered in this thread. You can see a public statement that AppLocker has no intent to service from
https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria which was mention in a previous comment (#11074 (comment))
Here is a screenshot:
microsoft-github-policy-service commented on Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.