Improve Hardening for TBB3.0
In the rush to get the Windows builds working correctly, we may have disabled hardening options that we shouldn't have. I experienced crashes on Windows 7 with a few options as well. We should get to the bottom of those issues and if they persist, we should ping the mingw-w64 people and find out what the issue is.
Here's a set of tools for Windows to validate hardening: http://www.microsoft.com/en-us/download/details.aspx?id=11910 https://www.microsoft.com/en-us/download/details.aspx?id=29851
Here's one for Linux: http://www.trapkit.de/tools/checksec.html
Here's some random documentation: http://wiki.debian.org/Hardening http://stackoverflow.com/questions/13276692/safeseh-gs-on-g https://developer.pidgin.im/ticket/15290
Activity
Replying to cypherpunks:
Relatedly, is there any way to implement some of the functionality of a project like IronFox?
Just noting the link to https://lists.torproject.org/pipermail/tor-talk/2013-November/031111.html from the blog post at https://blog.torproject.org/blog/tor-weekly-news-%E2%80%94-november-20th-2013
I played around with this a bit today and here is a tiny bit of progress and some rabid fangirling of objdump.
I enabled ASLR and DEP for tor.exe and libevent (nothing else automatically picks up LDFLAGS, so I need to look into that) and so far nothing is crashing for me on Win7.
Relatedly, I've been using objdump lately to look at the results of builds from #9444 (closed) and decided to see if it's possible to glean information about ASLR and DEP from the Windows binaries without having to check them in ProcessHacker or some other Windows app. For DLLs and EXEs (both PE), there is something called DllCharacteristics in the header which will tell you which, if any, of those are enabled. For ASLR it is 0x40 and for DEP it's 0x100, so all of our DLLs and EXEs should be showing something like:
DllCharacteristics 00000140. The main reason this is cool is that you can use objdump from Linux to investigate this, you don't need to use some Microsoft tool, and it can be automated post-build as a QA measure to make sure nothing funky happens accidentally to disable these measures.When I talked about this on IRC, Yawning also mentioned this ruby script which I haven't tried yet: https://github.com/Myne-us/dllcharacteristics
scan system for characteristics of PE files. This will enable you to find PEs with ASLR disabled, DEP disabled, and more
There is also pefile: http://code.google.com/p/pefile/
pefile is a multi-platform Python module to read and work with Portable Executable (aka PE) files. Most of the information in the PE Header is accessible, as well as all the sections, section's information and data.
As for the crashing: when was it happening? Did anything trigger it? So far I have been unable to reproduce with my test bundle. If anyone wants to test it, it's here: https://people.torproject.org/~erinn/qa/torbrowser-install-3.0-rc-1_en-US-hardened.exe e5dac7a49095a1422d82df05f67476119642c7488c8c02a7c452757fcdd769ba
I'm going to continue to tighten up the hardening options and try to reproduce the crashing. I'll also test further with the Microsoft tools mentioned above.
#10505 (moved) is related. See http://sourceforge.net/mailarchive/message.php?msg_id=31034877 (which is posted there) for a possible crash scenario.
The crash happened for me with way more than just ASLR enabled. I did:
export CFLAGS="-mwindows -fstack-protector-all -fPIE -Wstack-protector --param ssp-buffer-size=4 -fno-strict-overflow -Wno-missing-field-initializers -Wformat-security" export LDFLAGS="-mwindows -Wl,--dynamicbase -Wl,--nxcompat -lssp -L/usr/lib/gcc/i686-w64-mingw32/4.6/"
I also wrapped g++, gcc, and ld: https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/i686-w64-mingw32-g++ https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/i686-w64-mingw32-gcc https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/i686-w64-mingw32-ld
I'm guessing one of those many options is the culprit. Ideally we'd find out what it is, report it, and use the rest.
But in the short term, if just ASLR and DEP can be enabled without issue, we should start building with those two at least.
-pie is definitely the culprit. I built two TBBs: one with DEP/ASLR and no -pie and another with DEP/ASLR and -pie. The latter crashes and the former doesn't. I also get the same wrong AddressOfEntryPoint (00001000) in the build with -pie whereas in the non-pie build I get the correct one (000014b0).
It took a little wrangling but I eventually got all of the libs we build building with DEP/ASLR (this is including the Firefox libs). I think we should consider extending that to the libssp we build in mingw-64, but I didn't look into how to do that yet.
I have a gross monolithic branch in user/erinn/tor-browser-bundle.git called windows-hardening-monolithic: https://gitweb.torproject.org/user/erinn/tor-browser-bundle.git/shortlog/refs/heads/windows-hardening-monolithic
I will break it up further before I ask for any real merging, but I wanted to link it here because I won't be able to get to that before Monday and thought people should have a chance to look it over or at least test it if they felt like doing so. This enables DEP/ASLR and SSP on all binaries and DLLs we build. I also built a new libssp and am shipping the bundle with that instead of the MinGW one we were using before.
Issues:
-
None of the PT stuff is hardened at all. Is this a blocker for getting it into a beta?
-
skruffy's got two patches in here: one for binutils that creates a proper reloc section so we can have working ASLR, and one for gcc that prevents the use of /dev/urandom on Windows. nickm and zwol have reviewd the gcc (SSP) patch and deemed it okay, but both said someone with more binutils knowledge needs to check the ld patch. For reference they are here:
(And yes, I am aware they don't have descriptions in the patches. I'm going to fix that when I figure out good descriptions. :))
A test bundle is here: http://lucio.erinn.org/~helix/torbrowser-install-3.6-beta-1_en-US.exe a198037a157b1f29e80d3920ad964b590e4f57b44f93fcd3a1aba98fa2915c60
-
-
Only the libssp-0.dll is different (apart from the different tor-browser-bundle commit). I uploaded mine: https://people.torproject.org/~gk/misc/hardened_libssp-0.dll 36f7c2434e0e65ca9b6065c97a42de98992e434d80236e3619140c88ca7dfcdc. I built from commit 17425dec3a13de51b717efeb8bdde1a4460d31fa.
Trac:
Cc: gk, mikeperry to gk, mikeperry, tom@ritter.vggk -- it turned out to be a one line patch to make libssp build reproducibly. I've updated my branch.
As for next steps, the branch needs to be rebased... I tried it today but it looks quite messy with all the meek changes that have happened in the intervening period. I either need more sleep or to sit with someone and work on fixing the conflicts, because my first glance at it made me worry I might screw it up.
Trac:
Cc: gk, mikeperry, tom@ritter.vg to gk, mikeperry, tom@ritter.vg, intrigeriI've updated all of my patches for the 4.x series and the branch is here:
I have a test bundle here as well, if anyone would like to build & check for reproducibility: http://paganini.erinn.org/~erinn/torbrowser-install-4.0-alpha-1_en-US.exe 9328f4887406667d5d578d256fe9650e7b685f02e8f9a9248b1b1c7ef81987a1
Some issues remain, namely that none of the pluggable transports are hardened. The python dll we're distributing only has DEP and not ASLR. As I understand it, the default options have changed in the distributions of Python 3.x, but it seems like no small task to switch from one to the other. I looked into crosscompiling Python and while it seems possible (in the sense that there is some python-mingw port by some random person on the internet), it also might be quite a time consuming project.
As for the PTs written in Go, I refer to this thread where Russ Cox says:
Address space randomization is an OS-level workaround for a language-level problem, namely that simple C programs tend to be full of exploitable buffer overflows. Go fixes this at the language level, with bounds-checked arrays and slices and no dangling pointers, which makes the OS-level workaround much less important. In return, we receive the incredible debuggability of deterministic address space layout. I would not give that up lightly.Anyway, feedback welcome. Putting this into needs_review. I should note that skruffy's binutils patch remains mostly unreviewed, and I still need to send it upstream, but if anyone feels like digging into it before I do, I would appreciate it (and so would he).
Edit: And Tom, since you were part of the iSEC review, can you double check that I got the hardening right? I reviewed the binaries with objdump and in procexp and Process Hacker on a Win7 VM but would love a second set of eyes.
Trac:
Status: accepted to needs_review