Bug 16887 - Timestamp bug with Windows bound import technology
Summary: Timestamp bug with Windows bound import technology
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.24
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-30 12:39 UTC by Linda Zhang
Modified: 2014-06-26 11:24 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
a simple case (1.48 KB, application/x-compress)
2014-04-30 12:39 UTC, Linda Zhang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Linda Zhang 2014-04-30 12:39:13 UTC
Created attachment 7569 [details]
a simple case

There is a timestamp bug in ld 2.24.

ld 2.24 introduced a new "feature" that sets timestamp flag in the Windows PE header to zero by default to make deterministic binaries. However, BindImage / BindImageEx of imagehlp library (bound import technology) relies on the timestamp flag in the PE header, and it's widely used in Windows system DLLs and VB6 compilation process. A reference of the bound import technology can be found at http://msdn.microsoft.com/en-us/magazine/cc301808.aspx. ld 2.24 sets the timestamp to zero by default, thus caused a serious bug.

For example, one exe was bound to a series of dlls built by ld 2.24, which sets timestamp field in the PE header to zero by default. One of the dlls has security issues and producer wants to update it with a new version, also built by ld 2.24, and of course the timestamp field is all the same. Then the exe crashes after patching the new dll.


Steps to reproduce this bug:
Here is a simple example in the attachment.

make -f dll1.mak	// make the dll
make -f exe.mak		// make the exe
bindimage exe.exe	// bind the exe to the dll
exe 1 2			// run the exe, everything is ok

make -f dll2.mak	// update the dll with patched version
exe 1 2			// the exe crashes

However, if using ld 2.23 to retry these steps, the exe won't crash at all.


Suggested solutions:
Insert timestamp *BY DEFAULT*, delete the option --insert-timestamp, and add the option --no-timestamp to make deterministic binaries to meet someone's needs.
Comment 1 Linda Zhang 2014-05-02 03:21:48 UTC
Also the strip command will accidently erase the timestamp field of EXE/DLLs.
Comment 2 Nick Clifton 2014-06-26 11:24:19 UTC
Patch applied.