Opened 8 years ago

Last modified 2 years ago

#4152 assigned enhancement

Implement Bottom Up Randomization (Windows platform)

Reported by: bastik Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-security
Cc: bastik.public@…, tjr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

To improve ASLR efficiency you could add Bottom Up Randomization.

Matt Miller told Didier Stevens how he did. So I know that too.

“It works by reserving a random number (between [0,256]) of 64K regions via VirtualAlloc. This has the effect of consuming a small portion of the bottom part of the address space. Since the Windows kernel assigns base addresses for collided DLLs by searching for a free region starting at the bottom of the address space, bottom up randomization ensures that a random base address will be assigned. Without bottom up randomization the bottom part of the address space remains fairly static (with some exceptions, such as due to heap, stack, and EXE randomization).”

Code
"int iIter;
int iRand;

srand(time(NULL));
iRand = rand() % 256 + 1;
for (iIter = 0; iIter < iRand; iIter++)

VirtualAlloc(NULL, 64*1024, MEM_COMMIT | MEM_RESERVE, PAGE_NOACCESS);"

"In stead of 15 base addresses, with the most frequent address being using 30% of the time, my Bottom Up Randomization implementation gives me more than 300 addresses after 150.000 runs. And there’s no single address being used more than 0,5% of the time."

An comment adds that only MEM_RESERVE should be used for VirtualAlloc, because MEM_COMMIT would require more memory. Didier Stevens replies that this is possible although the additional memory wouldn't be much.

Here's the link: http://blog.didierstevens.com/2011/09/29/add-bottom-up-randomization-to-your-own-source-code/

BTW: It's impossible to chose an component, because all binaries (Tor/Vidalia at least) should make use of it.

Child Tickets

Change History (16)

comment:1 Changed 8 years ago by nickm

Component: - Select a componentTor Relay

Is there not real actual ASLR that we can use? Is this the best we can do on Windows?

It couldn't hurt to try something like this, though. We should use MEM_RESERVE, not MEM_COMMIT, as noted in the comments there.

Also, we absolutely shouldn't use srand()/rand() to get the offset.

I'm throwing this into one of the Tor components for now; if we get it working, we can make a new ticket for doing it in Vidalia, etc.

comment:2 Changed 8 years ago by rransom

By the time your code can run VirtualAlloc, every DLL that your program was linked to at build time has already been loaded, so this can't randomize their addresses. The only DLLs Tor loads at runtime are system DLLs, which should support real ASLR.

This piece of code cannot help us.

comment:3 Changed 8 years ago by bastik

Cc: bastik.public@… added

Sorry, I'm not checking my tickets for replies. (Will add myself to CC from now on)

When this piece of code is useless (because it works without the code), the ticket should be treated as "fixed" or "implemented" shouldn't it?

At least it should not be open.

"It still could not hurt"
I'm not a dev, can't read code. I don't know if it could lead to side effects.

The only thing I can think of is: Something that's injecting a DLL (even legit) into all running processes. Would that be a use-case for the above code?

comment:4 Changed 8 years ago by nickm

Milestone: Tor: unspecified

comment:5 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:6 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:7 Changed 3 years ago by nickm

Cc: tjr added
Keywords: windows hardening aslr security added
Severity: Normal
Status: newneeds_information

comment:8 Changed 3 years ago by tom

Owner: set to tom
Status: needs_informationassigned

I'm going to take this and investigate it. I'm wondering how more recent versions of Windows behave with regards to colliding dlls, and if this may yet still be helpful for JIT Spraying...

comment:9 Changed 3 years ago by cypherpunks

The correct implementation has already been written in https://blog.didierstevens.com/2012/03/29/update-se_aslr-version-0-0-0-2/
(Usually TBB Team makes hardening on Windows, but if you make it for Tor and TBB, it would be great. :)

comment:10 in reply to:  9 ; Changed 3 years ago by tom

Replying to cypherpunks:

The correct implementation has already been written in https://blog.didierstevens.com/2012/03/29/update-se_aslr-version-0-0-0-2/
(Usually TBB Team makes hardening on Windows, but if you make it for Tor and TBB, it would be great. :)

My reading of https://blogs.technet.microsoft.com/srd/2013/12/11/software-defense-mitigating-common-exploitation-techniques/ is that this technique is used by default in Windows 8+ if you turn on ASLR. So adding the code manually would improve the situation on Windows 7; but would probably just eat memory (although this may not be a real problem) on anything above that.

comment:11 in reply to:  10 Changed 3 years ago by cypherpunks

Replying to tom:

Replying to cypherpunks:

The correct implementation has already been written in https://blog.didierstevens.com/2012/03/29/update-se_aslr-version-0-0-0-2/
(Usually TBB Team makes hardening on Windows, but if you make it for Tor and TBB, it would be great. :)

My reading of https://blogs.technet.microsoft.com/srd/2013/12/11/software-defense-mitigating-common-exploitation-techniques/ is that this technique is used by default in Windows 8+ if you turn on ASLR. So adding the code manually would improve the situation on Windows 7; but would probably just eat memory (although this may not be a real problem) on anything above that.

As you like this doc, please, think about Force ASLR for TBB. But your worries about the code may be applied to old implementations only (Firefox uses that pseudo-ASLR in its pseudo-sandbox from pseudo-google https://dxr.mozilla.org/mozilla-central/source/security/sandbox/chromium/sandbox/win/src/process_mitigations.cc#302). See the researches of Didier Stevens in articles, subsequent to one in the description. Version in comment:9 includes all his findings. EMET SHIM DLL also uses something similar with no problems.

comment:12 Changed 3 years ago by tom

Owner: changed from tom to nickm

My conclusion on this is that it is a nice to have for Windows, but far from critical. I identified a different option that is similar and would be more valuable, in #22477. It is useful only on Windows 7, Windows 8+ includes it automatically.

comment:13 Changed 2 years ago by tom

Keywords: win32 added

comment:14 in reply to:  12 Changed 2 years ago by tom

Replying to tom:

My conclusion on this is that it is a nice to have for Windows, but far from critical. I identified a different option that is similar and would be more valuable, in #22477. It is useful only on Windows 7, Windows 8+ includes it automatically.

I'll recommend this as WONTFIX based on the fact that it only will affect Windows 7 users, and the addition of entropy to ASLR is useful, but the addition only makes a heap spray less likely to land - it doesn't change the exploit developer's game like adding ASLR would do.

comment:15 Changed 2 years ago by cypherpunks

Well, this ticket had been created before Windows 8 was released. And it is about the last mitigation to be implemented (see https://wiki.mozilla.org/Security/Sandbox). Tor Browser could be the first one (as usual) to have it. Then port it to Tor.

comment:16 Changed 2 years ago by cypherpunks

Component: Core Tor/TorApplications/Tor Browser
Keywords: tbb-security added; tor-relay windows hardening aslr security win32 removed
Milestone: Tor: unspecified
Owner: changed from nickm to tbb-team

You know why.

Note: See TracTickets for help on using tickets.