Processes created by SYSTEM services run limited; cannot elevate privileges

koharubi

Hello Kays + everyone,

I'm logged in as a SuRunner, and when a service running as NT AUTHORITY\SYSTEM creates a new process, the new process gets put under limited rights. This is a big problem for me, because my Lenovo laptop uses a hotkey service (running as SYSTEM) that creates new processes to control the system (power profiles, drive eject, touchpad properties, etc.) A host of other programs, such as RealVNC (the service spawns vncconfig.exe), also have major usability problems because of this.

Unfortunately, I cannot get SuRun to detect and elevate privileges on any process spawned by a SYSTEM service.

I was testing RunAsAdmin Explorer Shim before trying SuRun. It was very unstable and not ready for production, but at the very least, processes spawned by SYSTEM services ran with the parent's privileges.

Can I get this same behavior in SuRun? Perhaps with an workaround? Even an ugly one? :)

Appreciated,
David

xdmv

I use Process Explorer from Microsoft (Ex Sysinternals) to identify running processes.
Then I add them to SuRun Program List.
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Is this what you're looking for?

koharubi

Thanks, I use Process Explorer as well. The thing is: even if I add the program to the SuRun list as "automagically start", it is not detected and elevated.

Are you able to elevate any processes spawned by a running service? I wonder if I'm doing something wrong...

For example: I have vncconfig.exe set to automagically run. if I start winvnc4.exe (the RealVNC Server) in Service-mode, double-click the icon, and click "Configure", the service creates a new process "c:\program files\RealVNC\VNC4\vncconfig.exe". But it doesn't get elevated.

If I start the same RealVNC Server in User-mode (running with my user's credentials, not as NT AUTHORITY\SYSTEM), the vncconfig.exe process _does_ get elevated.

xdmv

I understand...
Adding the SYSTEM Group to SuRunners Group would be a solution? Just a thought...
Kay?
Would that compromise security?

koharubi

Interesting idea. I tried adding "NT AUTHORITY\SYSTEM": there's no error message, but it doesn't get put on the SuRunners list.

I've developed a very ugly workaround of sorts. Using the "Image File Execution Options" Windows NT registry key, I add a "Debugger" string to each program that isn't getting elevated. The "Debugger" is a simple AutoIt3 script that SuRuns a copy of the executable. So if the winvnc4.exe service creates a process "C:\vnc\vncconfig.exe -config", the script intercepts it and actually runs "surun.exe c:\vnc\vncconfig.ifeo.exe -config".

This hack also solves my problem of processes that are spawned by rundll32.exe not getting elevated. But it requires a lot of hands-on maintenance.

Kay

Welcome, :-)

SuRun does not intercept any functions in processes that already run with administrative rights. So all system processes are not hooked by SuRun and SuRun does not intercept starting applications by these processes.
This is the reason why adding "vncconfig.exe" to the users program list does do nothing useful.

SuRun does it that way because admin/system processes can do what they want and they should be programmed with care. SuRuns IAT-Hook does things, that Microsoft does "not recommend", so SuRun backs off on administrative processes.

But: What makes child processes of "system" processes run as standard user? Usually a process inherits the parent's process'es rights. So every process started by a SYSTEM process should have SYSTEM rights. Why is that different on your machine? Do you have any HIPS running? Does the service process launch the child as limited user by intention?

koharubi

Hi Kay!

Thanks for the explanation. I should have been more clear: not all services are spawning processes as "COMPUTER\User". It seems to be common practice with third-party services, but not Microsoft ones. I have witnessed it with RealVNC as well as all of the Lenovo/IBM services installed as part of the various Thinkpad utilities. It must be by the programmer's intention, as you said.

I tried it again, just to make sure it wasn't a mistake on my part:

1) Installed RealVNC Enterprise Trial on a clean XP SP3 VMware image.

2) Used default RealVNC settings (Service-mode)

3) Double-clicked on RealVNC tray icon, clicked "Configure" button

4) winvnc4.exe service spawned vncconfig.exe process with the following security settings:
User: COMPUTER\User
Logon SID: Mandatory
Everyone: Mandatory
LOCAL: Mandatory
NT AUTHORITY\Authenticated Users: Mandatory
BUILTIN\Administrators: Owner
BUILTIN\Users: Mandatory
NT AUTHORITY\INTERACTIVE: Mandatory

5) Reverted to clean VMware snapshot, installed SuRun, made "COMPUTER\User" an SuRunner, rebooted.

6) Installed RealVNC Enterprise Trial

7) Double-clicked on RealVNC tray icon, clicked "Configure" button

8) vncconfig.exe fails with error message. Process Explorer shows a difference:
User: COMPUTER\User
Logon SID: Mandatory
Everyone: Mandatory
LOCAL: Mandatory
NT AUTHORITY\Authenticated Users: Mandatory
COMPUTER\SuRunners: Mandatory
COMPUTER\None: Mandatory
BUILTIN\Users: Mandatory
NT AUTHORITY\INTERACTIVE: Mandatory

(As an aside, the RealVNC service failed to allow client connections until I removed my user from the SuRunners group. This happened on my laptop, but I failed to reproduce the problem on my VMware image.)

I think that, if an SuRunner decides to install a service, the user wants that service to have full administrative rights. Limited rights for service-spawned processes will (sometimes) be unexpected and/or undesired behavior. Do you agree?

If so, would it be possible in future versions to allow elevation of service-spawned processes? You make it sound dangerous, so perhaps you can implement a whitelist of parent service processes that would be monitored, and all others would be ignored. And of course you would not need to elevate anything running as NT AUTHORITY\*. Maybe you could take some cues from RunAsAdmin, which doesn't have this problem. It seem like a very different piece of software, though.

I think something like that would be a wonderful addition to your already amazing program.

Kay

I'm currently on vacation until August 10th. I'll test when I'm back.

Kay

I could verify your realvnc issue.

You can configure RealVNC by running "surun C:\Programme\RealVNC\VNC4\vncconfig.exe -noconsole -service".

Koharubi:1248639691 wrote: Limited rights for service-spawned processes will (sometimes) be unexpected and/or undesired behavior. Do you agree?

SuRun can hardly prevent a usual service from spawning processes with limited rights.
SuRuns hooks affect GUI apps only.
In the case of RealVNC we're in luck, but with non GUI services not.

Koharubi:1248639691 wrote: If so, would it be possible in future versions to allow elevation of service-spawned processes? You make it sound dangerous, so perhaps you can implement a whitelist of parent service processes that would be monitored, and all others would be ignored. And of course you would not need to elevate anything running as NT AUTHORITY\*.

SuRun would have to intercept the CreateProcessAsUser function.
Then analyze the user token.
If it is the logged on limited user but the program is in the users list SuRun would ask/start the program with an elevated token... This could also solve the "new hardware wizard" problem...
A quick check in a VMware WinXPproSP3 shows SuRunExt.dll injected to all service processes.

Your suggestion might work. :-D

I'll put that on the wish list.

Kay

Please try the current Beta.

It can intercept Process creation by services.
For that you need to enable "Show SuRun settings for experienced users", "Set a Hook into all processes that directly execute applications" and "Also set a hook into services and administrative processes. (System restart required!)".

After rebooting you can make "C:\Programme\RealVNC\VNC4\vncconfig.exe *" start automagically as administrator.

koharubi

Kay, thanks a million! I will try the new beta sometime next week on my über-problematic Lenovo laptop.