Forgot your password?
Security Microsoft Operating Systems Software Windows Hardware

ALSR in Vista Gets OEM Push 170

Posted by Zonk
from the at-leas-they're-trying dept.
gr00ve writes "Eweek is reporting that all the major OEMs will enable DEP/NX in their BIOSes by default to allow Address Space Layout Randomization (ASLR), a new security feature in Windows Vista, to work as advertised. ASLR, which is used to randomly arrange the positions of key data areas to block hackers from predicting target addresses, is meant to make Windows Vista more resilient to virus and worm attacks." From the article: "Because most CPUs that ship today support DEP/NX, Howard explained that Vista users on older hardware can use the control panel to manually verify that PCs have DEP enabled. With full support from OEMs, Microsoft is effectively using ASLR to create software diversity within a single operating system, a move that is widely seen as Redmond's attempt to address the monoculture risk. The memory-space randomization technique will block the majority of buffer overflow tricks used in about two-thirds of all worm and virus attacks."
This discussion has been archived. No new comments can be posted.

ALSR in Vista Gets OEM Push

Comments Filter:
  • Re:I call BS (Score:3, Informative)

    by interiot (50685) on Friday December 15, 2006 @01:46PM (#17259008) Homepage
    This article [] seems to imply that ASLR (or ALSR or whatever it is) can either be disabled by the user system-wide, or that certain systems won't have the features required to enable ASLR. So it probably won't stop determined users.
  • by Anonymous Coward on Friday December 15, 2006 @01:50PM (#17259074)
    The technique is simply a scrambling of address of DLLs and eventually of procedures of those DLLs. The symbols will be remapped accordingly and you should be able to use your debugger as always. It just makes more difficult to make "jump to libc" attacks which defy DEP [] [] entirely.
  • by Rosyna (80334) on Friday December 15, 2006 @01:50PM (#17259086) Homepage
    Isn't this the same as Linux virtual address randomization that works without BIOS?

    Yes, but the NX bit enforcement is part of a larger security push. It just happens that most articles confuse ASLR with NX (or are fuzzy on the details of each) when talking about them both. Part of the confusion is the fact in order for ASLR to be effective, then the NX bit should be enforced []. AFAICT, ASLR doesn't actually require NX at all and it's a mistake these "technical journalists" are making.

    Basically, Vista adds a bunch of walls to increase security. the NX bit and ASLR are just two separate instances of those walls.

    The big news is that even though some OEMs have previously disabled the NX bit in the BIOS (due to software compatibility issues), they've said they'll enable it by default in the future.
  • Re:grsec (Score:5, Informative)

    by oojah (113006) on Friday December 15, 2006 @01:52PM (#17259102) Homepage
    It's PaX actually, but yes. You can randomise the kernel stack base, the user stack base and the mmap() base.

    Security Options->PaX->Address Space Layout Randomisation in your kernel config, assuming you have the appropriate patches installed.


  • BS on your BS (Score:5, Informative)

    by Mr 44 (180750) on Friday December 15, 2006 @02:10PM (#17259386)
    In what way does this prevent FairUse4WM?

    This is a good thing to prevent viruses, without affecting anything else. Buffer overflow attacks need to rely on a known location in memory to jump to, typically kernel32!LoadLibrary/GetProcAddress, which will allow them to dynamically access the rest of the functions they need. Read more here: _Buffer_Overflow_Attacks.html []

    This is 100% completely unrelated to DRM bypass programs, which can actually link to the correct functions. Anyone who mods the parent up has no idea about how windows security or programming works.

    It sounds like the parent might (just trying to be generous here) be confusing FairUse4WM with the Apple Fairplay hack tool, which does rely on known offsets within the fairplay module's memory layout. However, even that wouldn't be affacted by this, since an actual properly linked program can still determine the base address it needs.
  • Re:BS on your BS (Score:4, Informative)

    by Mr 44 (180750) on Friday December 15, 2006 @02:43PM (#17259930)
    as far as I know, FairUse4WM doesn't rely on known offsets as a key aspect of how it works. Even so, what you are referring to would be a combination of the module's base address and an offset. ASLR would just mean the module base address changes every boot. A program running on the machine would still be able to call kernel32!GetModuleHandle to determine the current base address, and obviously ASLR wouldn't have anything to do with the offset from that base.

    However, it still prevents buffer overflows, since any shellcode wouldn't have gotten "fixed up" by the loader, and so wouldn't even be able to access any kernel32 functions, since the buffer overflow data would need to hard-code an absolute address.
  • by salimma (115327) on Friday December 15, 2006 @02:52PM (#17260064) Homepage Journal
    This is pathetic. The OS vendor is so inept that they can't keep hostile code from changing kernel data space, and their answer to this is to randomly move kernel code around?

    No - this targets userspace security. If everytime a DLL is loaded it starts at a different base address, then you cannot write a worm that has the addresses hardcoded, so buffer overflow attacks will be much less effective. OpenBSD started doing this several years ago, and Linux has also had it for some time.

    Microsoft is also introducing "kernel patch protection" that, I'd guess, would probably block unsigned kernel modules from being loaded. Even in the Unix world, if you're a superuser you can load kernel modules at runtime. The security risk in Windows currently is that everyone is an Administrator by default.
  • by flynn_nrg (266463) <mmendez AT gmail DOT com> on Friday December 15, 2006 @04:58PM (#17262002) Homepage Journal
    Not really. In the BSD world once you raise the secure level you cannot load kernel modules, root or not. And of course once you've raised the secure level you cannot lower it until next reboot.
  • by PsychicX (866028) on Friday December 15, 2006 @05:03PM (#17262098)
    Nope, not so easy.

    The problem lies in the subtlety of "not successful()" in your psuedo-code. It can't be implemented, to be exact. What you're generally trying to do in a buffer overflow attack is to replace the return address for the current function with the address for the code you actually want to run. If you get your addresses wrong, you crash and you're done. And when you're playing games with this sort of thing, exceptions are pretty much out the window. You can't rely on using SEH (structured exception handling, look it up if you're not familiar) to save your ass, because guess what -- you destroyed the application stack to get here! If you take an exception, you're completely gone.

    So basically there's no reliable way to actually execute the desired code. All of the solutions you'd normally apply, thinking from an apps programmer's point of view, no longer work. Remember, the virus is a parasite which will destroy the process beyond repair. The goal is to jump ship and set up somewhere core to the system. And none of the usual mechanisms are functional because you've gone and mucked them up. You need to talk (in)directly to the operating system, and ASLR makes that impossible to do reliably.

    That's the theory, anyway. Hackers have proven to be rather clever and innovative.
  • by julesh (229690) on Friday December 15, 2006 @05:09PM (#17262176)
    What exactly can the BIOS do with the hardware that the OS or boot loader can't? Err , nothing as far as I'm aware so whats the deal here?

    As I understand it, there's a method that can be used to disable NX protection on some processors. Some BIOSs/motherboards do this. Once it is done, there's no way for the OS to undo it.

    What all this has to do with ASLR is beyond me.
  • by bluefoxlucid (723572) on Friday December 15, 2006 @06:11PM (#17262936) Journal

    Works well when you can try this over and over; but sometimes you'll need to break a lot. On vanilla Linux you have 524288 states of memory (stack and mmap() base) relevant to your attack (you probably only care about {stack OR heap} and {mmap() OR program base}); in PaX you have 2^(24+16). Now if Internet Explorer crashes on the first newbie you try to exploit, you have to wait until he surfs to your site AGAIN to attack; if you have high-end randomization (2^48 is doable on x86, since the stack/heap/mmap()/program bases are all independently randomized; about double is possible on x86_64), it could be eternity before you actually break something (2^32 is 4 billion, earth's population is 6 billion).

    A miss from ASLR attack will change the instruction pointer and crash the program on failure, almost guaranteed. You'll either hit data; misalign with the instruction stream; align with the instruction stream in some way that makes no sense (in the middle of a function with another function's call stack); or hit unmapped memory. Any of these will get you program termination. You think someone won't notice if his Web server decides to crash and restart 300,000 times a minute? A simple host IDS can figure out that's wrong.

  • by Myria (562655) on Friday December 15, 2006 @11:56PM (#17265690)
    In previous versions of NT, if a DLL doesn't have to be relocated, the kernel will make the read-only portions of the mapped file shared among all processes using that DLL. With address randomization, it's as if *every* DLL is relocated. Won't this eat a lot of memory having a bunch of copies of the same DLL taking up RAM?


Passwords are implemented as a result of insecurity.