MS network API functions fail if native executable is started from a network share

Question

If we have a native executable that uses API network function calls like socket, ldap_init or ADsGetObject,
these calls may fail if the executable is started from a network share. The problem seems to be related to
the access rights on the share and the lower path where the executable resides. In my scenario I have a public
share on a Windows 2003 domain member server where no user has access e.g. C:\Public on SERVER01. If I create
the directories C:\Public\Dir1 and C:\Public\Dir1\Dir2 and grant the user full access to Dir2, the executable
can be started from a Windows 7 client machine, but any network API calls fail at run time.

If I set the user access for C:\Public and C:\Public\Dir1 to the special permission "List Folders / Read Data"
to allow, the network calls succeed. I experienced, that even if one directory in the UNC path
\\SERVER01\Public\Dir1\Dir2 has not the special permission "List Folders / Read Data" for the users group, the
network API calls fail.

The same problem exists if I use the task scheduler to run an executable from a network share by using the local
system account. The executable is started without a problem, not the usual access denied COM error 0x80070005,
but the network calls fail again. This is the same reason as for the user group, because if I grant the special
permission "List Folders / Read Data" to the group "Domain Computers", it works correctly. Here also the special
permission has to be applied to the complete UNC path and not only the executable directory.

I wonder if this behavior is by design, why a user without the special permission on the upper share directories
can still access the directory with the executable. So I think this is no denied access at all, but more of a
Windows bug. For now I discovered at least 3 API function calls that give problems, but I doubt that are the only
ones. It seems every network access from inside the executable is blocked.

As far as my investigation goes, this issue was first discovered by the following thread:
http://social.msdn.microsoft.com/Forums/en-US/wsk/thread/3076a9cd-57a0-418d-8de1-07adc3b486bb

The user Rukh13 solved the issue himself by applying more access rights to the upper directories, but Microsoft
never replied if this is a known bug or defective by design. I stumbled across this issue myself and searched
the internet for a few days now without any success. I tested this on Vista x86 (No SP, SP1, SP2), Windows 7 x86
(No SP, SP1) and the problem still exists. For XP x86 SP3 this problem does not exist. In XP it is enough to grant
access rights on the executable itself to run it successfully. To get a better understanding of the problem I added
the source code for 3 executables and their binary image as PellesC and Visual Studio 2010 projects. These executables
should be called like follows:

- ADsGetObject.exe LDAP://DC=CONTOSO,DC=COM
  argument 1 is the LDAP connection string
  Problematic Function call: ADsGetObject
  Return code HRESULT: 0x80070035
  The network path was not found.

- socket.exe
  no arguments needed
  Problematic Function call: socket
  Return Code WSAGetLastError: 0x2726 (this is the same error as in the thread link above, 10022 decimal)
  An invalid argument was supplied.

- ldap_init.exe SERVER01
  argument 1 is the LDAP server name
  Problematic Function call: ldap_init
  Return code LdapGetLastError: 0x5B
  LDAP_CONNECT_ERROR

Download-Link: https://rapidshare.com/files/3657619196/SourceCodeExamples.rar

How to simulate the behavior

- on a Windows 2003 Domain Controller, in our example called SERVER01, create a new directory C:\Public
  This Problem also exists on other Windows 2003 member servers.
- right click on C:\Public > choose Properties > open Sharing tab > select "Share this folder" and set Permissions
  for the group Everyone to "Full Control"
  Reason for the change: This creates a new share named Public on SERVER01.
- choose the Advanced button > uncheck "Allow inheritable permissions form the parent to propagate to this object..."
  > click Copy button > OK
  Reason for the change: This lets us define access rights on the C:\Public directory without inheritance from
  the above directories.
- in the Security tab remove all groups except the "Domain\Administrators" and the SYSTEM group entry > OK
  Reason for the change: We do not want domain users to access C:\Public, but Administrators are fine.
- create the directories C:\Public\Dir1 and C:\Public\Dir1\Dir2
  These newly created directories now inherit the access rights from C:\Public.
- because we want domain users to access C:\Public\Dir1\Dir2 add the group "Domain\Users" to the ACL of Dir2 and
  give it "Full Control"
  Reason for the change: The domain users should have access to Dir2 but not to Dir1 and the Public directory.
- copy one of the supplied executables to C:\Public\Dir1\Dir2, these executables should now have the same access
  rights as Dir2, so the group "Domain\Users" has full access
- now log on to a Windows 7 domain computer with a user that is a group member of "Domain\Users", but not of the
  "Domain\Administrators" group
  After the logon this user should have full access rights on the directory \\SERVER01\Public\Dir1\Dir2. We can
  verify this by typing "\\SERVER01\Public\Dir1\Dir2" in Windows Explorer. We see the executable copied there
  and can create and modify files in the directory Dir2.
