Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Why does Windows share the root of your drive?

Why does Windows share the root of your drive?

  • Comments 25

Out-of-the box, a Windows system automatically shares the root of every hard drive on the machine as <drive>$ (so you get C$, D$, A$, etc).

The shares are ACL'ed so that only members of the local administrative group can access them, and they're hidden from the normal enumeration UI (they're included in the enumeration APIs but not in the UI (as are all shares with a trailing $ in their name).

One question that came up yesterday was why Windows does this in the first place.

The answer is steeped in history.  It goes way back to the days of Lan Manager 1.0, and is a great example of how using your own dogfood helps create better products.

Lan Manager was Microsoft's first attempt at competing directly with Novell in networking.  Up until that point, Microsoft produced an OEM-only networking product called MS-NET (I have a copy of the OEM adaptation kit for MS-NET 1.1 in my office - it was the first product I ever shipped at Microsoft).

But Lan Manager was intended as a full solution.  It had a full complement of APIs to support administration, supported centralized authentication, etc.

One of the key features for Lan Manager was, of course, remote administration.  The server admin could sit in their office and perform any administrative tasks they wanted to on the computer.

This worked great - the product was totally living up to our expectations...

Until the day that the development lead for Lan Manager (Russ (Ralph) Ryan) needed to change a config file on the LanMan server that hosted the source code for the Lan Manager product.  And he realized that none of the file shares on the machine allowed access to the root directory of the server!  He couldn't add a new share remotely, because the UI for adding file shares required that you navigate through a tree view of the disk - and since the root wasn't shared, he could only add shares that lived under the directories that were already shared.

So he had to trudge from his office to the lab and make the config change to the server.

And thus a new feature was born - by default, Lan Manager (and all MS networking products to this day) shares the root of the drives automatically to ensure that remote administrators have the ability to access the entire drive.   And we'd probably have never noticed it unless we were dogfooding our products.

Nowadays, with RDP and other more enhanced remote administration tools, it's less critical, but there are a boatload of products that rely on the feature.

Note1: You can disable the automatic creation of these shares by going to this KB article.

Note2: The test lead for the Lan Manager product was a new hire, fresh from working at Intel who went by the name of Henry (Brian) Valentine.

  • And there are many products - I think Microsoft Baseline Security Analyzer is one, and I know that Grisoft's AVG Network Edition's remote install feature is another - that make use of the ADMIN$ share to push a program onto a workstation, then use the SCM API to launch said program. That's how Sysinternals' PsExec works (http://www.windowsitpro.com/Windows/Article/ArticleID/42919/42919.html - see page 2).

    For those who feel this is a security risk, turn Windows Firewall on. For administrators in a domain, use Group Policy to configure the Remote Administration exception.
  • If someone had done that in a team I managed I would have fired them on the spot. This type of hack is absolutely counter to any sense of security on a system and worse still it is hidden from the user, I myself wouldn't have even let it ship in XP.

    Back then couldn't you have used a service to gain access to *only what was required and not the entire drive?

    I hope this "feature" is removed by default in Longhorn, Microsoft have broken things before to secure a system (see SP2) this is one of the big ones next to printer sharing...
  • Manip,
    See Mike's comment. It's not a security hole. And if you don't like it, you can disable it (and you can deploy that via group policy). But you ARE going to break things. Things like networked virus scanning, remote backup, and other management utilities that require this functionality.

    The only people who can access this share are the people you've chosen to be able to administrate the box. Nobody else.

    And it's NOT hidden from the user. Start explorer and look at the properties of the root of your drives. See the "Sharing" tab? There's where it shows that the drive is shared. So will the NET SHARE command from the command line.

    The only place they're hidden is from the NET VIEW \\server command won't show it, because these are administrative-onlyshares, but they're NOT hidden.

    And a service that allowed enumeration and access to all the files on a hard disk only for users is functionally identitical to the admin shares - there's no security benefit to wrapping the admin access to the filesystem in a service that's separate from the file&print services, and you lose a huge amount of flexibility.
  • Interesting; I didn't realise they dated back quite that far! I'm not hugely familiar with LAN Manager, having cut my teeth on NetWare; at the same time we also had a system based around MS-NET (RM-NET, for those familiar with Research Machines -- a mainly-educationally-biased UK OEM), which was rather inflexible and irritating by comparison. Much of that was probably down to the really horrible networking hardware RM fitted to their kit; it was proprietary, I believe, and had no smarts in the NIC. Every single packet caused an interrupt and the poor old 8088 or 80186 in the machine had to drop what it was doing to work out if the packet was addressed to this node. Nice. Coupled with the less-than-stellar admin software they provided... *shudder*

    Anyway, was cool to hear where those shares came from. We actually use them in part of one of our products, when dealing with home directories and shares in general.

    Out of interest, why was it done that way rather than altering the UI to allow any path on the server to be shared? I don't think the (current) APIs require a new share to be under an existing share... Was it just that there was no way of querying the directory structure on the server so it would end up being trial-and-error to type a path that was valid?
  • SafeXP is simpler and faster than playing registry spelunker yourself. You can lock some of windows down as much or as little as you need to.

    http://www.theorica.net/safexp.htm

    Only problem comes when you disable, say, file sharing and admin shares and then later need to re-enable them all to roll out a new system. But that's not the tool's fault. ;)

    These are only a danger in the case of a weak or non-existant admin password (pre-xp), or from privledge escalation attacks, at which point the box is owned anyway.

    Don't most windows uis to connect to other server tools (like wins, dns, services, etc) still use IPC$? Besides all the third-party ones that do.
  • SafeXP is simpler and faster than playing registry spelunker yourself. You can lock some of windows down as much or as little as you need to.

    http://www.theorica.net/safexp.htm

    Only problem comes when you disable, say, file sharing and admin shares and then later need to re-enable them all to roll out a new system. But that's not the tool's fault. ;)

    These are only a danger in the case of a weak or non-existant admin password (pre-xp), or from privledge escalation attacks, at which point the box is owned anyway.

    Don't most windows uis to connect to other server tools (like wins, dns, services, etc) still use IPC$? Besides all the third-party ones that do.
  • baljemmett: The problem is that the UI has no way of accessing the files on the server - they weren't shared. And exposing an RPC interface to enumerate the entire filesystem on the server (even admin-only) was probably more work than adding the admin-only shares. And the admin-only shares provided significant value-add - you could edit the files directly without having to go in and share the directory.

    Foxishadis: Some windows tools still use named pipes (that's the ones that use IPC$), I'm not sure what the new ones use.
  • "It's not a security hole."

    Wrong, it is. I can access all files on the partitions thus yes it is very much so.

    "And if you don't like it, you can disable it"

    I see you lean to-wards the "make it insecure by default" mind set. I on the other hand lean to-wards the "secure by default" (or at least up to a point).

    "But you ARE going to break things. "

    So? Domain administrators normally deploy custom imagines over the network anyway let the burden fall on them to re-enable it. Also why is this active when in workgroup mode? With small business server (and Linux/Samba) there is no real excuse for an Office network of any size to not be running a DC.

    Attitudes like this are what makes Windows a security joke today; until you fix the mindset you have no chance of fixing the software.
  • Manip,
    In order to use the admin shares, you need to be a member of the local administrators group. If you're a member of the local administrators group, then you can access all the files on the system anyway. The presence or absence of the share doesn't change the risk at all.

    Why is this enabled in workgroup mode? I don't have an answer to that.
  • Thanks for adding those shares. I use them daily :)

    There has been security problems with them before (and in particular IPC$, see [1] for one I found. Searching for IPC$ and/or null session gives you some more). All of these have been fixed a couple of years ago now. Don't think the main cause was the network browsing, but rather what kind of access a "null session" gave you (was part of Everyone). So I assume that you could have exploited that through a different component then the network browsing (IPC$). But network browsing was the easiest way to exploit it, i.e. could do it with the tools shipping in Windows.
  • > Why is this enabled in workgroup mode? I
    > don't have an answer to that.

    OK I got here a few minutes too late to ask that question myself. Nonetheless I hope you understand that the complaints about security are correct.

    > And it's NOT hidden from the user.

    Yes and no. In NT4 the fact of sharing was less hidden, but the details (which kinds of users/abusers had what kinds of privileges) were completely hidden. Now the fact of sharing is moderately hidden (Explorer doesn't show it immediately but you pointed out how to get to it), but the details (which kinds of users/abusers have what kinds of privileges) are still hidden.

    I have co-workers who were still using Windows 2000 as recently as 2003 or even 2004. I showed one of them why he needed to set a password for his Administrator account. And guess what, I'm not a domain admin or local admin in this company.

    > For those who feel this is a security risk,
    > turn Windows Firewall on.

    Sure. Or use Kerio which is free[*] and also works on Windows 2000. But then remember the mindset that got these Admin shares put in and enabled by default and mostly hidden. The same mindset will find ways to punch holes in the firewall[**] to reopen this security hole.

    [* Though it wouldn't be free for commercial use, such as if it would be installed on my co-worker's machine where it was needed.]

    [** The second-to-last time that I cleaned up a Windows XP system for a friend, after deleting some spam servers, I also closed the firewall holes that the spam server installers had added. Would the spam server installers be able to punch the same holes through Kerio as they did through the Windows XP built-in firewall, I don't know.]
  • By default, a username without a password simply cant not be used to access a network resource.

    An admin username with no password is the most secure type of password you can have for network access. Since the account just cant be used for network access.

    However, a blank password doesnt help if you have local access to the machine.
  • M Knight:

    I don't know what OS you use, but let me assure you that on Windows 2000 an account in the Administrative group without a password can remotely access and modify an administrative(driveletter$) share. I see no reason this wouldn't have worked in the previous seven or so (depending on how you count) version of NT.
  • "Wrong, it is. I can access all files on the partitions thus yes it is very much so."

    Your "security hole" is the fact that you are an administrator - you have already been given permission to access the files on that machine (though possibly by someone who only expects you to be able to do so when connected locally).
    The default existence of the DRIVE$ shares does nothing to alter this - you could, as an admin, manage the computer locally and set up a root share on each drive yourself.

    And as a point of correction you do NOT have permission to "access all files on the partitions".
    You have whatever permissions have been granted to you - administrators usually have the right to take ownership of files, but they do not need to have DACLs allowing them access.

    "I on the other hand lean to-wards the "secure by default""
    I would agree with that, what is the situation with Longhorn?
    The shares are widely used and it would be foolish to require them to be individually manually created, but it would be better if there was a per machine setting to enable/disable them all (and that should default to disabled).
Page 1 of 2 (25 items) 12