Numerous "Security Audit Failure" events in Windows Event log

[a-bronx]

Description

Brave.exe generates a large amount of Security Audit Failures in Windows Event log.

Steps to Reproduce

Windows 10 Enterprise workstation in an Active Directory domain.

Open Event Viewer, Windows Logs, "Security" log.

Actual result:

See numerous Audit Failure events (Event ID 4673, category "Sensitive Privilege Use", provider "Microsoft-Windows-Security-Auditing"), associated with requests of SeProfileSingleProcessPrivilege:

A privileged service was called.
...
Service:
	Server:	Security
	Service Name:	-

Process:
	Process ID:	0x10f0
	Process Name:	C:\Program Files (x86)\BraveSoftware\Brave-Browser\Application\brave.exe

Service Request Information:
	Privileges:		SeProfileSingleProcessPrivilege

Also there is a small amount of audit failures associated with a request for SeTcbPrivilege:

A privileged service was called.
...
Service:
	Server:	Security
	Service Name:	-

Process:
	Process ID:	0x548
	Process Name:	C:\Program Files (x86)\BraveSoftware\Brave-Browser\Application\brave.exe

Service Request Information:
	Privileges:		SeTcbPrivilege

Expected result:

No audit failures at all, or a smaller number of failures, or provide and explanation and methods to avoid the audit log thrashing.

SeTcbPrivilege: "Allows a process to assume the identity of any user and thus gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this privilege. Note that potential access is not limited to what is associated with the user by default; the calling process might request that arbitrary additional privileges be added to the access token. The calling process might also build an access token that does not provide a primary identity for tracking events in the audit log. When a service requires this privilege, configure the service to log on using the Local System account, which has the privilege inherently. Do not create a separate account and assign the privilege to it."

SeProfileSingleProcessPrivilege: "Allows a user to sample the performance of an application process. Default setting: Administrators and Power Users. Ordinarily, you do not need this privilege to use the Performance snap-in. However, you do need the privilege if System Monitor is configured to collect data by using Windows Management Instrumentation (WMI)."

Brave version (brave://version info)

Brave: 1.2.43 Chromium: 79.0.3945.130 (Official Build) (64-bit)
Revision: e22de67c28798d98833a7137c0e22876237fc40a-refs/branch-heads/3945@{#1047}
OS: Windows 10 OS Version 1903 (Build 18362.592)

Other Additional Information:

The issue is reproducible on the latest version of Chrome as well, so it seems that the issue is inherited.

[diracdeltas]

I'm not sure offhand how serious these are. If not critical, I think we should just wait on a Chromium fix since it affects them as well. Have you reported to Chrome yet?

[a-bronx]

I didn't report it to Chrome. I suspect that the SeProfileSingleProcessPrivilege may be related with some performance telemetry. Not sure what use of SeTcbPrivilege.

[a-bronx]

A similar issue in the Chromium tracker is closed as "WontFix". Quoting the investigation result here:

I did a quick investigation into this on Windows 10 18363 but I'd expect it's similar on all versions of 10.
The source of SeProfileSingleProcessPrivilege is from ProcessMemoryDump::CountResidentBytes which calls the Windows API QueryWorkingSetEx. This is getting called quite a lot to monitor Chrome process state which is probably why you see a lot of events being generated.
The source of SeTcbPrivilege is from a call to ImportantFileWriter::WriteFileAtomically, which results in a call to the Windows ReplaceFile which calls NtSetSecurityObject which results in the privilege check.
The problem for Chrome is we don't control these privilege checks at all. Neither of the APIs being called have any mechanism to not do a privilege check, it's basically due to poorly design Windows behaviors.
The result of this is there's not much Chrome can do about it. About the only thing we could investigate would be a reduced rate of process profiling but that's not my area.
I'd recommend marking this as WontFix as it's really a problem with the Windows implementation and incorrect auditing policies, specifically you shouldn't be monitoring sensitive privilege failures. It's basically meaningless noise, only monitoring success has any obvious value from a security monitoring perspective as that represents actual attempts to use privileged functionality. At any rate success results should be relatively few as it looks like the kernel filters out any audits from service accounts.

[kjozwiak]

@diracdeltas should we close this one off as well as per the info that @a-bronx found above? I guess we can leave this opened if we plan on addressing the above.

[diracdeltas]

sgtm

…

On Fri, Mar 27, 2020 at 15:16 Kamil Jozwiak ***@***.***> wrote: @diracdeltas <https://github.com/diracdeltas> should we close this one off as well as per the info that @a-bronx <https://github.com/a-bronx> found above? I guess we can leave this opened if we plan on addressing the above. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEGGFR5LI5ZRNXCNYX4L73RJUQUPANCNFSM4KSF234A> .

[kjozwiak]

Thanks for the above info @a-bronx. As per @diracdeltas above, we'll close this off for now 👍