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.

[bradfitz]

I propose we add the new x/sys/windows.LoadLibraryEx function and proactively fix all known public code on Github to use the new x/sys function instead of syscall.LoadLibrary.

@minux, @alexbrainman, I consider both of you advanced users who would use syscall.LoadDLL, but I don't suspect there is much total code out there that would be affected.

[alexbrainman]

I propose we add the new x/sys/windows.LoadLibraryEx function

I don't think this will work for what your broke. Since you changed syscall.LoadDLL (in CL 21140), you would have to provide similar alternative. In syscall package too. Otherwise people would have to change too much code if they need to import x/sys/windows as well as syscall, and things can get messy. I don't use x/sys/windows myself, it is difficult for me to see what can go wrong here.

Alex

[mattn]

I checked loading dll from go.

#include <windows.h>

BOOL WINAPI DllMain(HINSTANCE hinstDll, DWORD dwReason, LPVOID lpReserved) {
    switch (dwReason) {
    case DLL_PROCESS_ATTACH:
        MessageBox(0, "Evil", "Wow!", MB_OK);
        break;
    case DLL_THREAD_ATTACH:
        break;
    case DLL_THREAD_DETACH:
        break;
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

build kernel32.dll

gcc -static -o kernel32.dll -shared kernel32.c

loader written in go

package main

import (
    "os"
    "syscall"
)

func main() {
    kernel32 := syscall.NewLazyDLL(os.Args[1])
    procGetCurrentThreadId := kernel32.NewProc("GetCurrentThreadId")
    procGetCurrentThreadId.Call()
}

then, pass argument pointed path to kernel32.dll like below

go run main.go [Argument]

Argument	Result
kernel32	OK
kernel32.dll	OK
./kernel32	Evail
./kernel32.dll	Evail

problems seem to not occur unless the program point to kernel32.dll relatively or point to kernel32.dll directly.

[taruti]

@mattn, That is because Windows registry has a list of dlls that will always be loaded from a system directory first. That covers some, but not all of the dlls that are used by Go stdlib.

I see at least three possible solutions:
A) Fix LoadDll and make applications deal with it.
B) Have a syscall.LoadDllSafe and change stdlib to use that (or even internal/syscall/windows.LoadDllSafe) and change nothing for custom user code.
C) Do nothing

[alexbrainman]

I see at least three possible solutions:
A) Fix LoadDll and make applications deal with it.
B) Have a syscall.LoadDllSafe and change stdlib to use that (or even internal/syscall/windows.LoadDllSafe) and change nothing for custom user code.
C) Do nothing

I think your solution A must include some plan for Go users on how to fix their breakage. I am worried they will just start copying runtime code. And some will make mistakes along the way. And maybe even copying code will not work for some reason or other.

As to my preference, I like your B approach (we can do better than syscall.LoadDllSafe name). I can be arm twisted into doing C :-), but B is not much harder, and it will make all standard library code safe for this current issue. And it won't break any user code. We can mention new syscall.LoadDllSafe function in release notes, and let our users decide if it is important for their projects. syscall.LoadDllSafe could be a simple replacement for syscall.LoadDLL, so it should be a trivial change for everyone who decides to follow our advice.

Alex

[bradfitz]

I've updated https://go-review.googlesource.com/21140 to hopefully be non-controversial. It now makes sure that all DLLs loaded by Go itself are safe, but does nothing to protect users using syscall.LoadLibrary or syscall.NewLazyDLL themselves.

[taruti]

That seems like a good way forward.

Would exposing that to third party code via the sys-repo be fine? I can submit that, if it is ok.

[bradfitz]

To write a proper test for https://golang.org/cl/21140, I would like a DLL which, when loaded, does something we can check easily in a test. Maybe it can write to stdout, or crash the process with a certain error code.

@mattn, could you provide such a minimal DLL & source code? From #14959 (comment) it looks like you know how to make them easily. I only have gomote+trybots for Windows testing. I don't have a Windows development machine at the moment. I found some information online about how to generate Windows DLLs from Linux which I can try otherwise.

One DLL is probably fine, but maybe a 32-bit one and a 64-bit one would be better?

[bradfitz]

@taruti, adding x/sys/windows API for all the possibilities is not controversial. It's only new API in the standard library that we want to avoid. If you'd like to do the x/sys change(s) already, feel free. I'd be happy to review.

[alexbrainman]

To write a proper test for https://golang.org/cl/21140, I would like a DLL which, when loaded, does something we can check easily in a test.

I think we already have TestStdcallAndCDeclCallbacks that does what you want. I wonder why the test didn't fail with your CL 21140 changes are applied.

Alex

[bradfitz]

Oh, nice.

Maybe the builders don't have gcc?

func TestStdcallAndCDeclCallbacks(t *testing.T) {
        if _, err := exec.LookPath("gcc"); err != nil {
            t.Skip("skipping test: gcc is missing")
        }

Will investigate.

[alexbrainman]

Maybe the builders don't have gcc?

They surely do. misc/cgo tests wouldn't run without gcc.

Alex

[bradfitz]

@alexbrainman, TestStdcallAndCDeclCallbacks didn't fail because it's using an absolute path to the DLL, which is unaffected by https://golang.org/cl/21140:

$ gomote run user-bradfitz-windows-amd64-gce-0 go/bin/go test -v -run=TestStdcallAndCDeclCallbacks runtime
=== RUN   TestStdcallAndCDeclCallbacks
--- PASS: TestStdcallAndCDeclCallbacks (0.35s)
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\test.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
        syscall_windows_test.go:400: MustLoading DLL "C:\\Users\\WINGOP~1\\AppData\\Local\\Temp\\TestCDeclCallback016371391\\testO2.dll" ...
PASS
ok      runtime 0.392s

I'll write a new similar test using a base filename ("test_bad.dll") and verify it doesn't search for it in the current directory once "test_bad.dll" is registered as requiring system32.

[bradfitz]

x/sys counterpart for discussion: https://go-review.googlesource.com/21388

[gopherbot]

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

[blinksmith]

@bradfitz Go should not paranoid when loading DLLs.
its not Go developer problem, its Window's user problem.

Search Path behavior should remaining same https://msdn.microsoft.com/en-us/library/7d83bc18.aspx

its not Go's fault when loaded dll is fake, it is user fault executing unknown program in their environment.

I am Windows user, I consider this as a feature we can try and load newer dlls without the need to replace original system32 dlls. so udating software is much easier.

• every downloaded file must be unblocked.
• every Windows user must have antivirus.

Win User know it, and they already have their own guards.

[bradfitz]

@blinksmith, we're only altering the DLL search path for DLLs used by Go. syscall.LoadDLL will remain unchanged for other DLLs. It is a non-goal for people to be able to manually update their system DLLs in non-standard locations and have Go respect them from those paths. You should use the normal Windows system update mechanism.

x/sys/windows is getting a new LoadLibraryEx in https://golang.org/cl/21388 for having more control.

[gopherbot]

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

[adg]

What's left to fix this?

[mattn]

Please wait bradfitz. Now he's trying to buy Windows XP at Best Buy maybe.

[bradfitz]

Nothing's left, other than to ship Go1.6.1. @alexbrainman confirmed all.bat passes on his Windows XP machine, and the new test fails (skips) as expected on XP.

[gopherbot]

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

[gopherbot]

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

[gopherbot]

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

[gopherbot]

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

[gopherbot]

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