Slashdot Mirror
ALSR in Vista Gets OEM Push
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."
Didn't grsec implement something like this ages ago?
Ok, so two-thirds of the tricks used in worms and virus buffer overflor attacks are negated, but are those two-thirds heavily used attacks, or very minor ones?
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?
ALSR?
34/en/m/c
-Dave
I can just imagine the headaches of having to track down memory related issues if their locations are now going to be 'scrambled'.
Isn't this the same as Linux virtual address randomization that works without BIOS?
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.
FATMOUSE + YOU = FATMOUSE
What is up with the Pooping Sumo Wrestler in the ad next to the article?
*brrrr*
There are supposedly 256 possible randomizations.
/*next spank
Old code:
poke (scriptylittlecode) to this address (usual kernel location, but we might check other modules with probes)
New code:
while not successful()
for i=1 to 254
spank (module old code with randomized address prediction)
next i;
This is goofy at best, and tragically hilarious and useless at worst.
---- Teach Peace. It's Cheaper Than War.
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.
MS also wants to start using gets() again.
This is a legitimate technique already used by some other high-security OSes (e.g. Open BSD). So it's a legitimately good security measure.
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.
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 "Mr. Soulless Automaton" to you, Bub.
On the flipside, this "diversity" will increase the incidence of intermittent bugs. But hey, with Windows, who'll notice the difference anyway?
"Not an actor, but he plays one on TV."
You can't just loop through it like that. Every failure crashes the app. It will be obvious that something is wrong.
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.
Hopefully any heuristic analysis can catch these exploits before they hit the right address. I'm still in no hurry to switch over to Vista though.
Theory:
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
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?
You do memory reads and code string matches to determine where modules are loaded, the poke your favorite malware where it needs to go. The signature only is corrupted when the module loads, so you need to write out the corrupted module and change its signature. So, it's not as tough as you're implying at all. Try it sometime. It's great for party jokes.
---- Teach Peace. It's Cheaper Than War.
Everything the previous replies said, plus you missed 2 of the random spots ;)
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 on all old system, and users will likely disable it on new systems because it causes errors with some game they play.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
"the majority" ... "used in about two-thirds" ... forgive my ignorance, but do worm attacks typically use multiple buffer overruns to do their dirty deeds, or is this simply poorly written?
I am, therefore you think.
are an oxymoron.
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).
---- Teach Peace. It's Cheaper Than War.
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/subvert the client end. Then it's going to be utter hell.
Best Slashdot Co
So, I agree with you.
Don't mod me down: I was joking!
Surely it's at least partially useful... Wikipedia mentions that it's enabled by default on OpenBSD, and that there are a number of add-ons available for Linux that lets you enable it there.
if this thing is done in the BIOS? will it make it extra hard to do duel boot?
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
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?
Find free books.
In what way does this prevent FairUse4WM?
f _Buffer_Overflow_Attacks.html
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.
See, you always probe a default position first, and the last one is what remains and must be true because all of the rest of the smacks didn't work.
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.
---- Teach Peace. It's Cheaper Than War.
...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.
"How to Do Nothing," kids activities, back in print!
What if the virus/spyware developers use this technology to provent their malware from detected by AntiVirus software. Is there a method available at all to identify applications with randomized image?
> Every failure crashes the app.
Doesn't Win32 allow you to catch STATUS_ACCESS_VIOLATION using SEH?
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
...but the power-on self-test for the Commodore PET 3032 was at location 65520, as I recall. What always seemed odd to me was that a machine that had an OS entirely in ROM and a software reboot would actually crash more than a third of the time when running the reboot.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Don't you love how market forces work for the good of the consumer ;)
ay, here goes my karma again...
It's been a while since I've studied this in college, but wouldn't this make little difference to a server, since they are rebooted less frequently than a regular desktop/terminal? According to another post of his (http://blogs.msdn.com/michael_howard/archive/2006 /05/26/address-space-layout-randomization-in-windo ws-vista.aspx) it sounds like this only occurs when the machine is rebooted. Plus, if my memory still serves me correctly, isn't the whole goal of some buffer overflow attacks to crash/terminate an application, since that way they know they've "hit a nerve"?
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.
You still use one and only one way to do things. So It still is monoculture. You can describe this as a "defense in deep", not as a solution, or a real safe protection. Anyway: Wellcome!
-Woof woof woof!
Which means the result will be a little of both, and utterly worthless in the long run, right? :)
Microsoft has just released their much anticipated hands-free cordless mouse. Warning, it may hurt a little at first.
Thanks! So instead of reading up on all the memory address allocs for Vista, all I have to do is study NX because once I crack that I no longer care about separate applications. I could destroy the whole table or get it to "randomize" a specific app to allocate at a specific address.
Of course this is only for the newest machines that will have the BIOS update. The older ones still use the old plans.
I find this interesting because on my brand new A105-S4334 Toshiba with a Core 2 T5500, Execute Disable is disabled and they've removed the BIOS level option to enable it, this on a laptop that is marked "Vista Capable". Toshiba has had an option in Satellites for a while now to Enabled XD (or NX as AMD calls it, or DEP as MS calls it) with the default being disabled. However, on this newer model, it's disabled and no setting exists. We're a Toshiba ASP so we have a high level fix request waiting an answer now but the tech told me that *all* their doing now is testing for Vista, hope someone over there reads this one...
Jay
So what sorts of things can we expect to break due to this, and can we disable it if we want too?
---- Booth was a patriot ----
Is it just a coincidence that the two sound similar?
Isn't this just more of Microsoft's typical 'Security through Obscurity' TM. They cant fix the problems so they will just hide them in different parts of the memory.
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 find than reproducible ones.
Of course ideally we want software that has no bugs - but for software of any size, that just ain't gonna happen. It'll be interesting to see whether the benfits of helping insecure software avoid letting the bad guys in outweigh the penalty of making somewhat buggy software less reliable.
www.sjbaker.org
... even on Windows :p
"It doesn't cost enough, and it makes too much sense."
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.
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.
Find something that can blow up to root, feed it the pill, and watch it get sick.
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.
---- Teach Peace. It's Cheaper Than War.
Stopping trying to own everything desktop-related would probably be a cheaper and more reliable alternative.
Yeah, and so what? Never been an issue for most users, they just think; "oh its microsoft" restarts the application and you get your next try.
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.
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.
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?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
So long as they allow one process to spawn a thread in another, you can read process memory. The Cell processor has some hardware tricks to try and keep that from happening, involving a combination of signed code and some special calls in one of the CPEs, combined with access restrictions on the memory areas accessed by thet CPE. x86 doesn't have the capability to do that - and both VMWare and checked builds allow you full access to the process memory.
That's a barn door you can not close on x86 or x86-64. At all.
Why can't I mod "-1 Idiot"?
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.
Support my political activism on Patreon.
It wouldn't be too much harder to simply locate the thing you want, instead of doing it like you did, I'm sure
...but I feel like I can just spout random crap about it anyway
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 additional processor/memory speed
No additional memory, and only an increase in the time it takes when first loading a DLL (such as on boot). Once the DLL's loaded, accesses don't change.
be disabled on all old system
I can't speak to this, so I won't say anything.
and users will likely disable it on new systems because it causes errors with some game they play.
I guess theoretically possible, but to break because of ASLR the game would have to be doing something extremely non-kosher like using hard coded addresses. And since those addresses can change from version-to-version (or even just patch-to-patch), the chance that it'd run under Vista w/o ASLR is extraordinarily slim.
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!
Registering accounts later than some other chrisb since 1997
"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."
The whole point of this is to help prevent the compromise in the first place. Nobody is perfect, and there is no way to make sure that all software is 100% bug free. So using techniques to help prevent exploitation of bugs when they are found is a good thing.
OpenBSD and linux both support this as well. Just because microsoft does something, doesn't mean its a bad thing.
"The OS vendor is so inept that they can't keep hostile code from changing kernel data space"
This has nothing to do with the kernel at all.
"This will make many kernel bugs nonrepeatable, and improve Microsoft's defect deniability"
No, it will make exploiting the bugs require you to correctly guess where the library is loaded in memory. The bugs don't change.
"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."
This is to prevent successful exploitation of bugs in software. It has nothing to do with preventing rootkits or other nastiness from being installed after your machine is already compromised.
"Note the effect. This doesn't make attacks harder. It makes attacks which leave Windows running harder."
Yes it does make (certain) attacks harder. You have to guess the address correctly. Typically, if you guess wrong it will crash the software instead of exploiting it.
"Earth to Microsoft: if an attack can get into kernel mode, it's succeeded."
Earth to Animats: if you have no idea what you are talking about, don't pretend you do.
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 out there.
I think a better answer to the parent is that you can turn this stuff off while you are debugging.
Lots of OS-level things are controlled by flags in the headers of executables.
I mean really WTF?
If the processor supports the feature, it should be available to the OS.
If the OS also supports the feature, it should be available to the apps.
For apps that are unaware of the feature, the OS should let the user decide.
Does the BIOS actually make the CPUID instruction lie about the feature?
(allowing the BIOS to hide the feature from the OS) If so, is it merely
hidden or actually disabled? In other words, could the OS just use the
feature despite whatever the CPUID reports? Does the BIOS instead make
the feature non-functional?
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
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
that sounds like a really, really, really good idea but so was blue screening whenever any program tried to read from memory that was in the operating system section of the memory. I guess if hackers found away around it then it doesn't work so well. Why didn't they fix that problem? It's like building a new car because your other one is broken.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
They can disagree all they want. Until it's been PROVEN to be effective, I won't believe it. Some of the hacks to 'train' xbox games were amazing. I even used the 'code cave' technique myself a couple times, and that's considered nearly child's-play compared to some of the hacks they did.
I meant memory speed, as in bandwidth. Not actual memory space. But even after boot, there's some processing needed to find the newly located code. If there wasn't, you could simply look up the location in the OTHER part of memory and BAM, hack time. To run tricks like that, they need to process.
It'll be disabled on all old systems because it either doesn't exist, or was shipped disabled. RTFA. It says so. No need to even argue it.
As for game errors... You have obviously never bothered to look into game programming. Some of the tricks they pull to gain speed are amazing. And absolutely reliant on the architecture. They use glitches to improve performance, and count on them. The oldest example of this was when games were programmed to use the system bus speed to time the game. Faster computers can't run these games without software that slows it down. Any other example is quite a bit more complex.
Still think I'm spouting crap randomly? I didn't have to look any of this information up because I've been dealing with it for so long. This new tech doesn't sound like it'll be worth researching. If it turns out to be a big thing, THEN I can be bothered. I'm still pretty sure it'll flop, and not going to waste my time.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
Until people start actually using the segmentation and privilege ring facilities on the x86 processors, this will still be circumventable. I think that the segmentation stuff et al is as silly as most other people who have done stuff with the x86, but there actually is some rationale behind it.
The real problem with segmentation et al, is that Unix doesn't map reasonably well to it, and there's this whole "lowest common denominator" thing (frequently labeled "portability", which is arguably a good thing in most cases).
As it is, as long as you can take over the running context, you can still scan for the code you are looking for, which will work until they start doing polymorphic code in the kernel. Which will work until someone (I assume only the real black hats will have the fortitude for this) writes up a code analyzer that will detect if the code does what you want it to. At that point, you'll need heartbeating and/or better CPU-level protection facilities.
If you want to be safe, limit your segment so that the program *cannot* access anything it isn't supposed to, set different page tables, use gates for control transfer, etc.
Prevention.
Detection.
Response.
Software without bugs happens. Regularly.
Specifications without bugs is a rare beast.
Have a look at companies like Lockheed-Martin.
for i=1 to 254
spank (module old code with randomized address prediction)
next i;
The goal is to prevent you from exploiting the machine by getting it run your code. If you have somehow gotten this "new code" running, then the game is already over.
I'd rather be lucky than good.