It rather involved being on the other side of this airtight hatchway: If you grant users full control over critical files, then it’s not the fault of the system for letting users modify them


Today's dubious security vulnerability is another example of If you reconfigure your computer to be insecure, don't be surprised that there's a security vulnerability.

This example comes from by an actual security vulnerability report submitted to Microsoft:

I have found a critical security vulnerability that allows arbitrary elevation to administrator from unprivileged accounts.

  1. Grant Full Control of the Windows directory (and all its contents and subdirectories) to Everyone.
  2. Log on as an unprivileged user and perform these actions...

I can just stop there because your brain has already stopped processing input because of all the alarm bells ringing after you read that first step. That first step gives away the farm. If you grant control to the entire contents of the Windows directory to non-administrators, then don't be surprised that they can run around and do bad things!

"If I remove all the locks from my doors, then bad guys can steal my stuff."

Yeah, so don't do that. This is not a security vulnerability in the door.

Bonus chatter

: There are many variations on this dubious security vulnerability. Actual vulnerability reports submitted to Microsoft include

  • "First, grant world-write permission to this registry key..."
  • "First, reconfigure Internet Explorer to allow scripting of ActiveX controls not marked safe for scripting..."
  • "On a compromised machine, you can..."

That last one is impressive for its directness. "Starting on the other side of this airtight hatchway..."

