ASLR Tests

Hi,

I thought it would be fun to do some tests of ASLR on Windows7.

Therefore I created the following tools:
1. A small C program that allocates different types of memory creating a CSV log file of the addresses
2. A batch that calls the compiled C program in an endless loop
3. An XLSX file that creates a Pivot Chart for each type of memory to show the distribution of addresses

First I compiled the executable for 32-bit with ASLR enabled and ran it 65536 times. If 16-bit would be used for entropy each address should occur aproximately one time.

Here are the files used:
http://pastebin.com/XA3x4mm7 <-- C source
http://pastebin.com/kprrmnjS <-- test.cmd calling compiled executable in endless loop
http://www.filedropper.com/aslr <-- Empty ASLR.XLSX file (populate it with the test results)

Here is a resulting ASLR.XLSX for the application compiled in 32-bit with ASLR enabled:
http://www.filedropper.com/aslr32a_1

I will do another test for 32-bit compilation WITHOUT using the ASLR compiler option next. Have to eat something first unfortunately. LOL

Andreas

 

Here is the result of the same test if the application is not compiled with ASLR enabled:
http://www.filedropper.com/aslr32b

As expected the stack adresses are not randomized.

 

Would be fun to compare it to some linux system running PAX? Any volunteers? :-]

 

Too early to draw many conclusions from this, but one can only strongly suggest to recompile apps with the flag enabled, because the stack and static heap are not randomized at all and VirtualAlloc resulted in the same address almost 50% of times. If using the ASLR flag when compiling the stack seems to be randomized really good instead if looking at the first excel sheet.

 

So here are the results for 64-bit with ASLR option enabled when compiling:
http://www.filedropper.com/aslr64a_1

And here without the ASLR option:
http://www.filedropper.com/aslr64b

What looks a bit strange to me is that the stack is slightly less randomized than on 32-bit, not a big difference though but I would have expected it to be the other way around.

All the tests were conducted without any EMET stuff, just the plain OS. The OS was Windows7 x64 SP1. On Windows8 I would expect different results as MS has changed ASLR.

Andreas

 

win32/ASLR flag:
stack: 25301 addresses | max occurance of same address: 14
static heap: 254 addresses | max occurance of same address: 1216
c runtime heap: 199 addresses | max occurance of same address: 2092
heap (VirtualAlloc): 74 addresses | max occurance of same address: 15312
heap (HeapAlloc/1st Heap): 165 addresses | max occurance of same address: 978
heap (HeapAlloc/2nd Heap): 403 addresses | max occurance of same address: 706

win32/No ASLR flag:
stack: 1 addresses | max occurance of same address: 65536
static heap: 1 addresses | max occurance of same address: 65536
c runtime heap: 110 addresses | max occurance of same address: 2118
heap (VirtualAlloc): 30 addresses | max occurance of same address: 31288
heap (HeapAlloc/1st Heap): 31 addresses | max occurance of same address: 2178
heap (HeapAlloc/2nd Heap): 298 addresses | max occurance of same address: 1196

win64/ASLR flag:
stack: 4096 addresses | max occurance of same address: 31
static heap: 254 addresses | max occurance of same address: 303
c runtime heap: 123 addresses | max occurance of same address: 1185
heap (VirtualAlloc): 39 addresses | max occurance of same address: 18502
heap (HeapAlloc/1st Heap): 73 addresses | max occurance of same address: 1719
heap (HeapAlloc/2nd Heap): 257 addresses | max occurance of same address: 1212

win64/No ASLR flag:
stack: 1 addresses | max occurance of same address: 65536
static heap: 1 addresses | max occurance of same address: 65536
c runtime heap: 79 addresses | max occurance of same address: 1609
heap (VirtualAlloc): 28 addresses | max occurance of same address: 22800
heap (HeapAlloc/1st Heap): 32 addresses | max occurance of same address: 2145
heap (HeapAlloc/2nd Heap): 222 addresses | max occurance of same address: 1387

 

looks a bit whack

 

