Vinod has the right information, but to expand on it a little bit:
The Service Control Manager (SCM, also see MSDN) is the parent process of all Windows services, and is also a Remote Procedure Call (RPC) server. When a service is started (and assuming that the service isn't in a shared binary, typically svchost.exe, which is a configuration primarily used for Microsoft-written services) the SCM launches the service command (in your example, C:\Program Files (x86)\Donald Duck\Donald_Duck.exe) and then waits for the service to connect back to the SCM via RPC and report that it is in startup. If the service fails to report back to the SCM (or it reports back that it was unable to start for some reason, or fails to proceed from the startup to running state) within a time limit (30000ms, or 30 seconds) then the SCM will kill the process.
For exploitation purposes, there's three ways around this.
- Do your work within the 30 second window (ideally well within it, as on a sufficiently-loaded machine you may spend a lot of that window waiting on CPU time or I/O). If all you need to do is, say, change a registry key or access a file, or perhaps something like inject a DLL into another privileged process, this is usually fine.
- Launch a child process that does the actual work. The SCM will kill the process it launched, but children of that process can continue executing.
- Report back to the SCM that you are, in fact, the hijacked service and are doing the right thing. This is non-trivial but not actually that difficult if you know any C - or especially Win32 - programming (in particular, you needn't know a thing about RPC, as it is all wrapped in Win32
ServiceDoThing() APIs). You may need to do this if, for example, it's important to your exploit scenario that the service appear to be running (perhaps some other component cares about whether starting the service succeeded, or some monitoring process will complain to somebody if the launch fails). The documentation on reporting that you are a service program is found in MSDN.
Regardless of all this, there's something else you should consider. Unless somebody has changed the NTFS permissions from their defaults, you cannot actually create any of those files without already being an Administrator! By default, non-admin users can create (or edit) directories but not files in the root of a drive, and of course the Program Files (x86) directory already exists so you can't create a new copy of it. Nor can you rename it, to replace it with another directory you control. You also cannot create, edit, or rename contents of Program Files or Program Files (x86) at all, without admin privileges.
Since having Administrator privileges is equivalent to having SYSTEM privileges (that is, an admin can either take control and edit the ACL on anything they want to access even if it's normally SYSTEM-only, or can simply launch a program as SYSTEM), if you have enough privileges to exploit this coding error, you already have all the privileges it would give you. In other words, there is no Escalation of Privilege here. It is still a coding error, and could have a security impact on a misconfigured system, but at that point the error really comes down to whoever changed the ACLs on the root of the drive or the Program Files (x86) directory.
