It appears that cross process messages are allowed in Windows, and while Windows appears to have protection so that a lower process can't inject a message to a higher process, say they are at the same level at the time and a message is created with an invalid pointer that gets updated. Isn't that a potential issue? For one, crashing apps or corrupting data, or two, maybe exploiting an app that may elevate later?
TIA!!
Cross process security risks are all about using the enhanced privileges of other processes to do something that your process cannot do. Privilege isolation of the message system protects against that.
crashing apps or corrupting data
Processes can terminate other processes at the same privilege level. Being able to send messages to other processes at the same privilege level adds nothing new.
exploiting an app that may elevate later
Processes cannot elevate later. Elevation happens as part of process creation.
Related
This has been always confusing me. Here is a statement which states "Principle of least privilege" whereas one more statement states, use UIPI to protect applications from low integrity level processes.
As an application I may not do any privileged operations, but in order to protect my UI (using UIPI), I will be forced to promote my application to high integrity.
Contradicting. Any one has a better explanation for this?
I am aware of the difference between those. I am not looking for what are these. I am looking at how to balance between these.
For example,
I am developing an application, I am not doing any privileged operation, so my application can run in low integrity level itself. So as per principle of least privilege, I am happy to execute my application as low integrity level. But if i run my application with low integrity level, i am prone to attacks by UIPI. Anyone can send messages and cause DOS attack. This makes me think, shall i go ahead and launch my application as high integrity so that no other medium integrity apps can attack my application. But this goes against "Principle of least privilege"
Mandatory Integrity Control was added in Vista and has 6 major integrity levels but only 3 of them are used for normal user processes; Low, Medium and High.
Win32 processes run at medium integrity level by default (when started from Explorer etc.) so most Win32 apps are already protected from low integrity level processes (UWP apps, Edge, IE and Chrome).
UIPI inspects the sender and receivers integrity levels and allows the interaction if sender >= receiver. There are some exceptions. Signed UIAccess applications in system directories have special access and you can manually add exceptions in your application for specific messages if desired.
You can view a processes integrity level with Process Explorer.
Applications running at medium IL are trusted from the users point of view, you should not worry about protecting yourself from them. High IL applications are trusted by the user/administrator and the machine. You should not run at high IL unless you need those additional rights that come with it. Low IL is for high risk applications like web browsers and PDF readers.
This is not documented anywhere but the current implementation allows you to create your own levels, so you could run your application with a integrity level somewhere between low and medium.
When running under Citrix or RDP as an admin, I can see, terminate or otherwise manipulate processes created by other users, or in other sessions. Admins need to be able to do this from time to time so I can't remove that capability from Admin logins, but I'd like to restrict it on certain processes.
Is there a way to change the security and/or privileges of the current process or a process I launch, so that it can no longer see or otherwise manipulate other user's processes? I'd be happy to either change the rights of the currently executing process (which is mine), or launch my process using some method that denies the privilege to the target executable. It's the inverse of Run as Admin.
I thought that AdjustTokenPrivileges might be the key, but I can't seem to find any privileges to remove that relate to seeing other users' processes in the Privilege Constants list.
CreateProcess with an appropriate lpSecurityDescriptor seems like it might do the trick, but I haven't been able to find a good example of the security descriptor, or anything that relates to other users' processes.
Anyone know the secret sauce? Thanks
In windows (in general), does process owned by a particular user exits when the corresponding user logs off (but computer is still on?)
Is the behavior consistent accross Windows / Windows Server ?
Yes, a process initiated by the user (or by the system on behalf of the user) is terminated when that user logs off. If they only "switch users" or "lock" the computer, the processes reaming running in memory, as normal (though they may lose priority in the queue to process initiated by or on behalf of other users concurrently logged in).
As far as I know, this behaviour is the same on Windows Server, though I imagine that it the priority queue is even more skewed in favour of system processes when a user is not actively logged in.
I have developed a C# Windows Forms application that runs in the background as a systray icon and does some stuff when it's clicked. It is supposed to launch when Windows starts and run continously, and a normal user without administrator rights shall not be allowed to shut it down.
What is the best way to do this? I initially intended to run it on the LocalSystem account through Task Scheduler, but then I learned (the hard way) about Session 0 isolation (i.e. the application will run but its UI elements do not show). When I run it with the logged in user, even if it runs elevated, the user can still shut it down through task manager (without requiring elevation).
Is there any way to give a process from LocalSystem access to the UI? I have a winlogon and a csrss process from LocalSystem running in session 1, so I guess it can be done, I just don't know how. Or is there maybe an easier way to disallow users to shut down a process of their own through the task manager? The only other option I can think of is to create an extra Windows Service that keeps polling if the app is running, and immediately launches it again if someone kills it - but that seems incredibly clumsy (also, I want it to stay dead when it crashed by itself, to avoid a single bug causing infinite loops of process creation).
Deponds on why they can't shut it down.
The natural way to go would to have created a service, started by a high priv account, and then had the desktop app just show what it was doing.
If there's something that they should see, but don't becasue they aren't running the service monitor app. (and acknowledge message back to the service), send them an email, send their boss an email, send yourself one and then go shout at them.....
Be a lot easier than trying to get the lid back on this tin of worms.
A nice way to make sure the desktop app is ruuning, would be simply to schedule it to run every X, but drop out immediately if it already is or the somethingwenthorriblywrong flkag is set.
Not worth writing a service to check if it's still there, as they could kill that as well, unless you want to make that a service they can't kill. :(
You are trying to be too draconian with this. Add some sort of auditing so you can see it dies or was shutdown, monitor that and deal with any adverse reports. It's a heck of a lot easier, and gives manage something to do...
You can run an administrative process in the user's logon session. One method would be to for a master process (a system service) to duplicate its own token, use SetTokenInformation to change the session associated with the token, and then call CreateProcessAsUser. The lpStartupInfo parameter can be used to associate the process with a particular window station and desktop. It may be necessary to explicitly change the permissions on the window station and desktop first.
HOWEVER, this is a bad idea from a security standpoint, because GUI applications are vulnerable to malicious messages sent from other processes on the same desktop ("shatter attacks").
It would be safer to run the process in the user's own context but apply an ACL to it. This can be done using the lpProcessAttributes parameter to CreateProcess or CreateProcessAsUser, or with the SetSecurityInfo function. I've never tried this, but it should in theory prevent the user from using task manager to close the process.
If you are creating the process from the user's context, then the user will be the owner, so a sufficiently knowledgeable person could change the permissions back in order to terminate the process. If you need to block this hole, using CreateProcessAsUser from a privileged master process (the token can be duplicated from one of the existing processes in the user's session) should (again, in theory) mean that the user is not the process owner.
Another potential issue: if you listen for messages indicating that the user is logging out (in order to exit) such a message could be faked. If you don't then you need to find some other way of exiting when the user logs out. You may need to experiment here, I'm not sure how the system will react.
I maintain a variety of managed userlabs on a university campus. These machines all currently run Windows XP and we have a windows service that is used to "lock" a machine by blocking any keyboard or mouse input. The locking happens during our scripted OS installation so that users aren't able to accidentally halt or break the process. It is also used to prevent users from logging into machines until they are checked out at the front desk of a given lab. Ctrl+Alt+Del is blocked via a keyboard filter driver and the rest of the keys and mouse are currently blocked using the BlockInput() function from user32.dll.
In XP, the service runs as Local System and the checkbox for "Allow service to interact with desktop" must be enabled from the BlockInput() call to succeed. Under Vista, this no longer works I'm guessing because of the Session 0 isolation changes. The call succeeds, but input is not actually blocked.
The keyboard filter driver still works just fine and we can use that to block the whole keyboard instead of just Ctrl+Alt+Del. But I'm at a loss as to how we're going to block the mouse now. I'm not even entirely sure the Session 0 isolation is to blame.
Can anyone recommend a fix or a workaround to allow us to block mouse input from a service in Vista and beyond? I've looked for alternative win32 API's without luck. Assuming Session 0 isolation is to blame, is there a legitimate way to call the function from Session 1 or would that sort of defeat the purpose of the isolation? Will I have to rely on an elevated companion exe that runs on user login and communicates with the service?
From a service, you can use WTSEnumerateSessions to get all logged on user sessions, WTSQueryUserToken to get the logged on user's token, and then use CreateProcessAsUser with that token to get code running on the user's desktop. This has the disadvantage that the code will run as the logged on user. Since all input is disabled, this is probably safe enough and is at least as safe as the existing XP solution.]
EDIT: BlockInput requires a high mandatory integrity level. You could try adding this group to the token, but then you have code with higher privileges running on the desktop and potentially open to attacks.
An alternative might be to use your service just to disable all HID class devices on the machine.