Why does Windows share the root of your drive?

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.

Comments

• Anonymous
  May 26, 2005
  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.
• Anonymous
  May 26, 2005
  The comment has been removed
• Anonymous
  May 26, 2005
  The comment has been removed
• Anonymous
  May 26, 2005
  The comment has been removed
• Anonymous
  May 26, 2005
  The comment has been removed
• Anonymous
  May 26, 2005
  The comment has been removed
• Anonymous
  May 26, 2005
  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.
• Anonymous
  May 26, 2005
  The comment has been removed
• Anonymous
  May 26, 2005
  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.
• Anonymous
  May 26, 2005
  The comment has been removed
• Anonymous
  May 26, 2005
  The comment has been removed
• Anonymous
  May 26, 2005
  The comment has been removed
• Anonymous
  May 26, 2005
  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.
• Anonymous
  May 26, 2005
  The comment has been removed
• Anonymous
  May 26, 2005
  REMOTELY, REMOTELY!
  you could, as an admin, manage the computer remotely and set up a root share on each drive yourself.
  
  Doh!
• Anonymous
  May 26, 2005
  Does anyone else notice how a lot of the above posters are ignoring the consumer market? I mean admin by default, passworded suggested..
  
  With a default install of XP someone can remotely access all your data and as the XP setup suggests you set a password there is something to be cracked...
  
  I am talking about SOHO and consumers, you guys seem to be talking about highly qualified technical professionals that understand how remote login works (and are even aware it exists).
• Anonymous
  May 26, 2005
  Manip,
  
  When you have Simple File Sharing turned on in Windows XP (that's the default for Windows XP Professional not joined to a domain, and it's the only choice for Windows XP Home), then the admin shares are disabled.
  
  The admin shares are only available if you have Simple File Sharing turned OFF which is only the default for Windows XP joined to a domain.
  
  See http://support.microsoft.com/default.aspx?scid=kb;en-us;304040 for information on Simple File Sharing.
  
  And remember, there is no security issue if a given feature (or bug) does not give you access to more things that you'd normally have access to. It doesn't mean it's not a bug, of course, it's just not a security bug. If you're an administrator on the machine, then you have access to all it's files anyway and adding an extra share doesn't give you anything except convenience.
• Anonymous
  May 26, 2005
  I'll be. That KB article indeed says that simple file sharing disables domain admins from accessing the administrative shares.
  
  So now we've got the opposite problem. In a company that does want domain administrators to be able to access administrative shares, any user of Windows Explorer can defeat it by going into Tools - Folder Options - View and setting simple file sharing.
  
  Shouldn't this kind of setting be done in Computer Management? or in Control Panel?
• Anonymous
  May 26, 2005
  Norman,
  
  Actually, I just tried it on my computer that's connected to a domain and it looks as though enabling Simple File Sharing does nothing. So it might be that Simple File Sharing only works when not connected to a domain, not just by default.
  
  I'm sure there's people who know more about this than I do, though...
• Anonymous
  May 26, 2005
  You are inaccurate. They are not *disabled they are *inaccessible. I do wonder if you were able to clone the SID if you could access them even with SFS turned on?
• Anonymous
  May 26, 2005
  Mike, I guess it only applies for Windows XP onwards then.
  
  It is controlled by the group policy "Accounts: Limit Local account use of blank passwords to console logon only".
• Anonymous
  May 30, 2005
  PsExec
  
  now thats funny. Just had a lengthy conversation with someone on this late last week. Basically the discussion started on how to perform remote DLL registration and the guy wanted to know how to do this. After a short discussion on an approach, this tool came up.
  
  He didn't realize one makes plenty of assumptions on remote access (e.g. firewall blocking ports, filesharing turned off and of course remote admin creds ..etc).
  
  This is a pretty interesting onion but theres alot of ways to skin a cat too.
• Anonymous
  June 15, 2005
  Interesting discussion. While i don't consider the share itself to be a huge security risk, the fact that Windows XP and 2000 let you get away with installing them without a strong password for the local Administrator account is a HUGE issue. I bet that i could access over 90% of the root shares of the computers logged in to my university that are owned by the students (i.e. their laptops).
• Anonymous
  June 15, 2005
  Stephan,
  Passwords on shares? What do you mean? Shares haven't had passwords since Win95.
  
  If you're thinking about the strength of passwords on the administrative accounts, that's a group policy - Windows itself can't enforce strong passwords, for users that want to shoot themselves in the foot, Windows will oblige.
  
  Having said that, I don't know (for real), but I would speculate that Longhorn may warn the user about weak passwords.