Hi @RLWA32 ,
Thank you for reporting this for us.
I can both reproduce this 2 cases you metioned in windows 2004,1909 version.
For the original sample(logon sid is assigned with *_ALL_ACCESS
in the document):
For the global namespace:
I have reported with 2 samples internally, any progress will be update here.
Some Updates:
- The default DACL being created for mutexs, events, timers, etc… appears to be hard coded and it is not using the default dacl in the token to create the DACL. It only changes the creator owner who gets full access and LocalSystem and the logon session get full access as well.
You can experiment by changing the default dacl and you’ll discover it doesn’t change the dacl on any of the synchronization objects. If you test with a private object, it does change the security descriptor based on the default dacl so the default dacl mechanism definitely works for secured objects. - For "Consequently, any other process running in the same session under a different account that receives the logon sid in its token will have full control over the synchronization objects. This is a security consideration that should be addressed"
We would say the following:- The logon sesion is going to be associated with the interactively logged on user via local or RDP logon. This user may or may not be an administrator. This user can launch other processes as other users and they will be a member of the same logon session. (This is how CreateProcecesswithLogonW() works due to interactive desktop access) Typically if you do runas or CreateProcessWithLogonW(), you’ll be running a higher privileged user so does it matter that this user has access to your secured objects? Even if they didn’t have direct access since they are a member of the administrator group they could get access to the named synchronization object.
- The other way an application can make a user be a member of the same logon session, they would need to be localsystem and have the “act as part of the operating system” privilege and it has to be enabled to add a group to a new user via LsaLogonUser() If a hacker is already running as LocalSystem, they already have full access to the system and they can easily get access to the named synchronization object.
- Services, users running in other logon sessions will not have access to these kernel objects since they are running in a different logon session unless they are configured for LocalSystem or a user who is a member of the administrator group.
- If a hacker can run a process as the logged on user, they will already have full access to your named synchronization objects.
- Our thoughts on why we grant full access to the logon session is for a couple of reasons:
- WindowsStations/desktops for runas
- Processes, when the user logs off, Windows needs to be able to terminate all processes associated with the logon session.
If the answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.