syscall: guard against Windows DLL preloading attacks

[bradfitz]

Taru Karttunen noted that Go should be more paranoid by default when loading DLLs.

Background:
https://textplain.wordpress.com/2015/12/18/dll-hijacking-just-wont-die/

Microsoft's guidelines:
https://msdn.microsoft.com/en-us/library/ff919712%28VS.85%29.aspx

LoadLibraryEx docs:
https://msdn.microsoft.com/en-us/library/ms684179(v=vs.85).aspx

@rsc proposed:

1. Change syscall.LoadDLL to call LoadLibraryEx with flags=LOAD_LIBRARY_SEARCH_SYSTEM32 instead of calling LoadLibrary. That is, LoadDLL is now secure by default and cannot load DLLs from the directory containing the executable.
2. Add a LoadLibraryEx to x/sys/win so that users can still get at the old behavior if they want it (by appropriate passing of flags).

CL forthcoming.

/cc @alexbrainman @adg @broady @jbuberel @ianlancetaylor

[bradfitz]

/cc @taruti, too.

[bradfitz]

Proposed fix: https://golang.org/cl/21140

[minux]

I'm not convinced that Go needs to solve this problem because dso hijack is
equally easy on Unix (e.g. via LD_PRELOAD) and yet we don't protect from it
(I actually think it's a feature, not a bug.)

Besides, this is not backward compatible as we silently changed the semantics
of syscall.LoadDLL.

I'm fine if we only change the runtime to load ntdll.dll, kernel32.dll, etc. with
LOAD_LIBRARY_SEARCH_SYSTEM32, but we should definitely preserve
the existing syscall.LoadDLL behavior.

[bradfitz]

Your analogy isn't complete.

Windows users download binaries and double-click those binaries from their Downloads folder. Windows users can get (malicious) DLLs silently downloaded to their Downloads folder just by browsing the web. Windows users don't need to set LD_PRELOAD to shoot themselves in the foot. The gun is always pointed down towards the foot by default on Windows.

[gopherbot]

CL https://golang.org/cl/21140 mentions this issue.

[mattn]

FYI, the order of paths for searching dll(s)

https://msdn.microsoft.com/en-us/library/7d83bc18.aspx

• The directory where the executable module for the current process is located.
• The current directory.
• The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
• The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
• The directories listed in the PATH environment variable.

[alexbrainman]

Background:
https://textplain.wordpress.com/2015/12/18/dll-hijacking-just-wont-die/

I read the article, and I don't see what the problem is. I went to the page pointed by the article which is suppose to automatically download malicious DLL, but my Chrome actually refused to download the DLL. Chrome told me that DLL looks suspicious and I shouldn't be downloading it.

As to CL 21140, I think it breaks existing valid programs. Somehow CL assumes that syscall.LoadDLL is onle used to load "system" DLLs. But that is not true. It is quite common to put application specific DLLs into application directory - directory where executable is located. How do you propose we handle this scenario if CL 21140 is accepted?

If you think there is something for us to fix here, perhaps we could create new syscall.LoadSystemDLL (or similar) that does what you want, and change all standard packages to use syscall.LoadSystemDLL.

Alex

[bradfitz]

but my Chrome actually refused to download the DLL. Chrome told me that DLL looks suspicious and I shouldn't be downloading it.

Chrome was updated according to the comments. The post also mentions the Edge browser (the default Microsoft browser) and comments suggest it hasn't been updated. I haven't tried.

As to CL 21140, I think it breaks existing valid programs.

https://golang.org/doc/go1compat says "A security issue in the specification or implementation may come to light whose resolution requires breaking compatibility. We reserve the right to address such security issues."

I believe calling syscall.LoadDLL(".\\foo.dll") is unchanged in behavior, if people really need to use the standard library to load DLLs out of the current directory.

If you think there is something for us to fix here, perhaps we could create new syscall.LoadSystemDLL (or similar) that does what you want, and change all standard packages to use syscall.LoadSystemDLL.

The proposal is to add that not to the standard library, but to x/sys. (See the original comment at the top of this bug).

[alexbrainman]

I believe calling syscall.LoadDLL(".\foo.dll") is unchanged in behavior, if people really need to use the standard library to load DLLs out of the current directory.

Current directory yes, but that is not what I was talking about. Some apps store DLLs in the directory where EXE is located. How do you propose people load these DLLs?

Alex

[bradfitz]

Current directory yes, but that is not what I was talking about. Some apps store DLLs in the directory where EXE is located. How do you propose people load these DLLs?

See the top comment in this bug: "2) Add a LoadLibraryEx to x/sys/win so that users can still get at the old behavior if they want it (by appropriate passing of flags)."

(A flags of 0 would mean the current behavior)

[alexbrainman]

Here is one of many programs I use on my PC.

C:\Program Files (x86)\Git\bin>objdump -p git.exe | grep Load
LoaderFlags             00000000
Entry a 00000000 00000000 Load Configuration Directory
        19cc7c    524  LoadLibraryA     7dd7499f

C:\Program Files (x86)\Git\bin>dir *.dll
 Volume in drive C has no label.
 Volume Serial Number is F0C8-6DFE

 Directory of C:\Program Files (x86)\Git\bin

07/12/2014  06:01 PM         1,154,665 libapr-0-0.dll
07/12/2014  06:01 PM           992,438 libaprutil-0-0.dll
07/12/2014  06:01 PM         1,724,229 libcrypto.dll
07/12/2014  06:01 PM           360,448 libcurl.dll
07/12/2014  06:01 PM           958,945 libexpat-0.dll
07/12/2014  06:01 PM           443,550 libgsasl-7.dll
07/12/2014  06:01 PM         1,241,889 libiconv-2.dll
07/12/2014  06:01 PM           293,380 libintl-8.dll
07/12/2014  06:01 PM         2,076,008 libneon-25.dll
07/12/2014  06:01 PM         4,884,531 libpoppler-7.dll
07/12/2014  06:01 PM           391,048 libssl.dll
07/12/2014  06:01 PM         1,218,359 libsvn_client-1-0.dll
07/12/2014  06:01 PM           851,272 libsvn_delta-1-0.dll
07/12/2014  06:01 PM           798,881 libsvn_diff-1-0.dll
07/12/2014  06:01 PM           792,459 libsvn_fs-1-0.dll
07/12/2014  06:01 PM         1,028,321 libsvn_fs_fs-1-0.dll
07/12/2014  06:01 PM           759,216 libsvn_ra-1-0.dll
07/12/2014  06:01 PM         1,017,784 libsvn_ra_dav-1-0.dll
07/12/2014  06:01 PM           800,669 libsvn_ra_local-1-0.dll
07/12/2014  06:01 PM           930,046 libsvn_ra_svn-1-0.dll
07/12/2014  06:01 PM         1,055,893 libsvn_repos-1-0.dll
07/12/2014  06:01 PM         1,248,729 libsvn_subr-1-0.dll
07/12/2014  06:01 PM           864,473 libsvn_swig_perl-1-0.dll
07/12/2014  06:01 PM         1,253,965 libsvn_wc-1-0.dll
07/12/2014  06:01 PM           812,063 libW11.dll
07/12/2014  06:01 PM           194,947 libz.dll
07/12/2014  06:01 PM           777,544 msys-1.0.dll
07/12/2014  06:01 PM         1,282,560 msys-crypto-1.0.0.dll
07/12/2014  06:01 PM            19,968 msys-minires.dll
07/12/2014  06:01 PM           939,520 msys-perl5_8.dll
07/12/2014  06:01 PM            82,852 msys-regex-1.dll
07/12/2014  06:01 PM           328,192 msys-ssl-1.0.0.dll
07/12/2014  06:01 PM            91,792 msys-z.dll
07/12/2014  06:01 PM            52,064 msysltdl-3.dll
07/12/2014  06:01 PM            65,124 pthreadGC2.dll
07/12/2014  06:01 PM         1,152,701 tcl85.dll
07/12/2014  06:01 PM            30,023 tclpip85.dll
07/12/2014  06:01 PM         1,410,875 tk85.dll
              38 File(s)     34,381,423 bytes
               0 Dir(s)  94,420,832,256 bytes free

C:\Program Files (x86)\Git\bin>

Just to demonstrate that behaviour you're about to break is actually used by some products.

See the top comment in this bug: "2) Add a LoadLibraryEx to x/sys/win so that users can still get at the old behavior if they want it (by appropriate passing of flags)."

(A flags of 0 would mean the current behavior)

But that will still break my existing code. I don't personally have problem like described in https://textplain.wordpress.com/2015/12/18/dll-hijacking-just-wont-die/. Why should I suffer? Why cannot we do what I suggested above? What is the downside?

Alex

[minux]

I agree with alex, loading DLL from program installation directory is pretty common. If we really want to anything here, we can make the runtime and syscall package only use LOAD_LIBRARY_SEARCH_SYSTEM32 to load known system DLLs (ntdll, kernel32, user32, advapi etc.) We should not change the behavior of exported syscall functions. I don't think this security problem is enough to invoke the security bug clause in the Go 1 guarantee.