Opened 4 years ago

Last modified 40 hours ago

#12968 needs_revision enhancement

Specify HEASLR (High Entropy Address Space Layout Randomization) in MinGW-w64

Reported by: mikeperry Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-security, tbb-rbm, TorBrowserTeam201811, boklm201811
Cc: tom@…, gk, boklm, sukhbir Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Mozilla patched mingw-w64 to allow the specification of "high-entropy" ASLR, which is an extra hardened ASLR option on Windows. Not sure if this flag only applies to 64bit builds. I think it might.

Here's their ticket:
https://github.com/rust-lang/rust/issues/16593
and the patch:
https://sourceware.org/ml/binutils/2014-08/msg00167.html
and it's approval by the Binutils team:
https://sourceware.org/ml/binutils/2014-08/msg00177.html

Child Tickets

TicketTypeStatusOwnerSummary
#16472taskclosedtbb-teamUpgrade Binutils to 2.25+ for Tor Browser builds

Change History (41)

comment:1 Changed 4 years ago by tom

Cc: tom@… added

comment:2 Changed 4 years ago by gk

Cc: gk added

comment:3 Changed 4 years ago by mikeperry

Keywords: tbb-security added
Parent ID: #10065

comment:4 Changed 3 years ago by gk

Keywords: tbb-hardening added

comment:5 Changed 3 years ago by gk

Keywords: tbb-hardened added; tbb-hardening removed

comment:7 Changed 2 years ago by bugzilla

Component: Applications/Tor bundles/installationApplications/Tor Browser
Keywords: ff52-esr added; tbb-hardened removed
Owner: changed from erinn to tbb-team
Status: newassigned
Summary: Specify high-entropy ASLR in MinGW-W64Specify HEASLR (High Entropy Address Space Layout Randomization) in MinGW-w64

It's not related to tbb-hardened at all.
Also don't forget to fulfil all its requirements, or its protection might be reduced.

comment:8 Changed 2 years ago by gk

Keywords: tbb-hardened added; ff52-esr removed

comment:9 Changed 15 months ago by gk

Keywords: tbb-rbm added; tbb-hardened removed

comment:10 Changed 14 months ago by gk

Keywords: ff59-esr added

Assuming we have 64bit builds for Windows ready when switching to esr59 set the proper keyword to put it on that radar.

comment:11 Changed 10 months ago by gk

Keywords: ff60-esr added; ff59-esr removed

Firefox 60 is the new ESR.

comment:12 Changed 8 months ago by gk

Cc: boklm added
Keywords: TorBrowserTeam201804 boklm201804 added
Priority: MediumHigh

comment:13 Changed 7 months ago by boklm

Keywords: boklm201805 added; boklm201804 removed

boklm201804 -> boklm201805

comment:14 Changed 7 months ago by gk

Keywords: TorBrowserTeam201805 added; TorBrowserTeam201804 removed

Move our roadmap tickets to May.

comment:15 Changed 6 months ago by gk

Parent ID: #24631

comment:16 Changed 6 months ago by boklm

Keywords: TorBrowserTeam201805R added; TorBrowserTeam201805 removed
Status: assignedneeds_review

There is a patch for review in branch bug_12968, adding the -Wl,--high-entropy-va flag in the Windows x86_64 build:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_12968&id=e61271539c985974e95e486b8736dd3a7049516c

comment:17 in reply to:  16 ; Changed 6 months ago by gk

Replying to boklm:

There is a patch for review in branch bug_12968, adding the -Wl,--high-entropy-va flag in the Windows x86_64 build:

That might not be enough, see the ffmpeg link in comment:6. I guess we need at least -Wl,--image-base,0x140000000 additionally?

Is there some way to check that we are good by inspecting the binary?

comment:18 in reply to:  17 Changed 6 months ago by gk

Replying to gk:

Replying to boklm:

There is a patch for review in branch bug_12968, adding the -Wl,--high-entropy-va flag in the Windows x86_64 build:

That might not be enough, see the ffmpeg link in comment:6. I guess we need at least -Wl,--image-base,0x140000000 additionally?

Oh, and if that breaks compilation we might need to backport https://github.com/gcc-mirror/gcc/commit/f47fc7ef7f52cd095e636d4f93cca052427f3f0a.patch

comment:19 Changed 6 months ago by gk

Keywords: TorBrowserTeam201806R added; TorBrowserTeam201805R removed

Moving review tickets to June.

comment:20 Changed 6 months ago by gk

Keywords: TorBrowserTeam201806 added; TorBrowserTeam201806R removed
Status: needs_reviewneeds_revision

I am inclined to assume this needs actually revision.

comment:21 Changed 6 months ago by boklm

Keywords: boklm201806 added; boklm201805 removed

boklm201805 -> boklm201806

comment:22 Changed 5 months ago by boklm

