New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 819258 link

Starred by 2 users

Issue metadata

Status: Unconfirmed
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

SeCreateGlobalPrivilege failures in Event Log when Privilege Auditing is enabled

Reported by ei...@caspi.org.il, Mar 6 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

Steps to reproduce the problem:
Hi,

I work with Chrome  64.0.3282.167 (Official Build) (64-bit) on Windows 10, build 1709, 64 bit.

My Windows event log system is set to log “Audit Sensitive Privilege Use” (https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-sensitive-privilege-use).

When Chrome is running, at the security event log there is an excessive large number of “Failure” event IDs of 4673, for Chrome, for trying to use the right of “SeCreateGlobalPrivilege” (“Create global objects = Required to create named file mapping objects in the global namespace during Terminal Services sessions. This privilege is enabled by default for administrators, services, and the local system account.” https://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85).aspx , https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-global-objects).

The use of Chrome is in a local console mode, not remote nor terminal based in any way. I am a local admin.

A sample (Event ID 4673, Source: Microsoft Windows security auditing., Opcode: Info, Task Category: Sensitive Privilege Use, Keywords: Audit Failure):

“
A privileged service was called.

Subject:
              Security ID:                          domain\user

               Account Name:                    user

               Account Domain:                domain

               Logon ID:                             xxxx

Service:

               Server:    Security

               Service Name:       -

Process:

               Process ID:            xxxx

               Process Name:      C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

Service Request Information:

               Privileges:                             SeCreateGlobalPrivilege

“

The description for the relevant privilege is stating about Terminal activity while this happens in a local console Chrome activity (unless Chrome is doing some Terminal trick...), so it looks strange.

The user mentioned in the log is local admin with full permissions.

Beside these event log records I did not see any issues (crash, speed, etc.) of Chrome

What is the expected behavior?
The Chrome will not generate these events. It looks like Chrome is "asking" the Windows OS for a privilege it doesn't need

What went wrong?
Well, since I was born things went wrong... :)
Just kidding.

Too many non-relevant (probably) windows security failure logs by Chrome

Did this work before? N/A 

Chrome version: 64.0.3282.186  Channel: stable
OS Version: 10.0
Flash Version:
 

Comment 1 by ei...@caspi.org.il, Mar 6 2018

Screen shot.
chromelog.png
56.6 KB View Download
Cc: penny...@chromium.org wfh@chromium.org
Adding a few ccs that might have an idea of what's going on here.
Friendly ping. I'm not sure if there's anything to do here, but would feel better if someone more familiar with this took.

Comment 4 by ei...@caspi.org.il, Mar 13 2018

Why nothing to do here? It floods the security log for no apparent good reason. The source of this activity should be found and stopped. 
Components: Internals>Core
To be clear, the event log is "flooded" because you've enabled Auditing, a feature which, by definition, logs all use of permissions. If you wish to avoid such flooding, either disable auditing or use filtering to ignore events from Chrome.

It is *interesting* that Chrome is attempting to utilize a privilege that it does not appear to strictly require, but it's certainly possible that this is working as expected. 

The only direct use of the permission I see is in a library used by test code:
https://cs.chromium.org/chromium/src/third_party/apache-portable-runtime/src/shmem/win32/shm.c?type=cs&q=SE_CREATE_GLOBAL_NAME&sq=package:chromium&l=76

...but presumably CreateFileMapping[1] or OpenFileMapping calls used elsewhere (perhaps in the shared memory system) check the privilege as well.

[1]https://cs.chromium.org/chromium/src/base/memory/shared_memory_win.cc?q=CreateFileMapping&sq=package:chromium&l=114

Comment 6 Deleted

Comment 7 by ei...@caspi.org.il, Mar 15 2018

Not so clear. I enable audit to find security events, especially ones of "failure" to attempt to detect security issues. I will not stop auditing of this for the whole OS and apps just because Chrome is misbehaving, attempting to use a privilege it should not use.

I didn't wrote Chrome is not working OK in general, but it is doing something it should not (probably) hence flooding the security audit log with no good reason.

I am not a developer, this is why I came here with this issue...
> attempting to use a privilege it should not use.

Thus far, there's no evidence that Chrome shouldn't be using this privilege.

