time: DLL side-loading vulnerability on non-English Windows systems

[ozanh]

Summary

A DLL side-loading vulnerability affects all Windows builds of Go when running on non-English Windows. When the
standard library time package initializes the local time zone (time.initLocal), it can trigger Windows to call
RegLoadMUIStringW (via GetMUIStringValue) without specifying a search directory on the first call. As a result,
Windows may attempt to load tzres.dll from the application's current working directory before falling back to
System32. This creates a DLL side-loading risk on machines with non-English locales.

Why tzres.dll is loaded

• time.initLocal lazily initializes local time.Location data.
• If a time zone abbreviation is not found in Go's internal map on non-English systems, the runtime calls into Windows
  to retrieve a localized string (via GetMUIStringValue).
• The underlying Windows call (RegLoadMUIStringW) is invoked first without a directory parameter, which leads
  Windows to look for tzres.dll in the current working directory.
• Only on a subsequent attempt does Windows use the System32 directory, so the initial nil-directory call is the root
  cause of the observable attempt to load tzres.dll from the CWD.

Reproduction

1. Use a non-English Windows installation (e.g., I used Turkish Windows 10).
2. Run a minimal Go program that touches time.Local. For example, this one line triggers the behavior:

   println(time.Local.String())

3. Observe the behavior with Sysinternals Process Monitor.

Note about attempted mitigations (no effect)

The following Windows API calls, when invoked early, do not prevent the observed RegLoadMUIStringW behavior and
therefore do not stop tzres.dll being probed in the CWD:

• SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32)
• SetDllDirectoryW(L"")
• SetSearchPathMode(BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE | BASE_SEARCH_PATH_PERMANENT)

Workaround Used

As a temporary mitigation in our environment, we used Go's -overlay build feature to override the GetMUIStringValue
function. This allowed us to patch the behavior at build time and avoid the vulnerable DLL load sequence without
modifying upstream Go sources.

Note: The Go Security team has requested that this report be tracked as a public issue.

[gabyhelp]

Related Code Changes

• time: handle localized time zone names

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[odeke-em]

Thank you for this report @ozanh!

I wonder if this should have perhaps been classified as a private security report? Kindly cc-ing @rolandshoemaker @neild, then some Windows experts @qmuntal @alexbrainman @jakebailey

[ozanh]

Hi @odeke-em , creating a public issue was a decision of @rolandshoemaker

[qmuntal]

Thanks for reporting. We get the time zones from a Windows registry key that is owned by Windows (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones), so it is fine for me to unconditionally try to load localized zone names from the Windows System library.