Share via


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:

/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:  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. ...

  • 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:&amp;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&#243;n de informaci&#243;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
    &amp;hellip;..well&amp;hellip;sort of.
    Go check out Michael Howard&amp;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&amp;nbsp;g&#246;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&amp;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 .&#160; 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 からは (条件がそろえば) デフォルトで有効になっています。