Address Space Layout Randomization in Windows Vista

Artikkeli
05/26/2006

Windows Vista Beta 2 includes a new defense against buffer overrun exploits called address space layout randomization. Not only is it in Beta 2, it’s on by default too. Now before I continue, I want to level set ASLR. It is not a panacea, it is not a replacement for insecure code, but when used in conjunction with other technologies, which I will explain shortly, it is a useful defense because it makes Windows systems look “different” to malware, making automated attacks harder.

So what is ASLR? In short, when you boot a Windows Vista Beta 2 computer, we load system code into different locations in memory. This helps defeat a well-understood attack called “return-to-libc”, where exploit code attempts to call a system function, such as the socket() function in wsock32.dll to open a socket, or LoadLibrary in kernel32.dll to load wsock32.dll in the first place. The job of ASLR is to move these function entry points around in memory so they are in unpredictable locations. In the case of Windows Vista Beta 2, a DLL or EXE could be loaded into any of 256 locations, which means an attacker has a 1/256 chance of getting the address right. In short, this makes it harder for exploits to work correctly.

Think: “Where’s Waldo()?”

For example, earlier today my laptop reported the following:

wsock32.dll (0x73ad0000)
winhttp.dll (0x74020000)
user32.dll (0x779b0000)
kernel32.dll (0x77c10000)
gdi32.dll (0x77a50000)

I then rebooted the machine, and my laptop reported the following:

wsock32.dll (0x73200000)
winhttp.dll (0x73760000)
user32.dll (0x770f0000)
kernel32.dll (0x77350000)
gdi32.dll (0x77190000)

As you can see, various DLLs are loaded at different addresses and this makes it harder for exploit code to locate and therefore take advantage of functionality inside these DLLs. Not impossible, just harder.

What really raises the bar however, is the combination of various defenses we now have in Windows Vista, including:

/GS

This is a compile-time option in Visual C++ (on by default) that adds stack-based buffer overrun detection. It also juggles around some of the function arguments and the function stack variable to make some classes of attack harder to pull off. Virtually all Windows Vista binaries are compiled with this, and we are now in our fourth iteration of /GS!

When /GS is triggered, the application is terminated.

/SafeSEH

This is a linker option that writes the addresses of exception handlers to the PE header of the executable, and when an exception is raised, the OS checks the exception handler address against the list in the PE header, and if the address is not in the list, something corrupted the exception handler address so the OS kills the process.

Data Execution Protection (aka NX)

This requires CPU as well as operating system support. Most (read: all) buffer overruns come into a vulnerable application as data, and then that data is executed. NX can prevent the exploit working by marking data segments as No-Execute, in other words, you can’t run data. When the WMF flaw was found, I wrote a small malicious WMF file that popped, “oops!” on the desktop. When I ran this on my computer at home, an AMD 64FX based computer that supports NX, Windows shut the image viewer down when I read my WMF file because the operating system detected an attempt to run data.

Function Pointer Obfuscation

Long-lived function pointers are targets for attack because (a) they are long lived (!) and (b) they point to functions that are called at some point by the code. In Windows Vista we encode numerous long-lived pointers, and only un-encode them when the pointer is needed. You can read more about this functionality in a prior blog post “Protecting against Pointer Subterfuge (Kinda!)”

Summary

The net of this is ASLR is seen as just another defense, and it’s on by default in Windows Vista Beta 2. I think the latter point is important, we added ASLR pretty late in the game, but we decided that adding it to beta 2 and enabling it by default was important so we can understand how well it performs in the field. By this I mean what the compatibility implications are, and to give us time to fine tune ASLR before we finally release Windows Vista.

Please remember, this is work in progress!

I’ll write more about ASLR and some other defenses in the coming weeks. Please let us know what you think.

Comments

Anonymous
May 26, 2006
UPDATE:&nbsp; Mike Howard has posted to his blog, confirming David and providing details on the Vista...
Anonymous
May 26, 2006
In the part, system DLLs were carefully based to avoid relocations and bound to speed up loading. What happens to these optimizations now that address space layout randomization exists?
Anonymous
May 26, 2006
The comment has been removed
Anonymous
May 26, 2006
The comment has been removed
Anonymous
May 26, 2006
So you have pretty much taken a very BSD like approach to memory access for programs.

