Funny Vista Tricks with ASLR

While doing alot of testing around the implementation of ASLR on both OSX and Vista I noticed something odd. 3rd party dlls in the Internet Explorer don’t seem to change addresses. See the screenshot below. Googletoolbar and flash9d stay at the same address through multiple reboots. I thought this was odd.

Flash9d and Googletoolbar stay at the same address.

Doing some reading it turns out that a linker flag, /dynamicbase, is what tells Vista that it is ok to rebase a DLL. This gave me a bright idea that maybe I could manually enable ASLR support in a DLL. The first step to this is to find out exactly what the /dynamicbase flag does to a binary. I did a couple of things to run this down, but mainly I compared a DLL that utilized ASLR versus one that doesn't. Mshtml.dll takes advantage of ASLR so that the target. Googletoolbar is the binary I want to force to use ASLR. After comparing alot of fields in the PE header i narrowed it to an option in the PE header, DLL Characteristics. Setting this field to 0x40 enables rebasing the DLL.

The real difference is the DLL Characteristic field which has to get set to 0x40.

1. The first step in enabling ASLR for this program is to save a copy of the original file so that it can be restored in case of an accident.

2. The next step is to open the Googletoolbar in a hex editor and find the DLL Characteristics field and set it to 0x40.

These are images of modifying the googletoolbar dll. The byte that is changed is on the bottom role on the right.

3. Save the file. B00m, some ASLR action for Googletoolbar.

Every reboot changes the load address of GoogleToolbar now.

I was worried that this would not work because of application signing. I thought that once an application is modified it would no longer run. No problems like that occurred. The toolbar seemed to work just fine.

I am not advocating doing this to your system DLLs, I just thought it was interesting.

Warning...Long post on how OSX does not has ASLR.

One of the posters to my “Bill Gates fights back” posted a very intresting statement that I felt deserved an entire blog entry for.

“First off, check the address spaces of the same framework on two different computers crash logs on OS X. Not identical.”

Ok. Because of my job I just happen to have a DoS and a weaponizied version of MoAB #1 lying around. Since popping a shell won’t get me the crash logs I need, we have got to use the DoS. I wrote the exploit based on HDM’s WMF module, its pretty nifty.

msf exploit(MOAB-01-Quicktime_rtsp) > exploit
[*] Started bind handler
[*] Using URL: http://192.168.1.108:8080/X34OVYSZq7nAQf5
[*] Server started.
[*] Exploit running as background job.
msf exploit(MOAB-01-Quicktime_rtsp) >

So going to the URL http://192.168.1.108:8080/X34OVYSZq7nAQf5 will get a crash. I do this on my desktop machine (a mac mini) and my test machine (also a mac mini). And I get a crash on each.
So I diff the two.
$ diff testmacmini.log desktop.crash.log
3,4c3,4
<> Host Name: david-maynors-computer-2
> Date/Time: 2007-02-05 08:55:15.473 -0500
10c10
<> Parent: WindowServer [62]
17c17
<> PID: 191
50,53d49
<> Thread 4:
> 0 libSystem.B.dylib 0x9001aafc select + 12
> 1 libSystem.B.dylib 0x90024b07 _pthread_body + 84
>
75,80c75,80
<> 0x5ae000 - 0x5affff com.apple.textencoding.unicode 2.1 /System/Library/TextEncodings/Unicode Encodings.bundle/Contents/MacOS/Unicode Encodings
> 0x14bc5000 - 0x14bd3fff com.apple.quicktime.webplugin 7.0.4 /Library/Internet Plug-Ins/QuickTime Plugin.webplugin/Contents/MacOS/QuickTime Plugin
> 0x15092000 - 0x150aefff GLDriver /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLDriver.bundle/GLDriver
> 0x150b5000 - 0x150d6fff GLRendererFloat /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLRendererFloat.bundle/GLRendererFloat
> 0x15169000 - 0x152aafff GLEngine /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine
> 0x152d2000 - 0x15327fff com.apple.driver.AppleIntelGMA950GLDriver 1.4.32 (4.3.2) /System/Library/Extensions/AppleIntelGMA950GLDriver.bundle/Contents/MacOS/AppleIntelGMA950GLDriver

Yes indeed there are some differences. This does not mean ASLR has been implemented. In order to take advantage of this vulnerability you need the address of System() to stay static. That is contained in the libSystem library which stays static across machines.

0x90000000 - 0x9016efff libSystem.B.dylib /usr/lib/libSystem.B.dylib

The address of the System() function is at 0x90046c30 on both machines. The libraries containing this never change location, only some of the framework stuff. The fact some of the framework addresses load at different addresses does not provide you with any security benefit.

If you want to see the full crash logs email me and I am happy to send them over.