Comments (55)
  1. Tom says:

    Honest question: how many of those reports did it take before the top of your head stopped exploding off in a comedic manner?  

    I'm not sure I would ever develop full immunity to it.

  2. TIago Magalhães says:

    Who submits these "security vulnerability reports"?

    [Microsoft receives 200,000 security vulnerability reports per year. As you might imagine, most of them are junk, but we have to read them all just in case. -Raymond]
  3. Antonio Rodríguez says:

    Windows is, of course, to blame. Windows (and specially Windows Vista, of course) is insecure, because it shouldn't let users change those permissions. I bet many (if not most) of these reports are done by Linux pundits that don't even know they can cause the very same trouble if they did the same to their Linux system (i.e., giving world write access to the /bin/ directory). Of course, Windows' UAC is the graphical version of Linux's sudo. But that doesn't matter, either. What a good OS Linux would be, if their users had another attitude…

  4. Dominik says:

    Speaking of security vulnerabilities…

    Why does Windows load DLLs from the current WorkingDirectory?

    I mean why provide that 'feature' in the first place?

  5. Rangoric says:

    @Dominik

    Because I have DLLs to load in there. I don't think that is the question you should be asking.

  6. Antonio Rodríguez says:

    > Why does Windows load DLLs from the current WorkingDirectory?

    I'd bet it's a remainder of the old times of Windows 1.0. It was easier (and required less code) to keep the executable's directory as current during application launch, than to implement additional logic in the library loader. That was, of course, 25 years ago. But now we are tied by compatibility…

    It's easy to fix that on your application. Just set at boot the current directory to the executable path, and make sure you never change it. It isn't difficult, because you can reference any file by its absolute path. And if you need to get the absolute path from a base and a relative path, you can always write a function that does so. Doing so will prevent your application form being attacked by DLL insertion.

  7. Joshua says:

    @Antonio: We have such an application. We got bit because, by default, the open & save dialog boxes will change the current directory.

  8. Leo Petr says:

    @Antonio: I disagree. What makes personal computers so wonderful is that anyone can start programming on them without having to acquire a special, unlocked developer edition of the operating system. Locked-down, unmodifiable devices like the iPad have their place, but we should not turn personal computers into the like.

    The administrator account should always allow a sufficiently ingenious administrator to shoot themselves in the foot.

  9. John Topley says:

    I'm probably missing the point here, but shouldn't the ACLs on Windows system files be orthogonal to the permissions that processes have whilst executing? Even if I have Full Control over all the files, surely my ability to do things as a user is still governed by the permissions assigned to the groups I'm a member of and group policies that are in effect etc.

  10. Alex Grigoriev says:

    @Dominic:

    In Windowss XP SP2+, the current directory is searched second to last in LoadLibrary. Time to get with the program.

  11. Frederik Slijkerman says:

    @John: And how does Windows decide which files you can access/modify if you're a regular user? By checking the ACLs on the files.

  12. DWalker says:

    I love these "other side of this airtight hatchway" stories.  

    At step 1, "Grant Full Control of the Windows directory (and all its contents and subdirectories) to Everyone", we need to hear a disembodied voice calmly saying "I can't do that, Dave…"

  13. Barbie says:

    @John Topley: And where do you think Windows stores the data that says which group you're part of ?

  14. John Topley says:

    @Barbie In the registry or within Active Directory if you're on a network I should imagine.

  15. Alex Grigoriev says:

    @John Topley:

    …continuing your sentense: and user's access to all objects (including system files) is deduced from the object's ACL and the user's group membership. It's an ACL that allows or reject access to a particular user.

    By the way, in Windows7+, there are ACLs that don't allow an administrator to get ownership to an object. Almighty administrator doesn't have powers anymore.

  16. Antonio Rodríguez says:

    @Joshua: you are right, and IMHO that is a bad design of the common dialog library: current directory is a process global setting, and components shouldn't change it without the main program explicitly asking for it. Of course, it can be solved by reverting the directory change after you get control back from the file dialog.

    @Leo: those were the merry old days of writing simple BASIC programs in the Apple II. Now, computers are connected to the Internet, and run a variety of software, almost all of which isn't created or even loaded by the user. The OS's main function nowadays is to protect the user from unwanted software. I would love to go back to the days of easy programming, but I do not want my customers to get infected because one of my programs had a vulnerability :-( .

  17. MikeCaron says:

    @John: This may surprise you, but all file access done by users is done via processes running on the computer. To make a distinction is pointless, because "Users" can't directly do anything anyway! Therefore, permissions should just be per process.

    In this hypothetical world, where every process has it's own set of permissions, the first line of today's punchline would be:

    1. Grant Full Control of the Windows directory (and all its contents and subdirectories) to Everyprocess.

    Suddenly, we're back in square one.

  18. Steve Syfuhs says:

    Starting with a compromised system….

    …It is possible to make it uncompromised by formatting the system and reinstalling Windows.  This is a Denial of Service because the attacker can't do anything on the vulnerable system anymore…

    …Therefore you should prevent users from formatting their drives and reinstalling Windows.

  19. John Topley says:

    OK I get it now, thanks.

  20. WendyHome says:

    "1.Grant Full Control of the Windows directory (and all its contents and subdirectories) to Everyone. " sounds like streaking on the football pitch without the aid of a policeman's helmet.  OH! …

  21. Anonymous Coward says:

    Antonio, the current directory is supposed to reflect the directory the user is currently working with. As such, it is obvious that the common dialogues should both use and set it. Doing otherwise would lead to a very frustrating user experience.

    As for the rest of the DLL loading discussion, by default Windows XP SP2 sort of fixes this, as already mentioned. However, in rare cases you can still get bitten, namely when the legitimate DLL is not installed, for example because it is an optional component, which as it happens is a common use for DLLs.

    However, you can call SetDllDirectory with an empty string to remove the current directory from the DLL search path altogether. A big downside is that this doesn't work for implicit DLLs so if you have any optional DLLs, don't for example mark the import optional and then check a registry key to see if can call the functions, because that will leave you vulnerable.

    If it would have been my decision, I would probably have removed the current directory from the search path altogether (as if this function was called) but who knows, maybe there's so much software that relies on DLLs in the current directory that adding a shim or configuration option would be unworkable. But that would really surprise me.

  22. Poochner says:

    @Wendy, Does streaking mean the same in English as in American (running out in public in the nude)?

    As for searching the current directory, loading from the exe's directory makes perfect sense, but not so much a shifting point of view.

  23. Jules says:

    @Poochner: Yes.

    @John: Even if the user is restricted in what they can achieve by their group membership and this can't be changed, granting full access to the windows directory still allows them to completely compromise the machine, because they can trivially replace one of the standard .exes or .dlls and therefore cause the local system user to do whatever they want, e.g. replace winlogon.exe with your own version and reboot.

  24. Alexandre Grigoriev says:

    @Anon:

    "the current directory is supposed to reflect the directory the user is currently working with".

    It used to make sense with command line programs. With GUI when all user's files are opened mostly through the common dialog, which remembers its last directory anyway, the notion of the current directory is not worth much anymore.

  25. DaveL says:

    This reminds me of the QA person I worked with some years ago who would randomly modify some bytes of the executable and then submit a bug report when it crashed.

  26. Rob Manderson says:

    @DaveL:

    That's what you get for not writing a self-repairing app!

    (Yikes!)

  27. Richard says:

    @Alexandre Grigoriev:

    >the notion of the current directory is not worth much anymore

    Except it is.  What if you open a file that does include an absolute path?  The relative path is taken "relative" to the current directory.  Why do you think short cut (.lnk) files have a "Start in" field.  That field becomes the current directory for the running process.  

  28. Nick says:

    [My guess is that a lot of these reports are from people seeking "street cred": "You should hire me because I found N vulnerabilities in Windows." -Raymond]

    That's probably part of it, but I think there really are a fair number of "experts" out there who really do think Windows is filled with holes and nobody but them seems capable of seeing them.  It's kind of like people who see conspiracies everywhere and don't understand why everyone else doesn't see them too.

    Reminds me of a little debate I had with somebody on Slashdot earlier this week.  Talk about an exercise in futility, read it if you care:  slashdot.org/comments.pl

  29. Paul M. Parks says:

    @Antonio Rodriguez: "The OS's main function nowadays is to protect the user from unwanted software."

    Now *that* is an expansive definition of an OS. I think some articles in Raymond's archive have touched on this theme.

  30. Michael Mol says:

    I wonder how many of these reports are from users looking for greater systemic 'depth' in 'defense in depth.' (Also known as a system override for stupid and/or malicious user-run code.)

    To shift the analogy of the airtight hatchway, consider having a firewall between your network and the rest of the world. From a security standpoint, should you assume it's safe to have every workstation inside the network run without a firewall? My old college took (and still takes) that approach, and every year or two it seems like there's a new case of some machine catching a worm, and that worm spreads like wildfire across the internal network.

    To be fair, there's already a degree of depth within Windows, with privilege separation. And, of course, if you implement an override, you'll be asked for an override for that override.* UAC was an override for users running as admin, and there's a registry setting for automating the elevation to UAC. (Should UAC pop up anyway when someone tries to modify that setting? What about the setting to override <em>that</em> setting? Whee!)

    * I know Raymond has made that point several times in the past, but I can't find the post I'm looking for. I don't think it had to do with programs whose developers had an overdeveloped sense of awesomeness.

    [My guess is that a lot of these reports are from people seeking "street cred": "You should hire me because I found N vulnerabilities in Windows." -Raymond]
  31. Alexandre Grigoriev says:

    @Richard:

    If a program is using current directory to open its files, then it's badly written. A current directory is never guaranteed to point to anything meaningful. And not every directory can even be used as current. UNC paths can't.

  32. Alexandre Grigoriev says:

    @Nick:

    The /. guy also naively doesn't want to see that all OS are vulnerable to the tampering via an alternate boot, which he proclaims a genuine Windows weakness. Actually, with a boot drive encryption, Windows is immune against that, as well.

  33. Cheong says:

    @Michael Mol: Oh firewall, my favorite story involves the fact that certain people doesn't (or pretend not to) understand putting machines in DMZ zone would remove protaction from firewalls. Some external users call-in to report they cannot connect, and the admins tweaked settings to add forwarded ports. Later they become annoyed, and found that putting server in DMZ zone and the users won't call in… When they were asked whether their servers are secure, they said yes because every servers are behind firewall……

  34. Joshua says:

    As for numbskull left a gaping hole that might get reported to Microsoft even though it's none of Microsoft's fault:

    1. Administrator installs cygwin sshd for his own use.
    2. Administrator mounts /home onto C:Users because that's convenient.

    3. Administrator enables public key authentication because its convenient for automation from some *nix box somewhere.

    4. Some other user with access notices sshd is available and sets up his public key.

    5. [much later] Administrator disables some other user's account as that user left the company (delete wouldn't help).

    6. [much later] Some user notices that he can still log in via sshd public key authentication.

    What happened here is Administrator enabled sshd public key authentication without understanding the ramifications. The cygwin tools have their own implemenation of cached account information (not credentials but everything else required to log in). When using sshd's public key authentication, no password is required, so cygwin, having everything it needs, logs the user in without even trying to authenticate via LSA.

  35. Medinoc says:

    @Joshua: Another vulnerability via SSH server is FreeSSHd prior to Windows Vista: It's an interactive service, that can open "Open" dialog boxes… Hello, cmd.exe under NT AUTHORITY/SYSTEM account, from any user!

  36. 640k says:

    A dumb user is not an excuse for writing sloppy code. Programs should NOT fail at the first user mistake, programs should help the user when the user makes mistakes.

  37. 640k says:

    @Alexandre Grigoriev: Actually, with a boot drive encryption, Windows is immune against that, as well.

    Until you boot with a floppy/cd/usb dongle.

  38. Cheong says:

    @Antonio Rodríguez: But *nix systems have their kinds of dumb things as well.

    For example:

    1) The infamous "rm -rf /" for those having habit to run as root at all time.

    2) Tricking noob admins to grant root impersonation priviledge for all users without password by telling them modify sudo config file some way can allow them run sudo commands without typing password.

    3) Granting full control of FTP access to web folder in certain event where users call in for unable to write files there, without recognising that'd give them ability to write other other's folder as well…

    Btw, there's something that Windows can copy from *nix for security. For example, in Linux email server would refuse to start if you got the /etc permission wrong. Perheps certain Windows system service can perform this kind of check as well…

  39. Cheong says:

    @Antonio Rodríguez: But *nix systems have their kinds of dumb things as well.

    For example:

    1) The infamous "rm -rf /" for those having habit to run as root at all time.

    2) Tricking noob admins to grant root impersonation priviledge for all users without password by telling them modify sudo config file some way can allow them run sudo commands without typing password.

    3) Granting full control of FTP access to web folder in certain event where users call in for unable to write files there, without recognising that'd give them ability to write other other's folder as well…

    Btw, there's something that Windows can copy from *nix for security. For example, in Linux email server would refuse to start if you got the /etc permission wrong. Perheps certain Windows system service can perform this kind of check as well…

  40. John Topley says:

    @Jules Yes, I realise that. Whilst replacing winlogon.exe might be trivial, I would suggest that writing your own version probably isn't!

  41. Medinoc says:

    Thank you. This cleared some misunderstandings.

  42. Alex Grigoriev says:

    @640k:

    If you don't know the password, you can't mount the encrypted drive, even if you boot from floppy/cd/usb. Because all metadata is also encrypted. That's the whole point of encrypting the drive. If you lose the laptop, your data won't leak.

  43. Medinoc says:

    By the way, I never understood *who* says an ActiveX control is safe for scripting. Is it the control maker or the administrator?

  44. Superdude says:

    @Paul M. Parks: Now *that* is an expansive definition of an OS.

    It's the minimum you should require from an modern OS. Definitions like os=kernel+cli are of last millenia.

  45. Mike Dimmick says:

    @Medinoc: "By the way, I never understood *who* says an ActiveX control is safe for scripting. Is it the control maker or the administrator?"

    It can be anyone. You register the control in the 'Safe for Scripting' Component Category, which is just a registry setting. Typically, though, it's done by the control's DllRegisterServer function, and/or the installer (which may well call DllRegisterServer).

    The other, and better, way is for the control author to implement IObjectSafety, which allows it to be a conversation rather than a yes/no answer.

    Unfortunately, it was really common for control authors to do this without really thinking about whether it was truly safe for the control to be scripted. It became default-ON rather than default-OFF. This is particularly true of controls that would be useful in intranet applications but would be dangerous when used from the Web. Or even, applications that use the WebBrowser control, but are not Internet Explorer, and use ActiveX controls to make up part of the UI. Like Visual Studio's C++ wizards from VS2002 onwards (idiotic decision, because anti-virus programs wind up stopping some of them from working, and some of them broke when IE8 was released – oh, and they're so slow that they become useless).

    Since 'Safe for Scripting' is just a registry entry that anyone can add to, you couldn't easily stop a control known to be bad just by deleting it (and a flawed IObjectSafety implementation couldn't be stopped that way). So IE's 'kill bits' are stored somewhere else.

  46. Richard Russell says:

    @Alexandre: "If a program is using current directory to open its files, then it's badly written".

    Why?  I've written programs that are designed to be run from a shortcut, and which use the setting of the 'Start in' property to determine the location of the files they will work on.  What's wrong with that?

  47. Random832 says:

    "Whilst replacing winlogon.exe might be trivial, I would suggest that writing your own version probably isn't!"

    ReactOS has an open-source version, one could use that as a starting point. Security through obscurity never works, and security through requiring a token bit of effort works even less.

  48. GregM says:

    Richard, I'd say that's the difference between opening files from the initial directory and from the current directory.

  49. Richard Russell says:

    @GregM: "I'd say that's the difference between opening files from the initial directory and from the current directory".

    What you seem to be saying is that it's OK to use the Current Directory on initial entry to your program (because that's what the 'Start in' property of the shortcut sets) but not later on.  However I don't see the distinction; the only way the Current Directory can change is if the program itself does so (either directly using SetCurrentDirectory or indirectly, e.g. by calling GetOpenFileName without the OFN_NOCHANGEDIR flag) so if the program is written such that the Current Directory never changes, it should be OK to use it at any time.

  50. GregM says:

    Richard, if you can guarantee that, then yes.  This means, for example, that your program never calls any third party code, either directly or indirectly, that changes the current directory, such as a printer driver that has a file dialog without that flag,.

  51. Engywuck says:

    At the Win7 introduction tour some Microsoft evangelist said (in german, translated by me): "One of the most common questions Microsoft is asked is: 'Our users have administrator accounts on their computers. How can I make sure that they don't…' — and at this point one can stop listening because the answer is always the same: Unless you stop having them have admin accounts you can't do anything, since every (full) Administrator has all the rights necessary to kill every limitation you could possibly add. Even GPO settings can be simply reversed by editing the registry."

    And he's fully right: the person with the right to change everything by default has the right to do so. And topmost on every computer is the Local Administrator. In at least XP/W2k3 (not tested later) one could even get SYSTEM rights with some simple careful invocations of certain (included) programs…

  52. 640k says:

    "current directory" is a hack whose features has changed between windows versions and been completely removed on Wince. Can't trust it.

  53. Joshua says:

    @Jules: actually in this particular case, writing your own winlogon.exe is not trivial, but not all that difficult either. You see, it's not all that hard to modify the binary near the entry point to load a .bin file somewhere else in memory and call CreateThread on it, followed by reading in another .bin to put the original code back and jump to it (syscall chaining).

  54. Stefan Kanthak says:

    @Alex Grigoriev

    Stop spreading FUD and misinformation!

    1. Relative, i.e. non-absolute paths, are always relative to the CWD.
    2. CWD can of course be set to UNC paths, and Windows does.

        Use Windows explorer, navigate to some network share using it's UNC path and double click any executable^Wfile there.

        Check MSKB article 156276 (rather old.-P) too!

  55. Gechurch says:

    This talk of modifying winlogon.exe has me confused. Who cares how hard it is to write? That's besides the point. If a user has write access to that file you are already on the other side of the air-tight hatch. You can modify a system binary that runs with full access. And this is hardly security through obscurity. By that definition every program and OS ever written uses security through obscurity throughout – because you can go in and change the code and it will do whatever you want! No, it's security through ACLs. If you modify those ACLs to give users full control of that file, don't be surprised that you have just lost said security.

Comments are closed.

Skip to main content