ALSR in Vista Gets OEM Push 170
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."
grsec (Score:2, Interesting)
Re:grsec (Score:5, Informative)
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)
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.
Re: (Score:2)
Re: (Score:3, Insightful)
Right, but that doesn't mean we shouldn't do it.
Cheers,
Roger
I feel dumb. (Score:5, Funny)
34/en/m/c
Re: (Score:2, Funny)
Re: (Score:2)
Re: (Score:2, Funny)
None?
Re: (Score:2, Funny)
Linux virtual address randomization (Score:2, Interesting)
Re:Linux virtual address randomization (Score:5, Informative)
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.
Mixed news (Score:2)
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)
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.
Re: (Score:2)
Re: (Score:2)
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. :)
Re:Mixed news (Score:4, Funny)
Even the nerd chicks don't think memorizing memory address ranges is cool.
It may not be cool... (Score:2)
This is good news (Score:5, Funny)
Re:This is good news (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
now rebooting Windows might actually help (Score:2)
Re: (Score:2)
NX (Score:5, Funny)
Re: (Score:2)
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...
Why does this need to be in the BIOS anyway? (Score:2)
Re: (Score:3, Informative)
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.
From the article... (Score:2)
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/
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
"Windows Vista also introduces
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.
so how will this affect installing Linux? (Score:4, Interesting)
Re: (Score:2)
Maybe you're looking for this? [waynesbooks.com]
Pistols at noon.
Re:so how will this affect installing Linux? (Score:5, Funny)
Linux: On-guard! This MBR is MINE!
Windows: *parry* *thrust* Never! The first 512B are the domain of NTLDR! Mu-ha-ha!
Linux: Touche! Looks like the boot CD will be needed to get GRUB back on here. *removes mask*
Re: (Score:2)
No.
band-aid (Score:3, Insightful)
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?
Re: (Score:2)
Re:band-aid (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:3, Insightful)
Of course, my router doesn't slow down my machine, introduce its own bugs, annoy me for updates, waste space and resources, etc...
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Considering IE7 is a major step in "undoing" the ties between the OS and the browser...I think its more an attempt at avoiding to be convicted AGAIN.
:)
Never noticed that if you have IE7 installed, and type a URL in windows' explorer, it will pop Firefox if its your default browser?
So i think that was a bad example
Say you manually verify that DEP ISN'T enabled... (Score:2)
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.
What a pathetic approach to security (Score:3, Insightful)
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.
Re:What a pathetic approach to security (Score:4, Informative)
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)
Re: (Score:2)
$ 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.
Re: (Score:2)
Re: (Score:2)
Compatiblity? (Score:2)
ALSR, Ulcer, coincidence? (Score:2)
Gonna make debugging & bug reporting a bitch! (Score:2)
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
Re:Gonna make debugging & bug reporting a bitc (Score:2)
Re:Gonna make debugging & bug reporting a bitc (Score:2)
Redmond's attempt to address the monoculture risk (Score:2)
What's the catch? (Score:2)
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?
Are DLLs no longer shared in memory? (Score:3, Informative)
Melissa
Re: (Score:3, Informative)
Re: (Score:2)
That article's talking crap. ASLR doesn't require DEP; it just isn't particularly useful at preventing buffer overrun attacks without it. If there were any programs that failed to work when run on the local system when ASLR was enabled, the lack of DEP would not prevent this.
Not quite! (Score:5, Insightful)
That said, I don't doubt that wanting to better secure their DRM is high on their list of reasons to improve security. That is, they probably want more to secure the machine *from* you than *for* you... While I've certainly had users that the system needed protection from, I still don't like what they're doing with DRM.
Soon, at this rate, you'll either have an unencumbered OS, or what you have won't be fit to call a computer. It'll probably look something more like a high definition TV with popup ads.
Re: (Score:2, Insightful)
Maybe they (Gasp, shock, swoon) have two different motivations at the same time, or there are at least two people working on it that both have either one or the other motivation
Shocking and mind-exploding, I know
Re: (Score:2)
Re: (Score:2)
Don't be daft! Next you'll be saying the whole company has degenerated into a series of disconnected fiefdoms that aren't all moving in the same direction [slashdot.org]!
BS on your BS (Score:5, Informative)
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: http://www.windowsecurity.com/articles/Analysis_o
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: (Score:2)
Re:BS on your BS (Score:4, Informative)
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.
Re: (Score:2)
That's a good (if paranoid) thought, but (and I probably shouldn't say this, because they might not have thought of it) it won't make an insurmountable difference for reading encryption keys. While brute-forcing the key space of an encryption algorithm may be infeasible, trying every possible "key" within the address space of a process isn't. Of course, MS will try to prevent untru
Re: (Score:2, Funny)
Re:can it be disabled during development? (Score:4, Informative)
Re: (Score:2)
NO.
Re: (Score:2)
Actually this makes it easier to find memory related issues. Often times a memory corruption bug will wind up corrupting some memory, allowing the program to run on for a little bit before it crashes; now you have a bug at X and a crash point at X+dX, you have to figure out what dX is. When the addresses are randomized, dX will change; importantly, sometimes the memory being corrupted just won't be there and your program will crash due to read from/write to unmapped memory. At this point your debugger t
Re:Ok, class: let's determine the effectivity of t (Score:3, Insightful)
It depends entirely on how you probe (Score:4, Interesting)
Re: (Score:2)
How do you do that when you don't have access to run code on the machine, but are only able to overwrite a stack return address with an address you've chosen?
Note that the address of your exploit code will likely have been randomised along with everything else. Or NX is enabled, and you've only got a return-to-libc attack available to you.
Those are the situations this scheme is designed to protect from, and it's pretty success
All it takes is a single exception at root (Score:2)
Users in Vista are presented with 100s of decisions about whether to install something. Someone will figure out how to forge something needed but not included (like MM flash), and slip the code a mickey the second the user makes an acknowledgement. It's proven.
Pretty successful? Others think naught.
Re: (Score:2)
So why, then, is it included in multiple BSD systems and SELinux?
Re: (Score:2)
If an SELinux (or other privilege-demoted) app tried to make exceptions, it can be successfully kept demoted, but will drive users crazy when their apps misbehave. In Windows Vista, about 50% of apps (or more) will misbehave, including a
Re: (Score:2)
In BSD or SELinux, the code base has always been of the kind where apps didn't often try to get root or a root authenticated app to do things with.
Say what ? Only a few short years ago pretty much ever single daemon on a typical unix system would have "required" running as root. Why do you think kludges like chroot exist ? Not to mention things like SUID...
Structured Exception Handling? (Score:2)
Doesn't Win32 allow you to catch STATUS_ACCESS_VIOLATION using SEH?
Re: (Score:2)
To make matters worse -- or better, depending on who you are -- when a system exception happens, the kernel goes into "uh oh something's wr
Re: (Score:2)
Re:Ok, class: let's determine the effectivity of t (Score:3, Insightful)
Randomly jamming things into memory locations is almost sure to crash the app. It wouldn't be too much harder to simply locate the thing you want, instead of doing it like you did, I'm sure. I believe the hardware bit is designed to stop you from locating the address as well, though...
I haven't bothered to research the tech because I think it will probably be mostly useless, take up additional processor/memory speed, be disabled
Oh, gosh (Score:2)
Yet there are any number of ways to compromise things. But I'm super-paranoid and only a bit of a hack, with origins in 8086/i386 machine code. Nothing is fool proof, because fools are so ingenious.
Re: (Score:2)
It is if the reason you're doing it in the first place is because you need a vulnerability to get your code running on the system, it's sorta hard to locate the thing you want until you've already done that.
I haven't bothered to research the tech...
it will probably be mostly useless
OpenBSD and the NSA [SELinux] disagree.
take up addition
Re:Ok, class: let's determine the effectivity of t (Score:2)
Re:Ok, class: let's determine the effectivity of t (Score:4, Informative)
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.
Re:Ok, class: let's determine the effectivity of t (Score:4, Informative)
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.
It might be that heuristics and Vista (Score:2)
Sorry, it's kind of a troll remark, but remember that modules are checked at load time; corrupt them in memory and make them do things is both an onerous and non-casual corruption. I won't say which modules are the leakiest, but look to the ones with lots of calls to hardware (hint) to do the job. It's not funny how easily this can be done-- especially if you then change a few key registry signature (next hint).
Re: (Score:3, Interesting)
They don't work on one thing at a time, so quit yer bitching.
Re: (Score:2)
Re: (Score:2)
There are two ways of exploiting a buffer overflow: you can make code in the buffer execute, or you can make code that already exists in the system execute with parameters from the buffer. The former is prevented by NX protection in most cases. The latter is made substantially more difficult by ASLR.
Re: (Score:2)
This is a nice step, but I'd like to see them be a little more active on the security front. How about patching some more of those released zero-day exploits for Word?
The trick is for these exploits to 'get into' the computer in the first place, which Vista makes far more challenging by 100x over previous versions of Windows.
In theory it should take a
Re: (Score:2)
Re: (Score:2)
Yes, there are many many MANY ways to attack a machine, this is just one, a hole being closed. BTW to all those people that are yapping about how this is some kind of unique MS shenanigans to patch a busted OS, you DO realize that Linux has this capability t
Re: (Score:2)
Market forces tend to work pretty well for the largest group of consumers. The rest of us suffer.