syscall: modest improvement to Windows DLL-preloading protection

[jazzy-crane]

What version of Go are you using (go version)?

go version go1.11 windows/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Alex\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\MyGo
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-LC:/winsdklibs64
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Alex\AppData\Local\Temp\go-build831000242=/tmp/go-build -gno-record-gcc-switches

What did you do?

I'm looking into protecting my project from DLL-preloading attacks. Many of the vendored libraries I use use the syscall/windows LoadDLL call rather than the safer x/sys/windows LazySystemDLL method.

I note that syscall/windows LoadDLL has some limited protection for a preset list of system DLLs via sysdll.IsSystemDLL . However this is case-sensitive, when LoadLibrary etc. are case insensitive. Therefore:

windows.LoadDLL("advapi32.dll") is protected but windows.LoadDLL("Advapi32.dll") is not

A simple tweak would be to string.ToUpper in sysdll.Add and string.ToUpper in the check in LoadDLL

[as]

Is there any advantage to using ToUpper instead of the more-ubiqutous output of ToLower?

[jazzy-crane]

No advantage, just looking for a case insensitive comparison. I think strings.EqualFold does the same thing?