As BSD has supported memory randomization for the increase of Security for quite awhile.

And just to note BSD hasn't Really suffered major speed reductions due to it.
Anonymous
May 27, 2006
Windows Vista Beta 2 Includes a new feature called Address Space Layout Randomization or ASLR.&nbsp;...
Anonymous
May 27, 2006
It's nice to see Microsoft implementing security technologies that have been available in other operating systems, like OpenBSD, for a few years now...
Anonymous
May 27, 2006
the origins of ASLR are here: http://pax.grsecurity.net/docs/aslr.txt

for Lionel: i think Vista randomizes the DLL base addresses once per boot, not per process like PaX and others do, therefore it's quite likely that the imports are rebound at the same time, so there's no net loss of performance later (except for some delay at boot). question is how they will evolve it before release, there's certainly room for improvement (stack/heap/exe randomization for one).
Anonymous
May 27, 2006
MS is inventing the wheel again. Adress randomization existed before vista was in the drawing boards. Linux had it implemented in kernel 2.6. The name of this technology is PAX. RISE is another technology in the world of open source.
Anonymous
May 27, 2006
How about fixing the bugs rather than simply mitigating the risk?

Also, address space randomization doesn't help with local privilege escalation, or when the exploit is in a .exe file (almost all of which can't be relocated).

NX does little good when it's trivial to return-to-libc to ntdll.dll's NtSetInformationProcess to disable NX.

Melissa
Anonymous
May 27, 2006
Wow! didn't Red Hat Enterprise Linux add this feature about a year and a half ago??????
Anonymous
May 27, 2006
PingBack from http://mdavey.wordpress.com/2006/05/27/vista-build-5384-office-beta-2/
Anonymous
May 27, 2006
Myria,

As I note, ASLR is a DEFENSE it does not fix insecure code. Also, if you read the article, you would also see it applies to DLLs and EXEs, I will write a follow-up article about this in more depth this coming week.
Anonymous
May 27, 2006
Very nice. Could mean the end of many types of remote exploits. To the folks complaining about the feature and saying "fix the bugs instead" or some such foolishness: So now MS is supposed to fix the remote exploits in Symantec and other's products too? This change can help to be sure that when someone finds a remote vulnerability in an MS OR 3rd party product that actually using it will be difficult if not impossible (except as a random denial of service). To the others saying, *nix had this before: guess what? There was one car that had seat belts before the rest. Nobody complained when other manufacturers added them BECAUSE IT WAS A GOOD IDEA.
Anonymous
May 27, 2006
No i w końcu stało się. Windows Vista będzie posiadał magiczną technologię określaną jako ASLR. W końcu. Tak na prawdę, to ja nie wiem, czy Windows Vista w końcu taką funkcję posiadać będzie, czy też nie. Ale według informacji zawartych
Anonymous
May 27, 2006
Mike,

A few questions I have after reading this post:

1. Does Vista's ASLR rebase modules at different addresses in each process or at a single base address for each system boot?

2. Is ASLR limited to DLL base addresses or does it also randomize memory mappings done anonymously?

3. Does ASLR in Vista randomize all DLL bases or just those of certain DLLs? If the latter, which ones?
Anonymous
May 27, 2006
What good is address randomization if the author of this column was able to determine the location of various dll's anyway (as show below, taken from the above article)?

Surely malicious code could do the same!?

For example, earlier today my laptop reported the following:
wsock32.dll (0x73ad0000)
winhttp.dll (0x74020000)
user32.dll (0x779b0000)
kernel32.dll (0x77c10000)
gdi32.dll (0x77a50000)
I then rebooted the machine, and my laptop reported the following:
wsock32.dll (0x73200000)
winhttp.dll (0x73760000)
user32.dll (0x770f0000)
kernel32.dll (0x77350000)
gdi32.dll (0x77190000)
Anonymous
May 27, 2006
What ever happeed to this: http://blogs.msdn.com/michael_howard/archive/2005/09/30/475763.aspx
Anonymous
May 27, 2006
PingBack from http://justinblanton.com/2006/05/address-space-layout-randomization-in-windows-vista
Anonymous
May 27, 2006
To the Microsoft bashers:

Are you guys saying that because Red Hat added this 1.5 years ago and Open BSD had it before that, then Microsoft is wrong to add it to Vista?

If they don't add it, you'd bash them, and yet when the do add it, you still bash them. Grow up.

(Assuming that you guys are correct in the first place that Vista is doing nothing that Red Hat and Open BSD aren't doing. I put little faith in your "analyses". I know from reading slashdot that many of your ilk haven't the first clue to what Microsoft's products are really doing, even outright refusing to learn, and merely assume that Microsoft is doing nothing that others haven't done before.)
Anonymous
May 27, 2006
The comment has been removed
Anonymous
May 27, 2006
We've had address space randomization in Linux for quite a while. Good for you that you are finally catching up.
Anonymous
May 28, 2006
To Myria:
"How about fixing the bugs rather than simply mitigating the risk?"

Kind of hard when the bugs are not in your own code. Security in OSes consists of two things, first is to secure the OS itself, the other thing is to mitigate or prevetn security-breaches in applications running on the OS.
Anonymous
May 28, 2006
Despite the various people above who miss the point, I am quite happy to see this. Please keep going with these defenses!
Anonymous
May 28, 2006
Awesome!

To those who are saying well Linux/BSD had this earlier -> yes, yes they did. But so what? This is wonderful news and along with the other improvements could help turn the tide.

It's also worth bearing in mind that ASLR on Windows is a lot harder to do than on Linux, partly because of PE/ELF differences but mostly because Linux vendors such as Red Hat have a rather cavalier approach to backwards compatibility (a LOT of apps break in the face of ASLR).

I'd be interested to hear more about the compatibility issues surrounding this. I work on the Wine project and a few years ago we got bit hard by execshield being rolled out on Fedora. The problems were partly that it was randomizing DLL loads into regions we needed protecting (eg for loading the exe file into) and partly because apps which rely on particular VM layouts are unfortunately quite common.

World of Warcraft in particular springs to mind (just discussing this one on IRC now actually).
Anonymous
May 29, 2006
PingBack from http://mkseo.pe.kr/blog/?p=1470
Anonymous
May 30, 2006
Good job for all of you, Michael!

All of this is result of SDL. You have thought about security from so many different angles and considered many situations to make Vista more secure and reliable.

Gongratulations!
Anonymous
May 30, 2006
OK. According to bink.nu this reduces odds of finding the appropriate memory address to 1/256. If I was a malware coder, I'd then code the malware to check 256 times, in all locations. Tell me why this wouldn't work. :)

CF
Anonymous
May 30, 2006
A free (for personal use) software package called Wehntrust provides this functionality on current Windows operating systems:
http://www.wehnus.com/
Anonymous
May 30, 2006
Is there any way to disable this. The reason I ask is since the 5XXX builds of Vista (including Beta 2) My computer crashses on the boot screen. If I have one 512 module in it works fine. If I place another 512 module ( And i have tried different slots and different modules) it will boot but some where randomly during the booto screen process the screen will freeze and sometimes pixalate as well.

Windows XP on the same machine boots with both RAM modules with no problems. Could this technology be causing this problem? Is there a way to disable this so I can see if this is the problem?
Anonymous
May 30, 2006
ASLR is not present in any free linux distributions.
Anonymous
May 31, 2006
To Christopher Feyrer

>>I was a malware coder, I'd then code the >>malware to check 256 times, in all >>locations. Tell me why this wouldn't work. :)

When you get it wrong you'll crash the app, after a few crashes any admin worth his salt would realize there is an attack going on.
Anonymous
May 31, 2006
PingBack from http://www.infosecblog.net/?p=97
Anonymous
May 31, 2006
<quote>
Surely malicious code could do the same!?
</quote>

CarbonBased, there are two parts to making a buffer overflow (and its cousins) exploitable.
a) Loading malicious executable code into a process space. This doesn't necessarily have to be within the overflowed buffer itself, but can be into any buffer or object in that processes memory.

b) Getting the processor to jump to an instruction in the malicious code.

