Address Space Layout Randomization in Windows Vista

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:


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.


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!)


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 (82)
  1. UPDATE:  Mike Howard has posted to his blog, confirming David and providing details on the Vista…

  2. Lionel Fourquaux says:

    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?

  3. The Insider says:

    Mike Howard talks about a new piece of technology coming with Windows Vista designed to help fight malware…

  4. Neal says:

    So, when the OS detects an attempt to execute data and shuts the app down does it clearly say so and log it?  Too many times on WinXP apps just disappear, or disappear and Windows gives some (too) nondescript error.  I don’t expect windows to analyze every app crash, or be able to give me messages that my grammy can understand, but I’ve been a developer for 15 years and frequently I have nothing to go on.

  5. Ricus says:

    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.

  6. Windows Vista Beta 2 Includes a new feature called Address Space Layout Randomization or ASLR. …

  7. Anonymous says:

    It’s nice to see Microsoft implementing security technologies that have been available in other operating systems, like OpenBSD, for a few years now…

  8. PaX Team says:

    the origins of ASLR are here:

    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).

  9. JC says:

    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.  

  10. Myria says:

    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.


  11. johnny knoxville says:

    Wow! didn’t Red Hat Enterprise Linux add this feature about a year and a half ago??????

  12. 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.

  13. Jerry says:

    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.

  14. 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

  15. 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?

  16. carbonBased says:

    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)

  17. Escamillo says:

    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.)

  18. none says:

    >MS is inventing the wheel again.  Adress randomization existed before vista was in the drawing boards.

    WTF?! they implemented it, not invented it! DOH!

  19. SomeoneElse says:

    We’ve had address space randomization in Linux for quite a while. Good for you that you are finally catching up.

  20. Erik Wikström says:

    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.

  21. Random Reader says:

    Despite the various people above who miss the point, I am quite happy to see this.  Please keep going with these defenses!

  22. Mike Hearn says:


    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).

  23. Toma Bussarov says:

    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.


  24. OK. According to 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. 🙂


  25. HD says:

    A free (for personal use) software package called Wehntrust provides this functionality on current Windows operating systems:

  26. jasonhnz says:

    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?

  27. VM says:

    ASLR is *not* present in any free linux distributions.

  28. 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.

  29. Zorba the Geek says:


    Surely malicious code could do the same!?


    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.

  30. captain BS says:


  31. Michael Howard’s blog entry on randomization of address space layout:&amp;nbsp;

  32. UNX says:

    "ASLR is *not* present in any free linux distributions."

  33. Rosyna says:

    AFAIK, when the NX/XD bit is on and a buffer overflow is triggered, the processor throws an exception. Windows can catch this exception which allows it to determine why the process crashed.

    Also, am I correct in assuming that ASLR only affects the entry points of DLLs and not the offsets of the functions?  In which case if a "sensitive" function exists within the same DLL as the function being exploited, ASLR wouldn’t prevent this? Granted, Michael explicitly says that ASLR isn’t a pancea.

    (Why it would affect the offsets, I’m not sure, it would be some evil kind of hack though… a fun kind of evil).

    Personally, I love the idea of piling on security features while writing secure code in the first place. As a "just in case" someone else hasn’t taken the same care in writing secure code.

  34. inc says:

    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?

  35. illusia says:

    That`s good,but when you start contribute to BSD Operating Systems?Never?Why?

    You took to windows a lot of things.

    It`s not fair and after this i can`t LOVE microsoft.

  36. rotty says:

    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

  37. 洒水车 says:


  38. Nicolas Pouvesle says:

    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.

  39. 1.- Revelaci&#243;n de informaci&#243;n en Mozilla Firefox2.- Actualizaciones para vulnerabilidad de Symantec3.-…

  40. Hi! ringtones site. ringtones site, Free nokia ringtones here, Download ringtones FREE. From website .

  41. &amp;hellip;..well&amp;hellip;sort of.

    Go check out Michael Howard&amp;rsquo;s post about Address Space Layout…

  42. Andrew says:

    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!

  43. Jeff Hotchkiss says:

    "simply retrieve every 256 entries, run under a VM, and test the output.":rotty

    You appear to have missed the point. Programs like a Trojan cannot be defended against at all by this kind of security, because a Trojan is a program and programs have to run. That’s what sandboxing and privileges are for.

    Of course a program already running can spot what the current addresses are!

    What ASLR does defend against is remote code execution which is modification of existing code in memory. You can’t just try in an VM 256 times and hope. Typically you’ll have crashed the app on the first try.

    Remember, the exploits being defended against are the type where you DON’T have any malicious program running yet. If you can download a program to find out the DLL addresses onto a remote target, you have already gained sufficient access that you don’t care about them.

  44. A couple of people have asked about the relationship between /GS, SAL and ASLR in Windows Vista. Here’s…

  45. ASLR&amp;nbsp;g&#246;r att adresser och pekare blir dynamiska i Vista, systemet slumpar nya Stack och Heap Adresser…

  46. criação says:

    nice blog, congratulations from brazil

  47. Thousands of people from around the world have been hard at work to ensure that Windows Vista is the…

  48. One of Windows Vista’s central tenets is to enhance Windows&amp;nbsp;security to such a degree that both…

  49. Symantec is so pissed at Microsoft for competing against it with OneCare, and for reducing the need for…

  50. Two articles got me thinking about this today. One was the ASLR article by Michael Howard that I linked…

  51. Today the Visual Studio 2005 team released Service Pack 1 Beta. Included in the beta is the new linker…

  52. Today the Visual Studio 2005 team released Service Pack 1 Beta . Included in the beta is the new linker

  53. As I mentioned in a previous series of posts , we recently had all the major OEMs on campus to discuss

  54. says:

    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

  55. From the Helping to Secure the Ecosystem Dept. Here’s some good news for people using CodeGear’s Delphi

  56. Over credit card debt management uk jouer � la roulette online

  57. Did you ever get a chance to blankly stare at a screen similar to the above, trying to recollect what

  58. IEBlog says:

    Hi, I’m Eric Lawrence from the Internet Explorer Security Team. With the RSA security conference kicking

  59. Wely says:

    Normal 0 false false false IN X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table

  60. Normal 0 false false false IN X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table

  61. Long time, no blog. Since the NetFX 3.5 Service Pack is available, now, I figured I’d put up a quick

  62. 【原文地址】 CLR Updates in .NET Framework 3.5 SP1 【原文发表日期】 19 August 08 07:57 Kevin Frie ,CLR核心部分的开发主管最近发布了一篇帖子

  63. A: Our goal is to enhance the default security settings for users. We have decided to enable DEP for

  64. Today Microsoft released a security update that fixes a remote code execution vulnerability in the Windows

  65. A couple of weeks ago Microsoft released an out-of-band security update in bulletin MS08-067 . Looking

  66. Opera browser v9.64 is available for download .&#160; In Opera website, they said it’s a security and

  67. 안녕하세요! 저는 인터넷 익스플로러 보안 프로그램의 책임자인 에릭 로렌스라고 합니다. 지난 화요일, 딘(Dean)이 신뢰성 높은 브라우저 에 대한 저희의 생각을 포스팅했었죠. 오늘

  68. こんにちは、五寳です。 IE7 から実装されているメモリ保護 ( DEP/NX Memory Protection ) の機能ですが、IE8 からは (条件がそろえば) デフォルトで有効になっています。

Comments are closed.

Skip to main content