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?
ALSR?
34/en/m/c
-Dave
Isn't this the same as Linux virtual address randomization that works without BIOS?
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.
It's pretty obvious what it's talking about. It talks about security countermeasures in you inbox. That's obviously viruses and trojans. Thus the squatting Sume Wrestler is taking a crap directly into your inbox if you use MS. The imagery is a little over the top, but it presents the facts quite well.
Stop Global Warming!
Just say no to irreversible processes!
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.
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 [mastropaolo.com] entirely.
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.
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
You must be new here. this is Slashdot. Hes never gotten a PEEK at anything before let alone got to POKE it.
Even the nerd chicks don't think memorizing memory address ranges is cool.
Reality must take precedence over public relations, for nature cannot be fooled.
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.
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.
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
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.
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 do know that the people in Microsoft work in parallel not serial.
They don't work on one thing at a time, so quit yer bitching.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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.
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.
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.
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