Comment 9 by ei...@caspi.org.il, Mar 15 2018

If Chrome should use this privilege but the OS blocks it, this means something is wrong and Chrome isn't getting the OS right it needs. very simple.

If you wanna help and fix this - please do. If you just wish to do a pointless argue, please move along.
> If Chrome should use this privilege but the OS blocks it
> this means something is wrong and Chrome isn't getting 
> the OS right it needs.

This is simply incorrect. For instance, an application may wish to share an object globally across Sessions if possible, falling back to sharing within a single session if permission for Global sharing is denied. 
Labels: -Type-Bug-Security -Pri-2 -Restrict-View-SecurityTeam Pri-3 Type-Bug
Summary: SeCreateGlobalPrivilege failures in Event Log when Privilege Auditing is enabled (was: Excessive failure security event logs by Chrome on Windows)
At worst, this is a functional issue (because the permission request is declined).

FWIW, I wasn't able to reproduce this problem on Windows 10 in Stable or Canary with privilege auditing enabled. It's possible that the failure is induced by some third-party module loaded into Chrome's process space (e.g. AV, drivers, etc).

Comment 12 by ei...@caspi.org.il, Mar 18 2018

A move forward, I tested again, now for version 65.0.3325.162 (Official Build) (64-bit).
At home, in a regular user installation, the issue does not exist.

At work, in a domain environment, with policy templates, it still happens.
here are some more details for the work installation:

chrome://version/:
Google Chrome	65.0.3325.162 (Official Build) (64-bit) (cohort: 65_win_162)
Revision	5d04e9e9c8ce31bee0923a8c326a7e9e19c492a3-refs/branch-heads/3325@{#695}
OS	Windows
JavaScript	V8 6.5.254.36
Flash	29.0.0.113 C:\WINDOWS\system32\Macromed\Flash\pepflashplayer64_29_0_0_113.dll
User Agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36
Command Line	"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --use-spdy=off --disable-quic --profile-directory="Profile 1" --flag-switches-begin --enable-quic --flag-switches-end --site-per-process
Executable Path	C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Profile Path	C:\Users\user\AppData\Local\Google\Chrome\User Data\Profile 1
Variations	bd23585d-3f4a17df
c134752e-b8b72c88
61fba06-ca7d8d80
3095aa95-3f4a17df
d52c4ff7-d52c4ff7
47e5d3db-3d47f4f4
9cfd95a0-ca7d8d80
4dc30737-b8a5ea08
34d450b1-3f4a17df
f9884634-659882c0
9e201a2b-6e3ce1c
57f575bb-3d47f4f4
f347910c-3f4a17df
4b61504a-d25ea691
9773d3bd-f23d1dea
8e3b2dc5-93702590
9e5c75f1-1039a221
c322f799-2dbe5f9
2981bcb4-ca7d8d80
3de1fbf2-ca7d8d80
f79cb77b-3d47f4f4
4ea303a6-2e46ed91
d92562a9-ca7d8d80
447469ba-13d9f35f
7aa46da5-c946b150
2b33233e-ca7d8d80
dd026cd0-f23d1dea
72606c4f-ca7d8d80
cac0a91c-388b6f1c
58a025e3-c2b41702
1bced4a3-90fa85cd
b2f0086-d6b26420
2d871858-3f4a17df
4bc337ce-69465896
9a2f4e5b-d226bfeb
1354da85-f91d1961
494d8760-52325d43
f47ae82a-86f22ee5
3ac60855-486e2a9c
f296190c-a0af34c0
4442aae2-4ad60575
ed1d377-e1cc0f14
75f0f0a0-a5822863
e2b18481-cdc3d902
e7e71889-e1cc0f14
34baa302-d25ea691
f5fff3a2-ca7d8d80
2aae5467-b05adee3
94e68624-803f8fc4
da4aaa01-4d2fac87
Compiler	clang


Cc: vamshi.kommuri@chromium.org
Labels: Triaged-ET TE-NeedsTriageHelp Needs-Triage-M64
This issue seems to be out of scope for triaging from our end as this is related to Privilege Auditing, hence adding label TE-NeedsTriageHelp and requesting someone from Internals>Core team to have a look into it and help in further triaging it.

Thanks!

Sign in to add a comment