I tried adding -Wl,--image-base,0x140000000 to the flags. However the firefox build fails with errors such as:

Executing: /var/tmp/dist/mingw-w64/helpers/x86_64-w64-mingw32-g++ -std=gnu++11 -mwindows -shared -Wl,--out-implib -Wl,liblgpllibs.a -o lgpllibs.dll module.res -specs=/va
r/tmp/dist/mingw-w64/msvcr100.spec -Wl,--build-id -static ../../../../config/external/lgpllibs/lgpllibs.def /var/tmp/build/firefox-f8f42fea2af3/obj-mingw/config/external
/lgpllibs/tmpcCxggc.list ../../../mozglue/build/libmozglue.a -luuid -lgdi32 -lwinmm -lwsock32 -luserenv -lsecur32
/var/tmp/build/firefox-f8f42fea2af3/obj-mingw/config/external/lgpllibs/tmpcCxggc.list:
    INPUT("../../../media/libav/avfft.o")
    INPUT("../../../media/libav/fft_fixed.o")
    INPUT("../../../media/libav/dict.o")
    INPUT("../../../media/libav/opt.o")
    INPUT("../../../media/libav/Unified_c_media_libav0.o")
    INPUT("../../../media/libav/Unified_c_media_libav1.o")
    INPUT("../../../media/libav/fft.o")
    INPUT("../../../media/libav/cpuid.o")
    INPUT("../../../media/libav/libavutil/x86/cpu.o")
    INPUT("../../../media/libsoundtouch/src/sse_optimized.o")
    INPUT("../../../media/libsoundtouch/src/Unified_cpp_libsoundtouch_src0.o")
    INPUT("../../../memory/fallible/fallible.o")

../../../media/libav/fft.o:/var/tmp/build/firefox-f8f42fea2af3/media/libav/libavcodec/x86/fft.asm:(.debug_info+0x6): relocation truncated to fit: R_X86_64_32 against `.d
ebug_abbrev'
../../../media/libav/fft.o:/var/tmp/build/firefox-f8f42fea2af3/media/libav/libavcodec/x86/fft.asm:(.debug_info+0xc): relocation truncated to fit: R_X86_64_32 against `.d
ebug_line'
../../../media/libav/fft.o:/var/tmp/build/firefox-f8f42fea2af3/media/libav/libavcodec/x86/fft.asm:(.debug_aranges+0x6): relocation truncated to fit: R_X86_64_32 against 
`.debug_info'
../../../media/libav/cpuid.o:/var/tmp/build/firefox-f8f42fea2af3/media/libav/libavutil/x86/cpuid.asm:(.debug_info+0x6): relocation truncated to fit: R_X86_64_32 against 
`.debug_abbrev'
../../../media/libav/cpuid.o:/var/tmp/build/firefox-f8f42fea2af3/media/libav/libavutil/x86/cpuid.asm:(.debug_info+0xc): relocation truncated to fit: R_X86_64_32 against 
`.debug_line'
../../../media/libav/cpuid.o:/var/tmp/build/firefox-f8f42fea2af3/media/libav/libavutil/x86/cpuid.asm:(.debug_aranges+0x6): relocation truncated to fit: R_X86_64_32 again
st `.debug_info'
collect2: error: ld returned 1 exit status
/var/tmp/build/firefox-f8f42fea2af3/config/rules.mk:800: recipe for target 'lgpllibs.dll' failed
make[5]: *** [lgpllibs.dll] Error 1

It seems the part of the build which fails is not the same every time, but with a similar error message. Probably because of the make -j8.

I tried the gcc patch adding #define _GLIBCXX_USE_WEAK_REF 0, however it does not solve the issue.

comment:23 Changed 5 months ago by sukhbir

Cc: sukhbir added

comment:24 Changed 5 months ago by sukhbir

As an update, I have been trying to build and find a solution for this with boklm's changes above, and it fails with a similar error to the one boklm had.

As per the ffmpeg commit, they apply --image-base,0x140000000 to get a higher entropy for HEASLR. Since that is not working for us, how about we just go with -Wl,--high-entropy-va for now till we find a solution?

There are other "solutions", that use -Wl,--image-base,0x10000000 instead (and rebase the address later?) and that seems to work, for the build and for the final EXE as well. However, this comes with its own set of caveats: https://www.cygwin.com/ml/cygwin-apps/2013-05/msg00134.html is the thread that talks about this.

For inspecting the binary, as per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836365, I inspected both with -Wl,--image-base,0x10000000 and -Wl,--high-entropy-va:

$ readpe firefox.exe | grep DLL
DLL characteristics:             0x160

Indicates that HEASLR was applied in both cases, so if anything, we lose out on the extra entropy?

comment:25 in reply to:  24 ; Changed 5 months ago by gk

Replying to sukhbir:

