How to do IPC with UAC elevation safely?

Question

i have portions of my program that require administrative access (settings that affect all users, stored in HKLM, and are limited to administrative access).

i've changed my software to indicate that elevation is required:

In response i am going to launch my executable while prompting for elevation:

SHELLEXECUTEINFO shExecInfo;
shExecInfo.cbSize = sizeof(SHELLEXECUTEINFO);
shExecInfo.fMask = NULL;
shExecInfo.hwnd = NULL;
shExecInfo.lpVerb = L"runas";
shExecInfo.lpFile = L"myapp.exe";
shExecInfo.lpParameters = NULL;
shExecInfo.lpDirectory = NULL;
shExecInfo.nShow = SW_MAXIMIZE;
shExecInfo.hInstApp = NULL;
ShellExecuteEx(&shExecInfo);

What i was going to do is pass the name of a named pipe on the command line, telling myself where it can connect back to in order to get instructions on what it's supposed to be doing:

myapp.exe /uac 6C844671-E262-46DD-939E-47517F105FB6

(Yes, using a GUID as the name of the pipe).

Through this pipe i would tell my elevated clone what database, e.g.:

• what server database it's supposed to be connecting to
• the user it should say it making the changes
• the thing it should add/edit/delete

My concern was then that anyone could launch myapp.exe, and then feed it all kinds of requests - things i don't want it to do cause i didn't launch it, e.g.:

MaliciousProgram.exe:

 ShellExecute("myapp.exe /uac HahaYouDoWhatISayNow")

i remember during the Longhorn beta there was a Channel9 video, or an article, talking about UAC and the dangers of the wrong of doing IPC (Inter-process communication).

i don't want to re-invent the wheel, making security mistakes that have already been solved. But i cannot find any existing guidance on the "correct" way to do IPC with UAC elevation.

What't he accepted pattern for doing IPC to communicate with spawned elevated process for temporary elevated actions?

---

Edit: Combined followers of uac and ipc tags: 53

Answer 1

I don't believe there is a security issue here (with certain caveats as noted below). If the user can't elevate, this solution won't work anyway; if the user can elevate, and is malicious, the machine is already compromised. For example, if a malicious user wants to make changes in HKLM, why use myapp.exe when regedit is available?

However, I'm confused by your mention of a server database; how does this fit in with the requirement for elevation? Generally speaking elevation is not required for accessing remote resources. (If either myapp.exe or HKLM contains a password to the server database, it shouldn't.)

As for the choice of IPC: I'm not expert in UAC programming, but searching MSDN I've noticed that elevated COM objects are mentioned several times, e.g.:

http://msdn.microsoft.com/en-us/magazine/cc163486.aspx

see also the powerpoint slides at the fifth link in this article:

http://msdn.microsoft.com/en-us/library/bb756996.aspx

However, if you're not happy with COM (join the club!) then using a named pipe as you suggest should be just as effective. You do however need to take the usual precautions necessary for named pipes - make sure that you create the server end of the named pipe before launching the elevated process, that you check whether the pipe already existed, and that you create it with an appropriate ACL.