Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#2358 closed enhancement (implemented)

Windows ASLR is not enabled for tor.exe, and DEP should be forced

Reported by: special Owned by:
Priority: Medium Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


To mitigate the potential impact of vulnerabilities, the Tor executable for Windows should be built with support for Address Space Layout Randomization. See for a potentially dated explanation of how this could be done for MinGW.

Additionally, Tor should permanently enable DEP by calling SetProcessDEPPolicy at startup. By default, non-server versions of Windows only apply DEP to processes that opt-in with this call, and it prevents the possibility of malicious code causing the process to opt out.

Child Tickets

Attachments (1)

0001-Enable-ASLR-and-permanent-DEP-for-Windows-executable.patch (1.9 KB) - added by special 8 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 8 years ago by nickm

Milestone: Tor: 0.2.2.x-final

Looks worthwhile and fairly easy to do. marking for 0.2.2, assuming somebody can figure out the right way to do this.

To do the DEP trick, I think we'll need to do the usual LoadLibrary/GetProcAddress shenanegans, right? It seems not to have been added till XP SP3 / Vista SP1.

comment:2 Changed 8 years ago by special

Status: newneeds_review

This was much easier than I expected. Recent (March 2009) versions of the mingw linker can set the nxcompat (forced DEP) and dynamicbase (ASLR-compatible) options, so I wrote an autoconf test to enable these.

It appears that with nxcompat from the linker, DEP is permanent, which makes the call to SetProcessDEPPolicy redundant. I put that in regardless, because not all linker versions may support these options. It could be left out.

For testing, view the properties in Process Explorer. DEP should be permanent, and ASLR enabled.

comment:3 Changed 8 years ago by nickm

Whoa; that _does_ look easy. Thanks for taking this on. One thing -- when I read the link you mentioned, it seemed to imply that we wouldn't benefit from ASLR unless we set the relevant flags on all the DLLs we linked. Do we need to do anything there as part of our package build process?

(I'm going to be away from my windows vm till monday or so, but I hope I can try it out then.)

comment:4 Changed 8 years ago by special

I can't find a clear answer on this; ASLR is definitely enabled for the executable's address with this patch, but DLLs that don't have dynamicbase set may not be randomized. That must happen while building the DLL. It would probably be worth putting similar logic into libevent, and perhaps openssl, to prevent exploits from leveraging those to gain some sort of access.

From my understanding, after this patch, the most important parts (Tor itself, and all system DLLs used by Tor) will be randomized.

comment:5 Changed 8 years ago by Sebastian

Hrm, I can't find aslr in process explorer, where should I look? DEP is indeed enabled in my test build.

comment:6 Changed 8 years ago by Sebastian

Ah, ASLR was just not supported on windows xp. I transferred the resulting binary to a windows 7 machine, and process explorer showed aslr as enabled.

comment:7 Changed 8 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

merged, thanks! We'll want to do this for our libraries too, though: I'm opening a new ticket for that.

comment:8 Changed 8 years ago by nickm

Conservation of Tickets applies: Ticket to do this for our library builds opened as #2487.

comment:9 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.