2

The company I work at uses a program on their Windows workstations that runs as the logged-in user but some tasks require elevated privileges. The user must be able to run these without having admin permissions himself.

The current approach is that at the installation of said program a Windows Service is installed with the user LocalSystem and autostart enabled. The elevated privilege tasks are implemented in the service and whenever the program needs one it just calls the service.

For me this seems kind of fishy because with the current setup any program could at any time call the service and run the implemented tasks with elevated privileges.

Since I'm not an expert in IT security my questions are:

Is this issue really as bad as it seems to me and what would be the right approach to handle the given problem?

nobody
  • 11,251
  • 1
  • 41
  • 60
etw0
  • 45
  • 3

1 Answers1

3

The design of services on the Windows platform implies that if your software architecture requires using some additional privileges it needs to be split into the parts where one of them usually runs as a service under "System" account.

The other part of the software typically communicates with this service using some IPC mechanism and runs with the restricted rights, for example, as a non-elevated process (if UAC is enabled and even if UAC is disabled but the software is designed to always run under restricted token, for example using CreateRestrictedToken Windows API).

Most of the Windows OS components and solutions from the different TOP vendors are created in this way. So, if a service that runs under the "System" account and an application which communicates with it were developed with best security practices in mind, everything is ok.

And vice versa, if a service allows any code to dictate which app to run and it runs it under a non-restricted access token with the "System" owner - this is definitely a security problem.

Artjom B.
  • 285
  • 1
  • 4
  • 13
Kostia Shiian
  • 146
  • 4