- open a command prompt on the Windows 7 machine and run the executable like:
  \\SERVER01\Public\Dir1\Dir2\ldap_init.exe SERVER01
  If you have no Domain Controller for testing ldap_init.exe may fail on the member server. Therefore you can use
  socket.exe for testing, this should reproduce the problem on every server.
- We see that ldap_init fails with a return code of 0x5B (LDAP_CONNECT_ERROR). The same applies to socket.exe which
  fails with return code 0x2726 (An invalid argument was supplied.) and ADsGetObject.exe which returns HRESULT:
  0x80070035 (The network path was not found.).
- on SERVER01 right click C:\Public\Dir1 > choose Properties > open Security tab > click Add... > add the group
  "Domain\Users" > OK > click Advanced > select Users > click Edit... > uncheck all Allow boxes > check only the
  "List Folder / Read Data" Allow box and choose "Apply onto: This folder only" > OK > OK > OK > do the same for
  the shared directory C:\Public
  Reason for the change: We now add the group "Domain\Users" to the directories C:\Public\Dir1 and C:\Public with
  the special permission "List Folders / Read Data" only.
- again open a command prompt on the Windows 7 machine and run the executable like:
  \\SERVER01\Public\Dir1\Dir2\ldap_init.exe SERVER01
- We now see that all executables run without a problem. As it seems the access rights change the API network
  functions in a way that they can not execute correctly.


Maybe someone can tell me what is going wrong.
Many thanks in advance for any help, much appreciated!

Answer 1

I tried to search this like report through internal ways, but I have not got a report described this, maybe I have not used the very correct keyword.

But it also would be a security design in Windows 7 System.

How about turn off the UAC, just a thinking?

If this cannot let it work, then please let me know, then I will try to involve others senior engineer to help you on this question.

Best wishes,

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 2

Thank you for your help. I have UAC turned off, but this makes no difference at all. I also have used fresh installs of Vista, Windows 7 and XP for the tests. Even the 2003 member server was reinstalled before, so no other software conflicts with the access rights. The 2003 Server was a standard install, so no Group Policy gets in the way of the tests. I also have turned off Windows Firewall to make sure no port is blocked. The most weird about it is, that if this is a security feature it does not work properly, because you can copy the executable from the network share to the local workstation and launch it from there. Then the network functions will work successfully!

Greets kondra

Answer 3

Ok, I will involve others senior engineers into this thread, and they will give you replies once they have any idea can help you.

If there's any concern, please feel free to let me know.

Best wishes,

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 4

I'm looking forward to your professional help. Many thanks in advance!

Answer 5

You're welcome!

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 6

This issue occurs because of a change in the behavior of Windows Filtering Platform (WFP) that was implemented in Windows 7 and in Windows Server 2008 R2. Please check the KB article http://support.microsoft.com/kb/2649107 for more information. You can contact Microsoft Customer Service and Support to obtain the hotfix. Thanks.

---

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Answer 7

Thanks for investigating into the problem!

I downloaded the hotfix and the installation tells "The update is not applicable to your computer.". After a little more investigation I found out, that I have to activate the "Services for Network File System"to make the hotfix work. So I activated the services and installed the hotfix, but the problem stays the same. I also wonder how a not installed component like the NFS service can give problems if the driver nfsrdr.sys is not loaded at all. In addition I do not use any Unix shares, only a Windows 2003 Server. The KB article says the hotfix only applies if the executable file is located on a Network File System (NFS) share in which the share name contains a path separator such as /root/share. This is not the case in my scenario.

I also use other functions which I think do not use the winsock library at all like ADsGetObject.

The good news is that the suggested workaround from the KB article works with a little change on my different problem also. I changed the UNC path name to have at least nine characters and not eight. At the moment I think there is still something wrong, but maybe the same fix that MS applied to nfsrdr.sys can also work for another driver which has a similar problem.

Edit:

If I use nine characters in the path name e.g. "\\SERVER01\Public000\Dir000001\Dir000002" it only works if the access rights are missing at the shared folder Public000. If I delete the access for Dir000001 or Dir000002 I have the same problem again. In addition it seems on longer path names also the Special Permission "Read Attributes" has to bet set.

Answer 8

As the workaround also works on your problem, we believe that the socket function problem can be related to the WFP issue which is fixed in KB2649107. However, I'm not sure why the fix is only populated in NFS service but not in the WFP itself. As this is not a good place to discuss a bug or verify a fix on Windows platform, I'd like to suggest you open a case to Microsoft support to verify the fix if necessary.

---

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Answer 9

Strange stuff is going on here. This guy has the same problem since January 2011 and no one answered to him if this is a bug or not.