The point of ASLR is to make (b) difficult. It is really a backup for the /GS flag that protects the return pointer on the stack from being overwritten. A known way of bypassing the need to overwrite the return pointer is to jump into DLL functions loaded into the process in known places. ASLR makes the location of these functions a little less known, and therefore makes it more difficult to write shellcode that works on every machine running the same version of Windows.

It isn't undefeatable. Look up apache-scalp.c to see an exploit that used a bug in OpenBSD's memory protection scheme.
Anonymous
May 31, 2006
The comment has been removed
Anonymous
June 01, 2006
Michael Howard's blog entry on randomization of address space layout:&nbsp; http://blogs.msdn.com/michael_howard/archive/2006/05/26/608315.aspx...
Anonymous
June 01, 2006
"ASLR is not present in any free linux distributions."

http://www.adamantix.org/
http://www.gentoo.org/proj/en/hardened/
Anonymous
June 01, 2006
PingBack from http://izarnotegui.com/gmo/2006/06/01/windows-vista-implementara-aslr-address-space-layout-randomization-activado-de-serie/
Anonymous
June 01, 2006
PingBack from http://www.windowsvistaweblog.com/2006/06/01/vista-vs-hackers/
Anonymous
June 01, 2006
The comment has been removed
Anonymous
June 02, 2006
These are features that have been apart of OpenBSD and even Fedora for quite some time. Why has it taken so long for Microsoft to implament these obvous secuirty features? Do you think Microsoft will be ripping off more memory protection features form these secure operating systems? When will microsoft add a new security technologies to the arena instaed of just taking from everyone else?
Anonymous
June 02, 2006
PingBack from http://blog.checksum.org/2006/06/03/windows-vista-beta-2-defends-buffer-overflow-attacks/
Anonymous
June 03, 2006
Thats good,but when you start contribute to BSD Operating Systems?Never?Why?<br>You took to windows a lot of things.<br>Its not fair and after this i can`t LOVE microsoft.
Anonymous
June 03, 2006
As carbonBased said, that you could just retrieve the memory points inwhich these files are loaded. If this is not possible, jeese 1 in 256, i like those odds, you could easily write a brute-force style program, that trys all the address and authenticates the information retrieved by the information that is wanted. This is an extremely short sited and incredibly silly idea.

Assuming that the code needed can't be verified by some sort of "Matching" with the code needed, simply retrieve every 256 entries, run under a VM, and test the output. I may, be hard at first, yes may take someone 2 months to write the first exploit, but considering we will be using Vista for 3 to 7 years, they have plenty of time.

The platform and style of attacks may change in this case, but attackers, will not rest.

cheers, rotty
Anonymous
June 04, 2006
肯定会有新的技术来对抗这种技术的，呵呵
Anonymous
June 04, 2006
ASLR + NX is a great step in Vista to protect against remote exploit.
However the current implementation does not offer protection if :

- the process is some kind of CGI
- the overflow only affects a thread (and does not crash the main process)
- the process is automatically restarted (service for example)

In those cases the process address space will always be the same and in the worst case you just have to try 256 addresses to find the good one.
The bruteforcer can take more steps if you need to use addresses in different dlls or if some patch change the address of the dll.

I hope we will see a randomization of the process address space each time a process is started (maybe in SP1 ;-) but at the same time I understand that there is an impact on the performance in opposite to the current approach.
Anonymous
June 05, 2006
1.- Revelación de información en Mozilla Firefox2.- Actualizaciones para vulnerabilidad de Symantec3.-...
Anonymous
June 06, 2006
Hi! http://www.ringtones-dir.com/get/ ringtones site. ringtones site, Free nokia ringtones here, Download ringtones FREE. From website .
Anonymous
June 07, 2006
&hellip;..well&hellip;sort of.
Go check out Michael Howard&rsquo;s post about Address Space Layout...
Anonymous
June 07, 2006
Hi Michael, I remember having this argument for the inclusion of this 2 1/2 years ago...it's great that you have FINALLY come around to include it.

Another advantage of this technology is detecting malicious code. With ASLR it will allow better signature detection / behavioural checking of malicious code from doing all the combinations to find the correct entry point, which given current rootkits not using the Win32Api, makes this more important.

Well done!
Anonymous
June 07, 2006
The comment has been removed
Anonymous
June 11, 2006
PingBack from http://www.tuxedo-es.org/blog/2006/06/11/microsoft-windows-vista-measuring-the-security-enhancements-so-to-speak/
Anonymous
June 12, 2006
A couple of people have asked about the relationship between /GS, SAL and ASLR in Windows Vista. Here’s...
Anonymous
June 14, 2006
ASLR&nbsp;gör att adresser och pekare blir dynamiska i Vista, systemet slumpar nya Stack och Heap Adresser...
Anonymous
June 19, 2006
nice blog, congratulations from brazil
Anonymous
June 20, 2006
PingBack from http://www.matasano.com/log/332/matasano-interviews-ie-lead-pm-christopher-vaughan/
Anonymous
July 12, 2006
PingBack from http://clerigo.alucardx.net/index.php/2006/07/12/inseguridad-en-vista/
Anonymous
July 24, 2006
Thousands of people from around the world have been hard at work to ensure that Windows Vista is the...
Anonymous
July 24, 2006

One of Windows Vista's central tenets is to enhance Windows&nbsp;security to such a degree that both...
Anonymous
July 24, 2006
The comment has been removed
Anonymous
July 25, 2006
Two articles got me thinking about this today. One was the ASLR article by Michael Howard that I linked...
Anonymous
August 03, 2006
The comment has been removed
Anonymous
August 22, 2006
PingBack from http://puntodivista.wordpress.com/2006/08/22/articoli-tecnici-su-nuovi-sistemi-di-autodifesa-di-vista/
Anonymous
September 26, 2006
Today the Visual Studio 2005 team released Service Pack 1 Beta. Included in the beta is the new linker...
Anonymous
November 17, 2006
Today the Visual Studio 2005 team released Service Pack 1 Beta . Included in the beta is the new linker
Anonymous
December 05, 2006
As I mentioned in a previous series of posts , we recently had all the major OEMs on campus to discuss
Anonymous
March 15, 2007
Viele PCs werden für aufgerüstet oder durch neuere Modelle ersetzt, heute erworbene Prozessoren sind in der Regel 64-bit fähig, doch lohnt sich der Einsatz der 64-bit-Editionen von Windows Vista?Argumente für den Einsatz der 64-bit-Editionen von Window
Anonymous
April 04, 2007
From the Helping to Secure the Ecosystem Dept. Here’s some good news for people using CodeGear’s Delphi
Anonymous
January 29, 2008
The comment has been removed
Anonymous
March 16, 2008
Did you ever get a chance to blankly stare at a screen similar to the above, trying to recollect what
Anonymous
April 08, 2008
Hi, I’m Eric Lawrence from the Internet Explorer Security Team. With the RSA security conference kicking
Anonymous
August 12, 2008
Normal 0 false false false IN X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table
Anonymous
August 12, 2008
Normal 0 false false false IN X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table
Anonymous
August 15, 2008
Long time, no blog. Since the NetFX 3.5 Service Pack is available, now, I figured I’d put up a quick
Anonymous
September 11, 2008
【原文地址】 CLR Updates in .NET Framework 3.5 SP1 【原文发表日期】 19 August 08 07:57 Kevin Frie ，CLR核心部分的开发主管最近发布了一篇帖子
Anonymous
October 08, 2008
A: Our goal is to enhance the default security settings for users. We have decided to enable DEP for
Anonymous
October 28, 2008
The comment has been removed
Anonymous
November 03, 2008
A couple of weeks ago Microsoft released an out-of-band security update in bulletin MS08-067 . Looking
Anonymous
March 03, 2009
Opera browser v9.64 is available for download .  In Opera website, they said it’s a security and
Anonymous
March 16, 2009
안녕하세요! 저는 인터넷 익스플로러 보안 프로그램의 책임자인 에릭 로렌스라고 합니다. 지난 화요일, 딘(Dean)이 신뢰성 높은 브라우저 에 대한 저희의 생각을 포스팅했었죠. 오늘
Anonymous
June 01, 2009
こんにちは、五寳です。 IE7 から実装されているメモリ保護 ( DEP/NX Memory Protection ) の機能ですが、IE8 からは (条件がそろえば) デフォルトで有効になっています。

Jaa

Address Space Layout Randomization in Windows Vista

Comments

Lisäresursseja