How does the Windows "Secure Desktop" mode work?
Can anyone explain (or provide a link to a simple explanation) of what the Windows "Secure Desktop" mode is and how it works?
I just heard about it in the KeePass documentation (KeePass - Enter Master Key on a Secure Desktop) and would like to understand it better.
Generally letter style headers and footers are considered unnecessary on SE sites. I pulled them out for you.
Secure Desktop link was broken. FTFY. Also, FTR: Even though a "Secure Desktop" similar to UAC, *might* be able to protect you against software keyloggers, they will be ineffective against hardware keyloggers. You still should not enter in any passwords (or other data) that you value on a system you do not trust.
@Iszi thanks for pointing that out. What are hardware keyloggers? Would that be like a specially engineered keyboard in an internet cafe? I'm mostly concerned about my Windows PC so I'm willing to trust that the hardware is fine but I am concerned about Malware installing itself.
Hardware keyloggers come in many forms. It could be a dongle plugged in between the keyboard and the USB/PS2 port (anyone still using PS2?) or it could be an entire keyboard. There's been many a story told about people at security conventions having their passwords snatched up by the cleaning lady.
I agree with the security comments of @iszi. The security of the keyboard in UAC mode vs keyloggers is not well documented. IF you have not falled prey to phishing or a Trojan horse program that has side effects, any LIMITED USER/Base user process will not be able to read the UAC Secure desktop keyboard input. BUT. beware. If a program sets the registry key disabling SecureDesktop when it runs its install (hopefully not possible with Install Sheild) UAC runs in the user context and any non-admin key logger grabs UAC content. (GOOD behavior detection AV catches keyloggers though)
There are three, separate issues claiming the name of "Secure Desktop":
- Windows builtin functions like GINA and the Credential Provider Model.
- Separation of privileged vs unprivileged applications running as the same user (nominally prevent privilege escalation), which may or may not be related to:
SwitchDesktop(), which is what KeePass is using and may or may not (I'm not sure) be resistant to DLL Injection.
As a quick primer to how Windows GUIs are built, basically everything runs through a function called
CreateWindow()(I mean everything, every button, every menu, everything) and is given a
hWndor Window Handle. Modifying these Windows is done via another function,
Here's the catch. As a user mode application, making the right API calls I can fairly easily send messages to other Windows. It's fairly trivial to make buttons disappear from other people's forms. It is a little harder to perform DLL injection and hook the message loop that receives messages (the OS sends Windows messages when things happen to them) but not that much harder. If I can hook those events, I could automatically submit your "yes/no" form. Or, I could change the label from
explorer.exeand you'd be none the wiser.
Insert: A really good article on the various techniques of getting your code into the address space of a running process.
Now, what are KeePass doing?
A very brief perusal of the source shows they are using
CloseDesktop()to create a second desktop connected to the physical viewing device you're on. In English, they're asking the kernel to create for them an isolated desktop whose
hWndobjects are outside of the findable range of any other application's
I should point out that
SwitchDesktopsuspends the updating of the UI of the default desktop. I'm not sure if the message loops are also frozen - I suspect not since the desktop is created as a new thread.
In this instance, KeePass is drawing the UI, so the execution is not, as I understand it, as
NT AUTHORITY/SYSTEM. Instead, the new desktop is created in isolation from basically the rest of the current desktop, which protects it. I'll be happy to be corrected on that. However, see the MSDN for SwitchDesktop:
The SwitchDesktop function fails if the desktop belongs to an invisible window station. SwitchDesktop also fails when called from a process that is associated with a secured desktop such as the WinLogon and ScreenSaver desktops. Processes that are associated with a secured desktop include custom UserInit processes. Such calls typically fail with an "access denied" error.
I believe this means that these dialogs (screensavers, Windows Logon) are built more deeply into Windows such that they always execute as
NT AUTHORITY\SYSTEMand the
UserInitprocess creates the sub processes on valid authentication at the required privilege level.
The reason I bring this up is because I believe there are two issues: different desktops and privilege separation. From Mark Russinovich's discussion of the topic of Secure Desktop:
The Windows Integrity Mechanism and UIPI were designed to create a protective barrier around elevated applications. One of its original goals was to prevent software developers from taking shortcuts and leveraging already-elevated applications to accomplish administrative tasks. An application running with standard user rights cannot send synthetic mouse or keyboard inputs into an elevated application to make it do its bidding or inject code into an elevated application to perform administrative operations.
As SteveS says, UAC runs a separate desktop process as
NT AUTHORITY/SYSTEM. If you can catch UAC in action (
consent.exe) via process explorer, it looks like this:
Escalating privileges as a process I don't have the specifics of, but here is what I think I understand: I believe the process of privilege escalation in the Windows API causes a process running as
NT AUTHORITY/SYSTEM(therefore able to execute the new process under whatever privileges it wants to, in this case an Administrator). When an application asks for higher privileges, that question is asked to you on a new desktop locally, to which none of your applications can get either the Desktop Handle or any of the GUI element handles. When you consent,
consent.execreates the process as the privileged user. Thus, the process running as
NT AUTHORITY\SYSTEMis a consequence of the need to create a new privileged process, not as a method of creating a secure desktop. The fact the desktop is different to the default is what adds security in both cases.
I believe what Mark means above is that, in addition to these secure desktops, two things are happening:
- Your default administrator desktop is in fact running unprivileged, contrary to Windows XP and earlier and
- Unprivileged and privileged applications now exist on separate desktops (disclaimer: could just be ACLs on the objects in memory, I'm not sure), ensuring that unprivileged code can't access privileged objects.
The Windows Logon UI is different again in Vista/7.
Clearly, none of these methods will defend you against kernel mode rootkits, but they do prevent privilege escalation and UI integrity compromise by isolating privileged applications, or in the case of KeePass, the sensitive dialog.
Having looked harder at the KeePass code, I saw this handy piece of C#:
Bitmap bmpBack = UIUtil.CreateScreenshot(); if(bmpBack != null) UIUtil.DimImage(bmpBack); /* ... */ SecureThreadParams stp = new SecureThreadParams(); stp.BackgroundBitmap = bmpBack; stp.ThreadDesktop = pNewDesktop;
From this you can see that in fact in order to mimic consent.exe, KeePass takes a screenshot of the background, dims it and creates its new desktop with the background of the old desktop. I therefore suspect the old desktop continues running even while it isn't being rendered. This I think confirms that no magic
NT AUTHORITY\SYSTEMaction is happening both with KeePass and
consent.exe(I suspect consent.exe is doing the same thing UI-wise, it just happens to be launched in the context of
When I say DLL Injection, I'm specifically thinking of DLL injection to corrupt the UI. DLL Injection remains possible on KeePass as a process, I'm just not sure whether it could be used to influence that secure UI. It could, however, be used to access the memory of the process and its threads, thereby grabbing the entered password pre-encryption. Hard, but I think possible. I'd appreciate someone advising on this if they know.
I don't know if that qualifies as a "simple explanation", but this is one of the better explanations I've read. :) I will edit my post as it's not entirely accurate with regards to only SYSTEM can create secure desktops.
@SteveS I think, if my understanding is right, there are two different types of desktop, "Secure" as in "part of Windows and only customisable via GINA, say" and "Secure" as in "isolated". I'm not 100% that separate desktops are created for unprivileged and privileged applications run by the same user but I think that is what Mark R is alluding to. Unfortunately, separating out these concepts becomes non trivial fairly quickly...! Your answer is fine I think, as for all intents and purposes the same ideas (at a high level) are used.
@Ninefingers - This is a great answer. However, could you perhaps provide a one-paragraph "TL;DR" summary at the top?
I really wish I could +1 this again, for the added detail in edits. @Ninefingers - Hope you don't mind, I edited the third "short answer" bullet to hopefully make it more clear - it appeared a little confusing to me.
@Iszi I don't mind at all - I agree, moving the wording around is an improvement.
Nice answer!! One tiny confusion: what's a "message loop"? I'm guessing it is a typical windows term for what I'd call an event loop?
@nealmcb yes, basically. Every Window (usually top level actual Windows) has a function that is a call back that basically is continually called with all the events that happen on that window, like `WM_CLOSE` if the user clicks the `x` for example. Dll Injection allows you to hook in your own listeners, so you could hook `WM_KEYDOWN` and grab every key the user types in the context of an application...
Wow, I learned more about the Windows GUI than I had bargained for. Great answer! Thank you very much!
@snth no problem. If you're interested in Windows internals, Mark Russinovich is the author of the tool in the screenshot (Process Explorer) and his blog is very much worth a read. He's so good, Microsoft hired him a couple of years' back.
2.0 uses actual SecureDesktop, but is that something that can be run as a mortal user too and just prevents window switching to normal programs? It would take a system routine that could start an actual SecureDesktop in System user context, which could happen, but it would take some research to determine what KeePass 2.0 does, there...