If you run notepad elevated (Right click | Run as Administrator), and you try and drag-and-drop a file from Windows Explorer, nothing happens. It looks like it is going to work because the pointer icon changes but the file doesn’t open. Weird, huh?
What’s Going On?
In the traditional NT Security model (prior to Vista), all processes on the same desktop ran with the same security token and had all the same privileges. UAC changed this by allowing processes with different privilege levels on the same desktop.
Lower Privilege Processes Can’t Interfere with Higher Privilege Processes
In order to prevent potential elevation of privilege attacks, certain functionality needs to be blocked. This is implemented through Mandatory Integrity Control (MIC). All processes and all resources (files, registry, etc.) have an integrity level assigned. MIC prevents a standard user process from writing to a protected per machine location like Program Files or the HKLM registry hive. I won’t go too deep into MIC in this post but the following is a great resource if you want more info: Inside Windows Vista User Account Control.
User Interface Privilege Isolation (UIPI)
Okay, back to our drag and drop issue… A “sister” technology that works in conjunction with MIC is UIPI. UIPI blocks Windows messages being sent from process with a lower MIC level to one running at a higher MIC level. Drag-and-drop is implemented via Windows messages. Therefore, if you try and drag-and-drop a file from Windows Explorer (medium MIC) to Notepad running elevated (high MIC), the Windows messages are blocked and drag-and-drop doesn’t work.
You can use ChangeWindowsMessageFilterEx in your application to allow specified Windows messages to not be blocked. Unfortunately, this isn’t recommended as a safe solution for drag and drop due to the messages that drag and drop uses.
Okay. Now What?
The best solution is to only use drag and drop between the same MIC levels. With UAC enabled, Windows Explorer will run at a medium MIC level. Therefore, your application (Notepad in our example) needs to run at medium (or lower) MIC level. The bottom line is that drag and drop from Windows Explorer will not work if your application is elevated. If you find yourself in this situation, you may need to rethink your application design or not support drag-and-drop with UAC enabled.
Why would it be bad to move from less privelages to more?
Why would it be bad? Well… it's a huge security hole, for one. It basically allows the low privilege application to run arbitrary code under *your* privilege. Don't forget, Drag and Drop is really, really old. It's from back when security wasn't worth the performance impact, and it isn't really possible to fix it while retaining compatibility (and, well, keeping it useful – the whole reason DnD is awesome is that it *works*).
Now this is downright a brain dead solution to a security problem. Why not just forbid using a GUI at all? I have a log viewing application and the most fast, handy and user friendly way to use it is by drag and drop. If the files are so unsecure, then opening them via a file dialog should also be blocked.
Hi Lurker and Seriously?!,
The need for UIPI is to prevent shatter attacks (See en.wikipedia.org/…/Shatter_attack).
Pat
I didn't know about that one so thanks for sharing.
But still, why block the messages that are designed and intended for interprocess communication? It indeed makes no sense to allow every possible message to be sent, but it also makes no sense to block messages that are meant to be shared (like drag-drop). It's like having a web browser that doesn't allow you to click on URLs to go to another site (which also was a Microsoft recomendation at some point).
It's kind of mystifying that when logging in as Administrator, one cannot drag-drop files, but if logging in as a restricted user, it's allowed.
Hi Lurker,
The issue is that there is no security context for Windows messages. This is the way Windows was originally designed. Preventing security vulnerabilities is very important. In order to be secure by default, messages with callbacks need to be blocked if there is a risk of elevation of privilege. Drag and drop will work in all cases except from a lower integrity level to a higher one. For your scenario, I'm guessing you have log files in a high integrity location. In order to access the log files, you need to run your app elevated. Then you are trying to drag and drop from Windows Explorer. By default, Windows Explorer will run at a medium integrity level and your trying to drag and drop to a higher integrity level. There are a couple of options, you can either move your log files to a medium integrity location so you can run your app at a medium integrity (preferred). Try moving your log files to test this. Or, you could run Windows Explorer elevated. You can't really do this with UAC enabled. See my post on how UAC works: blogs.msdn.com/…/if-i-m-an-administrator-why-do-i-get-access-denied.aspx.
Pat
fuck uac! drag-and-drop is a very good feature for user. why such a good feature offered compromises to a bad code design? why not try to fix or change bad code design? why not try to make drag-and-drop and UAC both enabled? win10 has a same fucking feature…you never change anything over the years….
Hi DanoR,
Drag and drop functionality will work as expected if applications run at the same integrity level when UAC is enabled. Because drag and drop uses Windows messages to communicate, you can’t accept potentially untrusted data from a lower integrity process.
Pat
I just got bit by this hard. Lost too much time tonight, trying to figure out where *I* was going wrong with my code. Okay, so this is a necessary security “feature”. Cool. But perhaps then the system should notify the user as to why they can’t perform this drag and drop, instead of letting us spin our wheels…
Hi tbarela,
Good point. The best place to submit developer product feedback is UserVoice. https://wpdev.uservoice.com/
Thanks,
Pat
Wow some people really upset to see the OS enforce security! lol
An interesting, alternative way to solve the UIPI “issue” is to let the program check its integrity level and restart itself at medium level. Works great without loosing the elevation state otherwise.