oh, have do redo the 64-bit tests.....i only logged 4 bytes of the address....my bad.

 

strange, the results are almost the same even though I changed the source code to log 64-bit addresses. am running it a second time now.

this is the 64-bit source code i used: http://pastebin.com/Adtx9SUs

 

win64/ASLR flag:
stack: 4096 addresses | max occurance same address: 22
static heap: 254 addresses | max occurance same address: 189
c runtime heap: 123 addresses | max occurance same address: 793
heap (VirtualAlloc): 37 addresses | max occurance same address: 11176
heap (HeapAlloc/1st Heap): 73 addresses | max occurance same address: 1015
heap (HeapAlloc/2nd Heap): 245 addresses | max occurance same address: 772

win64/No ASLR flag:
stack: 1 addresses | max occurance same address: 65536
static heap: 1 addresses | max occurance same address: 65536
c runtime heap: 79 addresses | max occurance same address: 1525
heap (VirtualAlloc): 27 addresses | max occurance same address: 22530
heap (HeapAlloc/1st Heap): 32 addresses | max occurance same address: 2129
heap (HeapAlloc/2nd Heap): 221 addresses | max occurance same address: 1362

Different but not any better.

 

Below I calculated the probability to guess a specific address if randomized by ASLR.

I also added the number of attacks needed on average to succeed.

Format is percentage in test result / expected result given the number of possible addresses / avg. number of attempts / expected avg. number of attempts

win32/ASLR flag:
stack: 0.02% | 0.0039% | 4681 | 25.301
static heap: 1.86% | 0.39% | 54 | 254
c runtime heap: 3.19% | 0.5% | 31 | 199
heap (VirtualAlloc): 23.36% | 1.35% | 4 | 74
heap (HeapAlloc/1st heap): 1.49% | 0.61% | 67 | 165
heap (HeapAlloc/2nd heap): 1.08% | 0.25% | 93 | 403

win32/No ASLR flag:
stack: 100.00% | 100.00% | 1 | 1
static heap: 100.00% | 100.00% | 1 | 1
c runtime heap: 3.23% | 0.91% | 31 | 110
heap (VirtualAlloc): 47.70% | 3.33% | 2 | 30
heap (HeapAlloc/1st Heap): 3.23% | 3.23% | 30 | 31
heap (HeapAlloc/2nd Heap): 1.82% | 0.34% | 55 | 298

win64/ASLR flag:
stack: 0.03% | 0.02% | 2979 | 4096
static heap: 0.29% | 0.39% | 347 | 254
c runtime heap: 1.21% | 0.81% | 83 | 123
heap (VirtualAlloc): 17.00% | 2.70% | 6 | 37
heap (HeapAlloc/1st heap): 1.55% | 1.37% | 65 | 73
heap (HeapAlloc/2nd heap): 1.18% | 0.41% | 84 | 245

win64/No ASLR flag:
stack: 100.00% | 100.00% | 1 | 1
static heap: 100.00% | 100.00% | 1 | 1
c runtime heap: 2.33% | 1.27% | 43 | 79
heap (VirtualAlloc): 34.38% | 3.70% | 3 | 27
heap (HeapAlloc/1st heap): 3.25% | 3.13% | 31 | 32
heap (HeapAlloc/2nd heap): 2.08% | 0.45% | 48 | 221

 

Interesting tests.
I don't know if this is true, but I read somewhere that the amount of physical memory influences the number of possibilities. e.g. if you install Windows 7 64 bit on a machine with 4GB RAM, there will be more occurrences of the same address than on a machine with 8GB RAM.

 

That sounds interesting. It is actually just the virtual address space getting randomized, meaning that it could use the entire available address space, no matter how much physical RAM was stuck into the machine.Would be interesting to repeat it on a machine with different physical RAM to see if the physical RAM influences the outcome which it shouldn't. Maybe I can put some more time and effort into this next week and do Windows8/2012 tests as well. Am curious if the good old "Buy more RAM" helps security wise too, LOL.