Bug 13334 – [infoleak] DMD always places module paths in data segment

Consider the following minimalistic Win32 executable program: /////////////// winmain.d ////////////// import win32.windows; extern(Windows) void ExitProcess(DWORD); void start() { ExitProcess(0); } pragma(startaddress, start); pragma(lib, "kernel32"); //////////////////////////////////////// If the program is compiled, then the EXE passed through the standard `strings` utility, the output is as follows: ExitProcess KERNEL32.dll C:\Soft\dmd2d\windows\bin\..\..\import\druntime\object.di C:\Soft\dmd2d\windows\bin\..\..\import\win32\w32api.d C:\Soft\dmd2d\windows\bin\..\..\import\win32\windef.d C:\Soft\dmd2d\windows\bin\..\..\import\win32\basetsd.d C:\Soft\dmd2d\windows\bin\..\..\import\win32\winbase.d C:\Soft\dmd2d\windows\bin\..\..\import\win32\winuser.d C:\Soft\dmd2d\windows\bin\..\..\import\win32\mmsystem.d C:\Soft\dmd2d\windows\bin\..\..\import\win32\winsock2.d C:\Soft\dmd2d\windows\bin\..\..\import\win32\ws2tcpip.d The executable contains an unused (unreferenced) string containing the path of each module of the program. These strings are present even if the program is compiled with -release -betterC! These strings seem to be generated by the Module::genhelpers function in mars.c. This function generates functions to handle range check errors, assertion failures, and unittest failures. Now, the functions themselves are generated each in a separate section, and as they are not used by the program, they are ultimately stripped by the linker. However, the strings are not stripped, because they are emitted directly to the object file's data segment. I can see two solutions: 1) Do not generate these helper functions or strings when -betterC is specified. 2) Emit the strings to a separate segment, so that they can be stripped away by the linker as well.

Correction. There are two separate issues here: 1. DMD leaks information about the source code in a way that can't be turned off with compiler switches. 2. DMD emits information that is useless to certain programs. The first solution above only applies to the second problem. The first problem touches a much bigger subject with several approaches, e.g. a set of compiler switches to strip or obfuscate file names, class names, __FILE__/__LINE__ expansions throughout Phobos, etc.

(In reply to Vladimir Panteleev from comment #0) > 1) Do not generate these helper functions or strings when -betterC is > specified. This is now in: https://github.com/D-Programming-Language/dmd/pull/3882

Modernizing the test case to: import core.sys.windows.windows; extern(Windows) void ExitProcess(DWORD); void start() { ExitProcess(0); } pragma(startaddress, start); pragma(lib, "kernel32"); and compiling with: dmd -betterC test2 produces: 02/15/2018 10:38 PM 2,076 test2.exe and strings produces: C:\cbx\bug>strings test2.exe MZ` Requires Win32 $ .idata @_TEXT `.reloc @.debug ExitProcess KERNEL32.dll and obj2asm produces: C:\cbx\bug>obj2asm test2 _TEXT segment dword use32 public 'CODE' ;size is 0 _TEXT ends _DATA segment para use32 public 'DATA' ;size is 0 _DATA ends CONST segment para use32 public 'CONST' ;size is 0 CONST ends _BSS segment para use32 public 'BSS' ;size is 0 _BSS ends FLAT group extrn _D5test25startFZv includelib kernel32.lib extrn _ExitProcess@4 _D5test25startFZv COMDAT flags=x0 attr=x0 align=x0 _TEXT segment assume CS:_TEXT _TEXT ends _DATA segment _DATA ends CONST segment CONST ends _BSS segment _BSS ends _D5test25startFZv comdat assume CS:_D5test25startFZv L0: push 0 call near ptr _ExitProcess@4 ret _D5test25startFZv ends end which looks satisfactory.