As an update, I have been trying to build and find a solution for this with boklm's changes above, and it fails with a similar error to the one boklm had.

As per the ffmpeg commit, they apply --image-base,0x140000000 to get a higher entropy for HEASLR. Since that is not working for us, how about we just go with -Wl,--high-entropy-va for now till we find a solution?

What prevents us from finding that out now? Did you try to use -mcmodel=medium or -mcmodel=large? Why is ffpmeg not hitting the dwarf related problem in the first place? I.e. why is the linker not complaining for them?

comment:26 in reply to:  25 ; Changed 5 months ago by sukhbir

Replying to gk:

Replying to sukhbir:

As an update, I have been trying to build and find a solution for this with boklm's changes above, and it fails with a similar error to the one boklm had.

As per the ffmpeg commit, they apply --image-base,0x140000000 to get a higher entropy for HEASLR. Since that is not working for us, how about we just go with -Wl,--high-entropy-va for now till we find a solution?

What prevents us from finding that out now? Did you try to use -mcmodel=medium or -mcmodel=large? Why is ffpmeg not hitting the dwarf related problem in the first place? I.e. why is the linker not complaining for them?

I tried (today) with -mcmodel=medium, -mcmodel=large (both with boklm's changes above and the GCC patch) and we have a similar if not the same error. As to why it works for ffmpeg, it seems they are using the same flags so I am not sure; I am going to compare the toolchain and see if there is a difference there.

comment:27 Changed 5 months ago by sukhbir

(EDIT: When I said that they are using the same flags, they are building with --image-base,0x140000000 and that works for them. It seemed like I said they are building with mcmodel but that's not what I meant.)

comment:28 Changed 5 months ago by boklm

Keywords: boklm201807 added; boklm201806 removed

boklm201806 -> boklm201807

comment:29 Changed 5 months ago by gk

Priority: HighVery High

comment:30 Changed 5 months ago by gk

Keywords: TorBrowserTeam201807 added; TorBrowserTeam201806 removed

Moving first batch of tickets to July 2018

comment:31 Changed 4 months ago by gk

Keywords: TorBrowserTeam201808 added; TorBrowserTeam201807 removed

Move our tickets to August.

comment:32 in reply to:  16 Changed 3 months ago by gk

Replying to boklm:

There is a patch for review in branch bug_12968, adding the -Wl,--high-entropy-va flag in the Windows x86_64 build:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_12968&id=e61271539c985974e95e486b8736dd3a7049516c

I cherry-picked that one to have it in the upcoming alpha (8.0a10) while we still try to solve the remaining issue with our proposed fix. (commit f7247cca852ce5f9cce092ca82cb92efbbba611d on master has boklm's patch)

comment:33 in reply to:  26 Changed 3 months ago by heaslr

Replying to gk:

Replying to boklm:

There is a patch for review in branch bug_12968, adding the -Wl,--high-entropy-va flag in the Windows x86_64 build:

Windows has protections from cheaters like you who set that bit in executables by linker or by notepad ;)

Replying to sukhbir:

I tried (today) with -mcmodel=medium, -mcmodel=large (both with boklm's changes above and the GCC patch) and we have a similar if not the same error.

Never try to change something which effect you don't know: we don't want executables >2 GiB, even for data. Also for you -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46125

As to why it works for ffmpeg, it seems they are using the same flags so I am not sure; I am going to compare the toolchain and see if there is a difference there.

https://sourceware.org/bugzilla/show_bug.cgi?id=15444
You were asked many times to stop using debug-grade gcc's crap in production code ;)

comment:34 Changed 3 months ago by gk

A comment from the blog about what we ship (https://blog.torproject.org/comment/276498#comment-276498):

You've only set the bit in executables, but it's possible to force heaslr flag (but not heaslr) on the app even without it. However, you should know it is opt-in only. So, no heaslr for now.
Also, you missed libssp-0.dll.

comment:35 Changed 3 months ago by gk

Parent ID: #24631

comment:36 Changed 3 months ago by gk

Keywords: ff60-esr removed

comment:37 Changed 3 months ago by boklm

Keywords: boklm201809 added; boklm201807 removed

boklm201807 -> boklm201809

comment:38 Changed 3 months ago by gk

Keywords: TorBrowserTeam201809 added; TorBrowserTeam201808 removed

Moving our tickets to September 2018

comment:39 Changed 7 weeks ago by gk

Keywords: TorBrowserTeam201810 added; TorBrowserTeam201809 removed

Moving tickets to October

comment:40 Changed 2 weeks ago by gk

Keywords: TorBrowserTeam201811 added; TorBrowserTeam201810 removed

Moving our tickets to November.

comment:41 Changed 40 hours ago by boklm

Keywords: boklm201811 added; boklm201809 removed

boklm201809 -> boklm201811

Note: See TracTickets for help on using tickets.