ASLR seems not to be working as it should on Windows

laanwj commented at 2:34 pm on June 23, 2016: member

Had an interesting exchange on twitter today re: Windows security: https://twitter.com/CopperheadOS/status/745962747117076480

Seems that dynamicbase is not enough and:

Something called highentropyva is necessary for (secure) ASLR on 64-bit.
Standard link/build flags of mingw-w64 prevent ASLR from actually being used, due to lack of an executable relocation table.
Rust worked around some mingw-w64 ASLR bugs here https://github.com/rust-lang/rust/commit/96f5eba4f5603c612464d6b1e961677e9d7084d3 and https://github.com/rust-lang/rust/issues/17684 (ASLR on Windows breaks thread-local variables)

At the least it should be verified using a debugger or something like sysinternals that the base address changes every invocation.

laanwj added the label Windows on Jun 23, 2016

laanwj commented at 3:15 pm on June 23, 2016: member

Apparently to enable high-entropy ASLR the image-base also needs to be set above 4GB.

0                 LDFLAGSCLI="$LDFLAGSCLI -Wl,--image-base,0x140000000"
1                 SOFLAGS="$SOFLAGS -Wl,--image-base,0x180000000"

laanwj commented at 4:36 pm on June 23, 2016: member

I’ve checked using Process Explorer and VMMap on Windows 10, and it looks like the windows executable is always loaded at the same offset:

0xb00000 for the 32-bit version
0xbf0000 for the 64-bit version

This is not the base address specified in the .exe (0x400000), but it doesn’t seem randomized either.

retep998 commented at 11:58 pm on June 26, 2016: none

You can easily check whether an executable has ASLR enabled by doing dumpbin /headers foo.exe where dumpbin is a program that comes with MSVC. Ideally you should see something like the following in the output:

0            8160 DLL characteristics
1                   High Entropy Virtual Addresses
2                   Dynamic base
3                   NX compatible
4                   Terminal Server Aware

If only you could use msvc to compile the code, then you’d have all that by default.

laanwj commented at 10:03 am on June 27, 2016: member

You can easily check whether an executable has ASLR enabled by doing dumpbin /headers foo.exe where dumpbin is a program that comes with MSVC. Ideally you should see something like the following in the output:

That just checks the header bits (the same as our security check script already does using objdump). It does not actually check whether the address space is randomized in practice, which I did by checking the memory maps at runtime.

If only you could use msvc to compile the code, then you’d have all that by default.

You can use MSVC to compile the code. There’s nothing about the code that should be gcc+clang specific (and if it is, that should be fixed).

However that doesn’t help for releases as they need to be able to be built from source deterministically (with gitian). Using a closed source, not freely redistributable compiler is out of the question for that.

laanwj renamed this:
~~Need to check ASLR is actually happening on Windows~~
ASLR seems not to be working as it should on Windows
on Jul 20, 2016

sipsorcery commented at 1:51 am on October 2, 2017: member

I can confirm that on Windows x64 a bitcoin-qt.exe process built from source on WSL is benefiting from ASLR.

Method used to confirm (note that two separate tools are used VMMap and WinDbg to provide additional confidence):

Start bitcoin-qt.exe,
Open VMMap and select the bitcoin-qt process,
Click on the Image Type and note virtual addresses of certain modules, e.g. 0x190000 f:\temp\bitcoin-qt.exe 0x7FFA06190000 c:\windows\system32\kernel32.dll 0x7FFA038F0000 c:\windows\system32\ws2_32.dll
Capture a memory dump of the process using Task Manager->Right Click Process->Create Dump File,
Open dump file in windbg,
Use lm to list loaded modules and confirm addresses are the same as VMMap, 0000000000190000 0000000001fd4000 bitcoin_qt (deferred)
00007ffa06190000 00007ffa0623e000 kernel32 (deferred)
00007ffa038f0000 00007ffa0395c000 ws2_32 (deferred)

Now reboot Windows, since ASLR will only reset the module addresses for a process after each OS restart, and repeat the above steps:

VMMap results: 0x820000 f:\temp\bitcoin-qt.exe 0x7FF9D1B00000 c:\windows\system32\kernel32.dll 0x7FF9D18D0000 c:\windows\system32\ws2_32.dll

WinDbg results: 0000000000820000 0000000002664000 bitcoin_qt (deferred) 00007ff9d1b00000 00007ff9d1bae000 kernel32 (deferred)
00007ff9d18d0000 00007ff9d193c000 ws2_32 (deferred)

chouquette commented at 1:16 pm on July 25, 2018: none

Hi, For what it’s worth, I submitted a patch that fixes the issue on binutils/ld side: https://sourceware.org/bugzilla/show_bug.cgi?id=19011

(Should you want a patch that applies cleanly over binutils 2.31.1 tarball, there’s also one here: https://code.videolan.org/videolan/docker-images/blob/master/vlc-debian-win64/patches/binutils.patch

Hopefully that will be of use :)

edit: Yeah so it makes readpe very happy as far as aslr is concerned, but windows can’t launch the resulting binary, so… oops.

laanwj commented at 1:57 pm on July 30, 2018: member

@chouquette Thanks!

I think this can be closed, now that we’re building on bionic, HIGH_ENTROPY_VA is enabled. See #13764.

laanwj closed this on Jul 30, 2018

chouquette commented at 2:04 pm on July 30, 2018: none

I doubt it is fixed, the patch I proposed is breaking the binaries, and AFAIK it hasn’t been fixed upstream in another way.

Unless your executable has some explicitly exported symbols, the relocation table will be missing, and this will cause the executable to be flagged with IMAGE_FILE_RELOCS_STRIPPED, so Windows won’t enable ASLR.

laanwj reopened this on Jul 30, 2018

fanquake commented at 12:10 pm on February 3, 2020: member

There’s been some upstream activity here. binutils have implemented a --enable-reloc-section, which would be turned on along side --dynamicbase or --high-entropy-va.

fanquake commented at 12:02 pm on May 19, 2020: member

Now that #18629 and #18702 have been merged. I think we can close this as “working for now”.

fanquake closed this on May 19, 2020

DrahtBot locked this on Feb 15, 2022

ASLR seems not to be working as it should on Windows #8248