Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
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:
  • grsec (Score:2, Interesting)

    by Jon Howard (247978)
    Didn't grsec implement something like this ages ago?
    • 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.

      Cheers,

      Roger
      • Re:grsec (Score:5, Insightful)

        by defile (1059) on Friday December 15, 2006 @02:51PM (#17260056) Homepage Journal

        This probably isn't such a big deal for open source.

        With Windows, whole swaths of the user community are running nearly identical binaries so malware authors have a large attractive market for their worms.

        With Linux, you have virtually thousands of possible binary configurations due to the high prevalence of custom compiled from source and the sheer number of competing distributions with frequent releases. Reduces the attraction.

        DISCLAIMER: Yes, I know, there are players who target niches, this rationale isn't bullet proof.

        DISCLAIMER2: Yes, address space virtualization can't stop all buffer overflow exploits either.

      • Randomizing the stack sounds like a great idea, to cure the symptom; Not the problem. Maybe we should wait for Vista SP1 before feeling comfortable leaving the front door open in an inner city environment that is the Internet. I do not know any better, but could someone post the results of having a Knoppix CD read a Vista formated hard drive? I am getting this nagging feeling that my M$-Zombie boss is going to let me find out, the hard way.
        • Re: (Score:3, Insightful)

          by oojah (113006)
          Randomizing the stack sounds like a great idea, to cure the symptom; Not the problem.

          Right, but that doesn't mean we shouldn't do it.

          Cheers,

          Roger

  • by bigdavex (155746) on Friday December 15, 2006 @01:40PM (#17258896)
    ALSR?

    34/en/m/c
    • Re: (Score:2, Funny)

      by clydemaxwell (935315)
      So is R religion or race to you? Because either you're a christian or a caucasian, and statistically speaking, you're likely to be both.
  • by Anonymous Coward
    Isn't this the same as Linux virtual address randomization [techtarget.com] that works without BIOS?
    • 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 [msdn.com]. 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.
  • Nice to see them taking steps like this.

    Alas, it's going to cause me some personal heartache. Presently, I know by heart the memory address ranges of the various core Windows components.

    • Re: (Score:3, Funny)

      by wiggles (30088)
      I know by heart the memory address ranges of the various core Windows components

      You win. You are officially the biggest geek here -- and that's saying something!

      Seriously, if you have this kind of shit memorized, you really need to get laid.
      • by idontgno (624372)
        Someone here has a sig which seems massively relevant just now:

        Three kinds of knowledge:
        1. Need to know
        2. Nice to know
        3. Get a life
        Someone is definitely in category 3.
      • by inviolet (797804)
        You win. You are officially the biggest geek here -- and that's saying something!

        You see the address ranges a lot when you're poking around in a crashed process with windebug. It's incredibly useful to know approximately where an instruction pointer is pointing.

        Guess you had to be there. :)

  • by ENOENT (25325) on Friday December 15, 2006 @01:48PM (#17259046) Homepage Journal
    Now if only Microsoft could develop a system for delivering electric shocks to users who run untrusted executables they receive in email, that would be something.
    • by truthsearch (249536) on Friday December 15, 2006 @02:06PM (#17259306) Homepage Journal
      Microsoft does sell their own mouse.......
      • I would submit that burns work as well as shock, maybe MS could put Sony batteries in their wireless mice?
    • by DLG (14172)
      If they did, then they would be accused of stifling a clearly important niche for development. Take hold of the opportunity and make your fortune!

      • by ENOENT (25325)
        One problem: I believe that the BOFH has prior art, and is willing to use it.
    • go look up the spoof RFC for "simple lart transfer protocol". well worth reading.
    • by SL Baur (19540)

      Now if only Microsoft could develop a system for delivering electric shocks to users who run untrusted executables they receive in email, that would be something.
      That's Microsoft's fault to begin with. Running arbitrary code like that has always been considered bad practice. Is anyone else old enough to remember all the controversy on USENET over executable shell archives? At least with a shar file you could read it first before running it to get at the files inside.
  • On the flipside, this "diversity" will increase the incidence of intermittent bugs. But hey, with Windows, who'll notice the difference anyway?
    • by Quantam (870027)
      Seems to me that it would make rare, intermittent bugs almost always occur. That's a very good thing for bug-hunting.
  • NX (Score:5, Funny)

    by ThurstonMoore (605470) on Friday December 15, 2006 @01:52PM (#17259110)
    I have noticed if DEP is turned on in XP when I look at the folder with all my porn and thumbnails are turned on it causes Explorer to crash. I hope they fix this.
    • by julesh (229690)
      I have noticed if DEP is turned on in XP when I look at the folder with all my porn and thumbnails are turned on it causes Explorer to crash. I hope they fix this.

      Of course this could be because one of those thumbnails is exploting a bug in Explorer's JPEG rendering and trying to execute itself, and DEP is actually preventing it from doing so...
  • 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?
    • Re: (Score:3, Informative)

      by julesh (229690)
      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.
  • "Windows Vista also introduces ..., kernel patch protection, mandatory driver signing..."

    So they make it more difficult for new hardware to be developed, and more difficult for hardware hacking in general. Unless you just click "allow this driver to run". That's going to make lots of people who develop non-mass marketed hardware very unhappy.

    The kernel patch protection sounds like a good security feature. Unless the server they serve patches from gets compromised, or unless someone finds a way to disable/

    • There is no "allow this driver to run". Under normal operation on Vista x64, drivers must be signed by a "trusted" authority (making your own root cert doesn't work), or they won't load. Period. The only way to get past it is to hit F8 when the computer boots, which only turns off mandatory signing for that session.
      • by b0s0z0ku (752509)
        Under normal operation on Vista x64, drivers must be signed by a "trusted" authority (making your own root cert doesn't work), or they won't load. Period. The only way to get past it is to hit F8 when the computer boots, which only turns off mandatory signing for that session.

        What say people chip in a few bucks for the appropriate certificate from Very$lime and then leak it onto the Internet or share it amongst themselves? Call it the Windows Authors' Collective or some such thing. The fact that you essen

    • by Evangelion (2145)

      "Windows Vista also introduces ..., kernel patch protection, mandatory driver signing..."

      So they make it more difficult for new hardware to be developed, and more difficult for hardware hacking in general. Unless you just click "allow this driver to run". That's going to make lots of people who develop non-mass marketed hardware very unhappy.
      ... or make them port thier non-mass market stuff to Linux.
  • by advocate_one (662832) on Friday December 15, 2006 @02:09PM (#17259374)
    if this thing is done in the BIOS? will it make it extra hard to do duel boot?
  • band-aid (Score:3, Insightful)

    by bcrowell (177657) on Friday December 15, 2006 @02:09PM (#17259382) Homepage

    If there are buffer overflows, isn't the solution to fix the buffer overflows?

    I keep hearing about stuff people do on Windows to avoid viruses, and it all seems predicated on the assumption that every Windows machine is going to get infected, so then you have to mitigate the damage. For instance, I've heard people say that even if you have a Windows box sitting on your desk at home, you should make a habit of logging off when you're not using it, because that way if yout box gets owned and starts sending out penis enlargement spam, the amount of spam being sent out will be reduced.

    Shouldn't the idea be to keep your machine from having hostile code run on it at all?? All this kind of stuff seems like telling people to go ahead having unsafe sex, but then take vitamin C afterward to help boost their immune system and reduce the harm done by the HIV virus.

    Heck, if I found out my Linux box had been owned, my reaction would probably be to wipe the hard disk, reinstall Ubuntu, and restore all my user files from backup. I don't have the expertise that would be needed to do forensics on the machine once it's been compromised.

    Antivirus software seems like the same kind of deal. Why do I want a resource-hogging process running all the time on my machine to scan the disk and memory for viruses? By then it's too late. At my school, I have some web stuff I want my students to be able to use, but it requires modern CSS support, so I requested that the Windows machines in the student labs be upgraded to IE7. The response that came back was that they weren't ready to support IE7 yet, because it didn't work with their AV software. WTF?? IE7 is a high-priority security update that is supposed to happen by default. Where is the logic of refusing to do security updates that would keep your machine from being infected, so that you can run the software that would detect the infection?

    • by Jerf (17166)
      If there are buffer overflows, isn't the solution to fix the buffer overflows?
      Well, sure, but defense in depth is a good thing.
    • Re:band-aid (Score:5, Insightful)

      by Aadain2001 (684036) on Friday December 15, 2006 @02:42PM (#17259912) Journal
      If there are buffer overflows, isn't the solution to fix the buffer overflows?

      Well sure it is! But MS doesn't control all the source code of the software the OS runs (but they're working on that ;)). Even if the OS is free of buffer overruns (which is should be after 5+ years of development), if a poorly implemented yet popular program (such as an IM client) still has buffer overruns, there is only so much that the OS can do/not do.

      • True. You can't keep poor developers from introducing overflows in their own code... but you can prevent a poorly written IM client from allowing an attacker to root the entire machine. The problem has never been buffer overflows, it's what you can do to the operating system with an unprivileged process.
    • Re: (Score:3, Insightful)

      by pkulak (815640)
      What you're saying is correct, but it's often a good idea to do both at the same time. You could say the same thing about firewalls. I'm nearly 100% sure that I've got my Linux box locked up tight, but I still appreciate knowing that it's behind a router with only 2 ports open.

      Of course, my router doesn't slow down my machine, introduce its own bugs, annoy me for updates, waste space and resources, etc...
    • Of course it's better to fix the buffers, that's my job now, before that I used to board up windows to keep the brain eating zombies out; seriously they only have to miss one and you'd be rooted. Defense in depth is the ticket, but I suspect that M$ skips bounds checking to improve performance where the buffer shouldn't be overflowable and see what we get.
    • If there are buffer overflows, isn't the solution to fix the buffer overflows?

      No. The solution is to make them trivial. If there's a buffer overflow, it should result in your machine crashing once in a while; THEN someone should fix it. This way you don't just silently get loaded with spyware and worms for 9 months until someone notices odd network traffic and starts analyzing the worm's behavior; it's immediately apparent that the whole system just shit itself because LSASS.exe died.

  • ...what then?

    Oh, wait, I forgot, this is the new millennium. There is no such thing as property. We own almost nothing. We rent almost everything as a service.

    The very few things we own are only there for the purpose of supporting things we rent (playing music we've rented, watching videos we've rented, running an OS we're rented) and are only expected to last a couple of years.
  • by Animats (122034) on Friday December 15, 2006 @02:25PM (#17259654) Homepage

    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? This will make many kernel bugs nonrepeatable, and improve Microsoft's defect deniability. That's its main advantage to Microsoft.

    Meanwhile, hostile code can just take over the interrupt locations, which can't move. Attacks will have to do more of the operating systems's work, like that attack which installs a virtual machine under the operating system. There are other approaches, such as simply taking over the whole machine and running something else, like a mini-OS equipped with a spam engine. Eventually someone may notice and power cycle the machine, but night attacks could get whole zombie farms going. While the attacker has control of the machine, they can make changes to the disk, too, so that after the reboot some of their stuff remains for next time. There's also a potential attack on the network controller which could leave the machine wide open for future takeover.

    Note the effect. This doesn't make attacks harder. It makes attacks which leave Windows running harder.

    Earth to Microsoft: if an attack can get into kernel mode, it's succeeded.

    • 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.
      • Re: (Score:2, Informative)

        by flynn_nrg (266463)
        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 dadragon (177695)
          Actually, init [openbsd.org] (and only init) can lower the secure level. Try typing:

          $ kill -s TERM 1

          as root some time. It will lower securelevel and drop into single user mode. Securelevel will rise again once in multiuser.

      • Doesn't Red Hat/SELinux have some sort of signed kernel module check?
      • When did OpenBSD start with randomization? I know PaX got NX on i386 in late 2000, added an NX policy back then, and ASLR in 2001; OpenBSD and RedHat both got an emulated NX bit in May of 2003, but no NX policy yet (a PaX fan added a few SELinux policy elements that let you get PaX's NX policy on RHAT though). I don't know when the last two got their randomization.
  • So what sorts of things can we expect to break due to this, and can we disable it if we want too?
  • Is it just a coincidence that the two sound similar?
  • I'm not sure I understand all of the details here - but I presume (please correct me if I'm wrong) that shuffling code around will tend to randomise the nature of memory corruption bugs in software.

    For example, an array off-by-one overflow error might benignly overwrite an unused RAM location during debug - but one time in a hundred the random shuffle could cause it to screw up something important. This would make software stability generally worse - and unreproducable bugs would be much, much harder to fi
    • Well, hopefully you're not allocating arrays in your code segment. Generally if you're overwriting anywhere near where your code lives thats a bad thing.
      • Who said anything about allocating? Ever see a programmer dereference some data pulled off the network as an address? (Hell, maybe it was an address on the server side...) How about dereferencing a null pointer as an array with a suitably high index? Or clobbering your stack with a buffer overflow, and then dereferencing what used to be a perfectly valid pointer? Overwriting data by accident is a bad thing even if it is nowhere near your code segment, but bugs happen, and there are plenty of bad programmers
  • Stopping trying to own everything desktop-related would probably be a cheaper and more reliable alternative.
  • Wow, a good idea that even Microsoft is willing to implement. What's the catch? Does the PRNG always return 0? Oh wait, I bet I know: it sometimes randomly uses address ranges that overlap with already-allocated memory?

  • 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?

    Melissa

HELP!!!! I'm being held prisoner in /usr/games/lib!

Working...