Why is my starting directory ignored when I elevate a command prompt?


Take a shortcut to the command prompt or some other Windows component, right-click it, and select "Run as Administrator." The "Start in" directory from the shortcut is ignored and you are always dropped into the system directory. Why is the starting directory ignored?

To avoid a category of attacks (current directory attacks).

According to the dynamic link library search order documentation, the current directory is searched in step five, after the executable directory, and a variety of system-defined directories. If a program calls LoadLibrary and does not pass a fully-qualified path, and the DLL cannot be found in one of the first four locations, the current directory will be searched. An attacker can drop a DLL into a directory and trick you into running a program with that directory as its current directory. When that program tries to load a library that normally doesn't exist, the one the attacker created will be found and loaded. This is bad.

Note that this behavior applies only to Windows binaries and only if they are launched through an elevation prompt. (Programs that are not a part of Windows do not receive this behavior because compatibility testing showed that third-party application rely heavily on the current directory being preserved across an elevation boundary. For example, installers will unpack their contents into a temporary directory, change to that temporary directory, and then run the main setup program.)

Comments (21)
  1. Anonymous says:

    But in order to exploit it, the attacker needs to convince you, the administrator, to run an executable from a shortcut they control.

    After all, if they didn’t control the shortcut, they wouldn’t be able to set the "start in" directory to one with their evil DLL.

    But if the attacker convinces you to "run as administrator" a shortcut they control, haven’t they already got to the other side of the airtight hatchway? Can’t they just set the shortcut to point to an evil EXE instead of using a known EXE with an evil DLL?

    Or am I missing something?

    (I’m also intrigued to know what criteria is used to separate "Windows binaries" from the rest.)

  2. Anonymous says:

    Not really, they’d only have to convince you to drop a named DLL into a given, unprotected folder where you are likely to load something with adminstrative rights.

    Think, maybe, your Documents folder. I imagine a good many people have command prompts or other applications that open with that as the current directory. I can’t imagine it’s that hard to use social engineering to get people to download a dll there and wait for the time bomb to go off.

    Same could be said of the system drive root, the desktop, or for us developers our build or tools directory.

  3. Anonymous says:

    Doesn’t this fall into your "if they can put a file on the disk and convince you to run a program, they may as well have convinced you to run the malicious program in the first place" scenario?

  4. Anonymous says:

    Does Vista have a "sudo" equivalent?

    All too often, I type a command and get a snarky "This requires elevation" message.  That means I have to find a cmd.exe shortcut, right-click it, select "Run as administrator", wait five seconds for the UAC prompt to appear, click "Continue", navigate to the directory I was in, and retry the command.  Enough of a hassle that I just might disable UAC (and then disable all tray warnings to make Vista stop complaining that UAC is disabled).

  5. How is "Windows component" defined? Does Explorer take a look at the manifest or the signature? Or does it have a list of programs for which it shouldn’t do this (e.g. "setup.exe" gets treated differently)?

  6. Anonymous says:

    JS: The Script Elevation PowerToys for Windows Vista gives you an "elevate" command.

    http://www.microsoft.com/technet/technetmag/issues/2007/06/UtilitySpotlight/default.aspx

    PMP

  7. Anonymous says:

    "An attacker can drop a DLL into a directory and trick you into running a program with that directory as its current directory. When that program tries to load a library that normally doesn’t exist, the one the attacker created will be found and loaded."

    I don’t know if I buy the reasoning behind this.  If the attacker can get you to modify a shortcut to change the current directory in order to load his dll, why wouldn’t he be able to trick you into just copying his dll to the system directory?  I guess it’s good to close off an attack vector, but I think the same people who would modify their shortcut would also probably just copy the dll to the system directory.

    UAC does nothing to address the underlying problem of ignorant users.  People just see a dialog and click Yes/Allow without even reading it, much less understanding the implications of it.  I guess it gives the rest of us one last chance before our machines get owned, so it’s not completely useless.

  8. Anonymous says:

    Is it just me, or does this sound like another case of "make programs jump through unnecessary hoops just to operate safely with Windows"? (Shatter attack, anyone?) I know it’s too late to change this behaviour, but it seems awfully alot like that.

    UAC does nothing to address the underlying problem of ignorant users.  People just see a dialog and click Yes/Allow without even reading it, much less understanding the implications of it.

    I don’t understand this reasoning. Natural curiosity has been a part of the human race since its inception, why try to change the way people think instead of designing something to work with how they think ?

  9. Anonymous says:

    John: Replacing a file in the system directory isn’t that easy to do anymore. It involves taking ownership of the file in question and then changing permissions on the file.

    As for the utility of the UAC prompt, I think it’s pretty useless if you run as an administrator all the time, but running with elevated privileges for day-to-day use is silly ,anyway. I run as a non-administrative user (and non-pretty-much-everything-else), so when I get a UAC prompt I have to stop and type the Administrator’s password to confirm the action. That definitely makes me pay a little more attention.

    PMP

  10. Anonymous says:

    Why even fiddling with a shortcut to an evil binary? Just make the shortcut itself a binary. Due to the stupidities of ShellExecuteEx(), a binary renamed to .pif or .lnk will execute as well.

    But I have another question: Is there a way to change the search order arbitrarily, not just the two variants offered by the SafeDllSearch configuration entry? I’d like to have the %PATH% before the system directory, so I can have a user’s program loading updated DLLs without replacing the system’s DLL.

  11. Anonymous says:

    I think changing the search order arbitrarily would count as "one of those things that developers would abuse".  I might be wrong but I thought LoadLibrary looked in the program’s directory first anyway.

  12. Anonymous says:

    Triangle:  Because no matter how good your system is, at some point the decision will ultimately fall on the user.  Normal people (and I don’t mean this in a condescending way) don’t think about computers the same way we do.  As long as those people are kept in the decision making process, they are prone to making bad decisions.  Unfortunately, computers are complicated and most people are unwilling to learn.

  13. Anonymous says:

    This is definitely not the airtight hatchway situation due to the "My Documents" scenario above.  Or consider a Virus Scanner – many virus scanners run as a service of some form or fashion.  Imagine if they managed to slip a DLL into C:ProgramDataRandomProduct or some such and then you, to work around an issue, need to launch the Live Updater through an elevated cmd.exe

    RandomProduct has a file called securfile.dll and so they throw a file called securfile.dll in there without so much as requiring any admin privileges and now you’ve installed a trojan that has now been given full administrative privileges and there was no way you could have ever worked around it.

    Or similarly from a shortcut – install the same file and say the Magic Update shortcut has a start in that points to C:ProgramDataRandomProduct.  It auto-elevates as necessary and again – you’ve installed a trojan without so much as being able to prevent it or know about it beforehand.

  14. Anonymous says:

    But still, in order for this to be a problem it requires three things:

     1. A user-modifiable folder.

     2. A user-modifiable shortcut with Start In set to #1.

     3. An admin who will accept elevation using #2, and then run a program that uses a DLL included in #1.

    So any folders/shortcuts set with permissions that prevent non-admins from modifying them are automatically safe, and could have been left alone.

    And any user-modifiable elevating shortcuts are automatically dangerous, no matter what the Start In is — since the rogue user/program can just change the Target to whatever evil app they want.  (Although the elevation prompt may show the difference in that case, so hopefully the real app is signed and the admin is paying attention.)

    [You can employ this attack without steps 1 and 2. The only step necessary is #3. Hint: CIFS. -Raymond]
  15. Starting an elevated CMD prompt in the folder of your choosing:

    elevate cmd /k C:FolderOfYourChoosing

    where "elevate" is the script described here:

    http://blogs.msdn.com/aaron_margosis/archive/2007/07/01/scripting-elevation-on-vista.aspx

  16. Anonymous says:

    From John:

    "

    If the attacker can get you to modify a shortcut to change the current directory in order to load his dll, why wouldn’t he be able to trick you into just copying his dll to the system directory?

    "

    The system directory is usually very protected on a normal Windows configuration. It’s not write-able by non-admin users.

    However, the temporary download directory of a Web browser will typically be in a directory write-able by the user.

    Assume a user running a browser with a non-admin user account.

    It’s easy to imagine that an average security flaw of a browser may let a DLL be downloaded to the temp download directory without user consent (or maybe, he accidentally downloaded a file he didn’t want to, with a "quick download" shortcut key).

    Then, the user may download a trusted signed installer from another site and carefully execute it with admin rights from the temporary download directory.

    "

    UAC does nothing to address the underlying problem of ignorant users.  People just see a dialog and click Yes/Allow without even reading it, much less understanding the implications of it.

    "

    It protects users that aren’t totally ignorant.

  17. It protects users that aren’t totally ignorant.

    It also protects those that aren’t running as admin… and don’t know the admin password.

  18. Anonymous says:

    It also protects those that aren’t running as admin… and don’t know the admin password.

    Not quite. If a user got a virus, that virus could still do anything that user could do, such as delete all their files or exhaust their quotas. So more accurately it protects the system, not the user.

  19. Anonymous says:

    This would be why Unix and Unix-based systems don’t include the current directory in the search path for libraries or executables. It just opens up too many security holes on multi-user systems. (This isn’t even a particularly nasty example.)

    The reason Windows doesn’t run into issues is that it’s a GUI OS and programs are generally launched with the directory the executable is in as the current directory. Anyone doing admin work on directories accessible to other users from the Windows command line is probably asking for trouble.

Comments are closed.