http://social.technet.microsoft.com/Forums/en-US/w7itprosecurity/thread/b7ca94cc-0bd1-4134-ad0d-74a632ca076a/

I investigated further and also saw that the ZwCreateFile function inside mswsock.dll fails with return code 0xC0000225. So this problem is public already!

Answer 10

Can it have something to do with traversal check?

-- pa

Answer 11

@Pavel A: This is a very good idea. I tested it with my "Default Domain Controllers Policy" on the Windows 2003 Server, but after disabling the Users group for "Bypass traverse checking" I got the error "Access is denied" for the user's command prompt and COM Error 0x80070005 in the task scheduler if the executable from the share was run as SYSTEM. So the system can interpret this group policy setting and set access denied correctly. In addition the access in the standard configuration for "Bypass traverse checking" is:

Administrators

Authenticated Users

Everyone

Pre-Windows 2000 Compatible-Access

So the users and local system account should already have that access right. Another point is that the Windows 2003 Server access works for Windows XP without a problem and the policy setting used is that on the server, because it hosts the share.

Thanks for your suggestion, Mark Russinovich is always worth a read!

Answer 12

@kondra: did you ever resolve this issue? We have a similar issue...

Answer 13

Nope, I haven't solved this yet. I investigated further into the problem and found out that the so called Windows Filtering Platform can not be disabled as it seems. In the MS documents it is described as if you deactivate a few services it will shut down. But in real the WFP is directly build and compiled into tcpip.sys! There are Wfp function references all over tcpip.sys. You can see this in the kernel debugger clearly.

In my tests I disabled the Windows Firewall completely and even shut down the Base Filtering Engine Service without success. This means to me that we can not simply disable this filtering crap, which it is in my opinion. If this works it would be ok, but as an Admin I have to say: If you can't disable it, don't install it. :-)

What drives me even more mad is that MS already seems to have a fix for it for the Network File System stuff, but does not tell what really caused the problem in that driver. I bet it must be the same problem for tcpip.sys.

Only thing you can do to date is giving the "Authenticated Users" group read access to the full share and directory path inside the share. If you use services that start executables from the network you can further improve security if you give access only to the group "Domain Computers". This way the users have no access to the path and only the machine accounts can access it.

It would be nice if MS wanna fix this issue, but my impression after all the numerous threads I have linked to is, that MS wants this problem to go away by itself. Maybe the WFP is defective by design or has a new self healing feature implemented which turns on 2013?!

If I have time to investigate further into the problem I will report back here.

Answer 14

Thanks for the info, Kondra.

Is the "Domain Computers" approach what you are using as a workaround so you can still have the permissioning the way you want it?

Answer 15

Granting access to the group "Domain Computers" will only work if you start the executable as a scheduled task by the SYSTEM account of the machine from the network or as a service. The users will not have access this way. If you have users that need to start executables from the network you can only set the read permission, but it is not always optimal if users see all files inside a folder. Some may only want them to see the single executable that can be launched and NOT all the parent directories.

Answer 16

That is helpful. Thanks for the info.

Do you have Premier Support through MS? If so, have you tried that route?

Answer 17

No I have no support through MS. I am only a private computer nerd. In addition I hate that fixing bugs is dependent on your support status, which seems it is in this case. I would be glad if someone else with premier support could create a MS bug report. Feel free to use my tests and programs if you do so.

Answer 18

Old thread however the problem is still here. We've opened a support case with MS for it, i'll let you know how it goes. Did you ever find a solution other than the workarounds?

Answer 19

MS is still working on this issue.

This problem is extremely easy to reproduce on any win7, win2k8,win2012 (haven’t tested xp or vista) by doing the following:

1. Log in as administrator
2. Create a standard user called ‘test’
3. Create a folder c:\myshare
4. Share the folder c:\myshare and add Full Control to Everyone on the share
5. Right click the folder, click Properties -> Security -> Advanced and Remove the checkbox “Include inheritable permissions from this object’s parent” (select copy)
6. In the permission entries, remove everything except Administrators and System and CREATOR OWNER
7. Click OK and OK again
8. In the c:\myshare folder, create  a new folder called ‘test’
9. Right click that folder and add Modify permissions to the user ‘test’ created in step 2
10. Log in as the user ‘test’
11. Map a network drive, eg Z: to \\localhost\myshare\test
12. Try to run an executable that does any network activity from Z:, it fails
13. To verify that this only fails for <= 8 chars for the ‘test’ name, unmap the net drive, rename the folder test to testtest2 (9 chars), map the drive again, and run the exe, it works.

Answer 20

Old thread however the problem is still here. We've opened a support case with MS for it, i'll let you know how it goes. Did you ever find a solution other than the workarounds?

Thanks for opening an official case! I never found any other solution than the workarounds.