#18906 (Bug) ASR rule + DisplayCAL-apply-profiles.exe

+1 0

Closed as Not A Bug
Component: DisplayCAL
Created by rafik

Last modified

DisplayCAL-apply-profiles.exe seems to trigger “Block credential stealing from the Windows local security authority subsystem (lsass.exe)”. I want to enable this rule (now it is in audit mode) to block any potential bad guys/software.

Info on this ASR rule: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard

This link could helpful to solve this mystery: https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Interpreting-Exploit-Guard-ASR-audit-alerts/ba-p/228366

2019-07-26 015344 (image/png | 2019-07-26 01:59:30)

22 comments on “ASR rule + DisplayCAL-apply-profiles.exe”

  1. The MS blog post contains some wrong information, i.e. OpenProcess with PROCESS_ALL_ACCESS (which is the least restrictive access) is not required to trigger a block, it is enough to use PROCESS_QUERY_LIMITED_INFORMATION (which AFAIK is the most restrictive access available). The latter is used by the profile loader.

    You should be able to enable the rule and still use the profile loader, but you will likely loose some functionality, e.g:

    • The profile loader will no longer be able to detect applications other than DisplayCAL
    • As a result of this, automatically reloading calibration will probably stop working.
    • madVR or any exceptions you have added will not trigger the profile loader being automatically disabled/reset calibration as configured. When you need the profile loader to be disabled when certain other applications are running, you will need to do so manually.

  2. Btw, I’m not sure if the block description is supposed to mean that only access to lsass.exe is blocked. If that is the case, profile loader functionality will not be impacted at all, as it doesn’t actually access lsass (it is just included in the process list of all processes, naturally).

  4. May I suggest a small change: if this OpenProcess  fails, do not retry this query.

    Why? because it fills the event log with this warning every 3s(?)

    Windows Defender Exploit Guard audited an operation that is not allowed by your IT administrator.
    For more information please contact your IT administrator.
    ID: 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2
    Detection time: 2019-07-26T00:09:05.609Z
    User: COMPUTERNAME\username
    Path: C:\Windows\System32\lsass.exe
    Process Name: C:\Program Files (x86)\DisplayCAL\DisplayCAL-apply-profiles.exe
    Security intelligence Version: 1.299.517.0
    Engine Version: 1.1.16200.1
    Product Version: 4.18.1907.4

  5. > May I suggest a small change: if this OpenProcess fails, do not retry this query.

    Sorry, that’s not possible. We cannot know the name (or other likely unique identifiable information) of a process before we have called OpenProcess on it, so there is no way to build a hash table for exclusion.

    In light of the block description, this looks like a bug in Windows Defender, because it should check the dwDesiredAccess parameter to determine if the requested access can actually pose a security risk. In this case, it can not (or at the very least, I fail to see how), because PROCESS_QUERY_LIMITED_INFORMATION is meant to be used in cases where you are only interested in e.g. the process name or other metadata (I’m also pretty sure that in this case OpenProcess doesn’t actually access any memory of the process in question at all, instead, the OS likely returns the data from an internal table that it populates on process launch).

  6. Yes, I understand, I will try to raise this issue with MS product team.

    but after the 1st (or 3rd?) failure, DisplayCAL-apply-profiles.exe could stop asking and asking and asking…?

  7. but after the 1st (or 3rd?) failure, DisplayCAL-apply-profiles.exe could stop asking and asking and asking…?

    No. How? It would have to have some (other) identifying information about a process it is trying to get the name of. Without having the name, it can’t make any assumptions about the process, not even if it is the same process (image) as it was three seconds ago.

  8. From my point of view it doesn’t if it is the same process (image) or not – just don’t try more than 3 times.

  10. How else would you detect other processes then? The reason you poll in intervals is to detect changes in the list of running processes. If you stop that just because you can’t get information about some of the processes, it breaks all the stuff I explained in my very first comment. Plain and simple.

  11. Yes, but it doesn’t matter. The profile is loaded, that’s all that matters in this situation + useful eventlog 😉

  12. or in another words: if you are blocked and cannot detect other processes, just quit these detection efforts NOT to overwrite the event log that might be important

  13. Yes, but it doesn’t matter. The profile is loaded, that’s all that matters in this situation + useful eventlog 😉

    Well, I hope you understand that this line of thinking is quite selfish – you’re basically saying “it doesn’t matter to me”, but rest assured, it matters to many users around the world.

    if you are blocked and cannot detect other processes, just quit these detection efforts

    Sorry, you do not understand. It is absolutely normal and expected for a quite sizeable portion of running processes to be off-limits for even basic queries like this, regardless of ASR is enabled or not. That is no problem at all. But because there is no way to know what processes failed the query and for what reason, you cannot just stop querying altogether, otherwise you will loose detection ability completely.

  14. “this line of thinking is quite selfish”

    ???

    I just ask to stop all that non-working process detection and NOT overwriting the event log in case that particular ASR rule is enabled. That’s selfish?

  15. Well yes, of course that is selfish. I don’t get why this actually surprises you? You are asking me to make a global change, yes? That will affect everyone, not just your particular situation?

    I just ask to stop all that non-working process detection and NOT overwriting the event log in case that particular ASR rule is enabled.

    How would a program know that there is an ASR rule in place that’s not working properly and floods (well, not really, three second intervals is hardly flooding) the event logs? I repeat, there is no way to detect this, see above.

  17. Nope. It will return a generic error value, normally access denied. This is fine, but not enough detail to infer the actual underlying reason for access having failed.

  18. MS suggest the similar behavior:

    Following this pattern, when you get to lsass.exe in the process list, you’ll be alerted to the fact that you used an overly permissive request and, in block mode, Windows Defender ATP will decline it. But, as you can see in the demo code, you can check for failure. If you check for a null handle and respond appropriately, then the failure doesn’t break your app.

    And, in the case of this ASR rule, we have come across zero impact to application compatibility by switching to enforced mode. (Note: that doesn’t mean there will never be a compatibility issue. It’s just that, in this case, it appears to be statistically unlikely.) Yes, Windows Defender ATP will flag an alert and, in block mode, prevent you from being granted a handle, but doing so doesn’t necessarily break your app.

  19. If you check for a null handle and respond appropriately, then the failure doesn’t break your app.

    You need to understand that these are basics of application design. The processes that cannot be accessed are just skipped.

  20. I hoped you are able to implement this small change, but it is considered too complicated.

    I give up.

  21. Well no, of course not, because there is no way for me to implement it, as I’ve spent much time and energy trying to explain, and the correct solution is to fix the bug in Windows Defender in the first place.

Comments are closed.