exception_handler.cc: dbghelp_module_ and rpcrt4_module_ are subject to path manipulations

[GoogleCodeExporter]

dbghelp_module_ = LoadLibrary(L"dbghelp.dll");
...
rpcrt4_module_ = LoadLibrary(L"rpcrt4.dll");

I've heard it called Binary Planting and DLL Hijacking.

Original issue reported on code.google.com by [email protected] on 27 Sep 2012 at 6:12

[GoogleCodeExporter]

I wonder if we can't just link directly to these libraries nowadays, since 
we've pretty explicitly dropped Windows 2000 support.

Original comment by ted.mielczarek on 27 Sep 2012 at 11:37

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Linking directly would probably have three benefits: (1) remove the direct path 
manipulation problems; (2) ensure an expected code base is being used (lots of 
down-level versions of ImageHlp.dll, DbgHelp.dll, etc are floating around in 
the %SYSTEM32% directory); and (3) no need to redistribute a DLL (many FOSS 
folks find it objectionable).

If any statically linked libraries have additional dependencies, then they 
might suffer path manipulations too.

Perhaps it would be best to (1) use static linking; and (2) call 
SetDllDirectory for any lazy loads via LoadLibrary. We really need a manifest 
setting for SetDllDirectory so that we can harden the process early, but its a 
gap in the platform.

Also see "Dynamic-Link Library Security," 
http://msdn.microsoft.com/en-us/library/windows/desktop/ff919712(v=vs.85).aspx.

Original comment by [email protected] on 27 Sep 2012 at 8:08

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I didn't mean statically link, I'm pretty sure that's not an option for 
DbgHelp. I just meant dynamically link directly to the library instead of using 
LoadLibrary.

Original comment by ted.mielczarek on 28 Sep 2012 at 12:24

• Added labels: ****
• Removed labels: ****