Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

ALSR in Vista Gets OEM Push

Zonk posted more than 7 years ago | from the at-leas-they're-trying dept.

Security 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."

Sorry! There are no comments related to the filter you selected.

grsec (2, Interesting)

Jon Howard (247978) | more than 7 years ago | (#17258864)

Didn't grsec implement something like this ages ago?

Re:grsec (4, Informative)

oojah (113006) | more than 7 years ago | (#17259102)

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 (4, Insightful)

defile (1059) | more than 7 years ago | (#17260056)

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:grsec (1)

Jon Howard (247978) | more than 7 years ago | (#17260304)

Cool, thanks for the reminder. That's the one I was thinking of, alright.

what about the other 1/3rd? (1)

nutznboltz2003 (832752) | more than 7 years ago | (#17258894)

The memory-space randomization technique will block the majority of buffer overflow tricks used in about two-thirds of all worm and virus attacks.

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?

Re:what about the other 1/3rd? (0)

Anonymous Coward | more than 7 years ago | (#17259470)

buffer overflows are the most heavily used method of exploiting an operating system. Windows, Linux and OS X are all vunerable. This is a great move from MS.

Google it and you find that writing a buffer overflow exploit is not all that difficult. (or at least 6 years ago it wasn't)

Re:what about the other 1/3rd? (1)

ThatsNotFunny (775189) | more than 7 years ago | (#17259514)

You've got it backwards. The tricks are used in 2/3ds of the attacks, not that it will stop only 2/3ds of the attacks that use the trick.

Re:what about the other 1/3rd? (2, Interesting)

DrSkwid (118965) | more than 7 years ago | (#17260232)

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.

Re:what about the other 1/3rd? (1)

Tim C (15259) | more than 7 years ago | (#17261624)

More to the point, 9 women can't have a baby in 1 month; throwing more people at a task doesn't necessarily make it go any faster.

I feel dumb. (4, Funny)

bigdavex (155746) | more than 7 years ago | (#17258896)

ALSR?

34/en/m/c

Re:I feel dumb. (2, Funny)

clydemaxwell (935315) | more than 7 years ago | (#17260172)

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.

Re:I feel dumb. (1)

bigdavex (155746) | more than 7 years ago | (#17261006)

I was thinking race.

I'm not sure why L became language instead of location.

Re:I feel dumb. (1)

chad.koehler (859648) | more than 7 years ago | (#17261280)

This is slashdot, we all know your sex.

Re:I feel dumb. (1)

mkw87 (860289) | more than 7 years ago | (#17261656)

Oh, I thought R stood for rank and couldn't figure out what that translated to.

Re:I feel dumb. (0)

Anonymous Coward | more than 7 years ago | (#17261738)

ALSR?

34/en/m/c

Ok, I get part of if:
34 = age
en = english
m = male (i think)
c = ???
What in the hell is "c"

I call BS (-1, Troll)

Orange Crush (934731) | more than 7 years ago | (#17258904)

The memory-space randomization technique will block the majority of buffer overflow tricks used in about two-thirds of all worm and virus attacks.

Hogwash! The real reason MS wants this is to keep things like FairUse4WMV from reading encryption keys to strip off the DRM.

Re:I call BS (2, Informative)

interiot (50685) | more than 7 years ago | (#17259008)

This article [softpedia.com] 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.

Re:I call BS (0)

Anonymous Coward | more than 7 years ago | (#17259040)

MS also wants to start using gets() again.

Not quite! (5, Insightful)

Anonymous Coward | more than 7 years ago | (#17259042)

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.

Re:I call BS (2, Insightful)

Anonymous Coward | more than 7 years ago | (#17259184)

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

Re:I call BS (1)

st1d (218383) | more than 7 years ago | (#17259932)

Which means the result will be a little of both, and utterly worthless in the long run, right? :)

BS on your BS (5, Informative)

Mr 44 (180750) | more than 7 years ago | (#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: http://www.windowsecurity.com/articles/Analysis_of _Buffer_Overflow_Attacks.html [windowsecurity.com]

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 (1)

Orange Crush (934731) | more than 7 years ago | (#17259644)

I'm no programmer, but I had figured that FairUse4WM worked by cracking the blackbox file into plaintext by finding the encryption key securing it in memory when Media Player was running. I was going on the discussions I read over at Doom9 when MS released their lightning-quick response patch which merely changed the address used. It sounded like the FairUse author countered this by just adjusting to the new address.

Re:BS on your BS (3, Informative)

Mr 44 (180750) | more than 7 years ago | (#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.

Re:BS on your BS (0)

Anonymous Coward | more than 7 years ago | (#17261180)

I wonder if they left the application descripter at 0x10000.

Re:I call BS (1)

russotto (537200) | more than 7 years ago | (#17260072)

Hogwash! The real reason MS wants this is to keep things like FairUse4WMV from reading encryption keys to strip off the DRM.
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 untrusted (by them, not by you) programs from accessing trusted program's address space to stop that sort of attack.

can it be disabled during development? (1)

mcouper (128103) | more than 7 years ago | (#17258916)

I can just imagine the headaches of having to track down memory related issues if their locations are now going to be 'scrambled'.

Re:can it be disabled during development? (4, Informative)

Anonymous Coward | more than 7 years ago | (#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 [mastropaolo.com] [mastropaolo.com] entirely.

Re:can it be disabled during development? (1)

ifrag (984323) | more than 7 years ago | (#17259828)

My guess is you'll have the option to turn it off via complier options. Probably default off on debug builds and default on for release builds.

Re:can it be disabled during development? (1)

ifrag (984323) | more than 7 years ago | (#17259864)

Err... I just realized what I wrote makes no sense... This is OS level stuff not application level.

Re:can it be disabled during development? (1)

badboy_tw2002 (524611) | more than 7 years ago | (#17261798)

Given that its an option in the control panel and the bios, and that OEMs had to do something to turn it on, and thus implying that its an on/off switch, the only rational conclusion that one could make is of course...

NO.

Linux virtual address randomization (2, Interesting)

Anonymous Coward | more than 7 years ago | (#17258922)

Isn't this the same as Linux virtual address randomization [techtarget.com] that works without BIOS?

Re:Linux virtual address randomization (5, Informative)

Rosyna (80334) | more than 7 years ago | (#17259086)

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.

Re:Linux virtual address randomization (1)

hjf (703092) | more than 7 years ago | (#17259192)

Yes, but if it has problems, it's the BIOS manufacturer's fault, not Microsoft's. That's outsorcing taken to the extreme!

Mixed news (1)

inviolet (797804) | more than 7 years ago | (#17258938)

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:Mixed news (1)

lysdexia (897) | more than 7 years ago | (#17259064)

... if you start talking about using POKE without a manual we're leaving. Seriously.

Re:Mixed news (3, Funny)

gsn (989808) | more than 7 years ago | (#17259204)

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.

It may not be cool... (1)

jd (1658) | more than 7 years ago | (#17259568)

...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.

Re:Mixed news (2, Funny)

wiggles (30088) | more than 7 years ago | (#17259242)

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.

Re:Mixed news (1)

idontgno (624372) | more than 7 years ago | (#17259350)

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.

SKREEEEEEEEEE! (0, Offtopic)

lysdexia (897) | more than 7 years ago | (#17258940)

What is up with the Pooping Sumo Wrestler [atdmt.com] in the ad next to the article?

*brrrr*

Re:SKREEEEEEEEEE! (2, Funny)

Chosen Reject (842143) | more than 7 years ago | (#17259018)

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.

Re:SKREEEEEEEEEE! (1)

lysdexia (897) | more than 7 years ago | (#17259144)

Thanks for giving me the straight poop on my inbox. I wonder if he tosses quicklime or salt into your junk folder before entering?

Ok, class: let's determine the effectivity of this (1, Insightful)

postbigbang (761081) | more than 7 years ago | (#17258968)

There are supposedly 256 possible randomizations.

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; /*next spank

This is goofy at best, and tragically hilarious and useless at worst.

Re:Ok, class: let's determine the effectivity of t (2, Insightful)

lseltzer (311306) | more than 7 years ago | (#17259088)

You can't just loop through it like that. Every failure crashes the app. It will be obvious that something is wrong.

It depends entirely on how you probe (3, Interesting)

postbigbang (761081) | more than 7 years ago | (#17259224)

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.

Re:It depends entirely on how you probe (1)

julesh (229690) | more than 7 years ago | (#17261970)

You do memory reads and code string matches to determine where modules are loaded

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 successful.

Structured Exception Handling? (1)

mypalmike (454265) | more than 7 years ago | (#17259528)

> Every failure crashes the app.

Doesn't Win32 allow you to catch STATUS_ACCESS_VIOLATION using SEH?

Re:Ok, class: let's determine the effectivity of t (1)

MadMidnightBomber (894759) | more than 7 years ago | (#17261794)

... even on Windows :p

Re:Ok, class: let's determine the effectivity of t (1)

AP2k (991160) | more than 7 years ago | (#17259132)

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.

It might be that heuristics and Vista (1)

postbigbang (761081) | more than 7 years ago | (#17259264)

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).

Re:Ok, class: let's determine the effectivity of t (2, Insightful)

Aladrin (926209) | more than 7 years ago | (#17259254)

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.

Oh, gosh (1)

postbigbang (761081) | more than 7 years ago | (#17259400)

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.

Re:Ok, class: let's determine the effectivity of t (1)

interiot (50685) | more than 7 years ago | (#17259366)

Surely it's at least partially useful... Wikipedia mentions [wikipedia.org] 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.

This is good news (4, Funny)

ENOENT (25325) | more than 7 years ago | (#17259046)

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.

Re:This is good news (4, Funny)

truthsearch (249536) | more than 7 years ago | (#17259306)

Microsoft does sell their own mouse.......

Re:This is good news (1)

Red Flayer (890720) | more than 7 years ago | (#17259850)

I would submit that burns work as well as shock, maybe MS could put Sony batteries in their wireless mice?

Re:This is good news (1)

DLG (14172) | more than 7 years ago | (#17260914)

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!

Re:This is good news (1)

ENOENT (25325) | more than 7 years ago | (#17260978)

One problem: I believe that the BOFH has prior art, and is willing to use it.

Re:This is good news (1)

speculatrix (678524) | more than 7 years ago | (#17260952)

go look up the spoof RFC for "simple lart transfer protocol". well worth reading.

Re:This is good news (1)

SL Baur (19540) | more than 7 years ago | (#17260982)

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.

now rebooting Windows might actually help (1)

mkcmkc (197982) | more than 7 years ago | (#17259048)

On the flipside, this "diversity" will increase the incidence of intermittent bugs. But hey, with Windows, who'll notice the difference anyway?

NX (5, Funny)

ThurstonMoore (605470) | more than 7 years ago | (#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.

Re:NX (0)

Anonymous Coward | more than 7 years ago | (#17261546)

That isn't DEP's fault, it is just a sign that your 500GB porn drive is out of space.

Re:NX (1)

julesh (229690) | more than 7 years ago | (#17261944)

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...

Why does this need to be in the BIOS anyway? (1)

Viol8 (599362) | more than 7 years ago | (#17259200)

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?

PC Architecture... (1)

StupidMBA (1039062) | more than 7 years ago | (#17259332)

You know I was thinking along similar lines of "W(hy)TF are we still beholden to hardware architecture from the early 80s? And hardware architecture that, IIRC, was a hack by one of IBM's engineers?"

So, I agree with you.

"the majority" ... "used in about two-thirds" (1)

BadERA (107121) | more than 7 years ago | (#17259262)

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

From the article... (1)

wiredog (43288) | more than 7 years ago | (#17259322)

"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/subvert the client end. Then it's going to be utter hell.

Re:From the article... (1)

PhrostyMcByte (589271) | more than 7 years ago | (#17259590)

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.

Re:From the article... (1)

b0s0z0ku (752509) | more than 7 years ago | (#17259852)

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 essentially need a license to develop kernel-mode software for Vista galls me.


-b.

Re:From the article... (1)

Evangelion (2145) | more than 7 years ago | (#17259624)


"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.

so how will this affect installing Linux? (3, Interesting)

advocate_one (662832) | more than 7 years ago | (#17259374)

if this thing is done in the BIOS? will it make it extra hard to do duel boot?

Re:so how will this affect installing Linux? (1)

Red Flayer (890720) | more than 7 years ago | (#17259906)

will it make it extra hard to do duel boot?
Duel boot?

Maybe you're looking for this? [waynesbooks.com]

Pistols at noon.

Re:so how will this affect installing Linux? (4, Funny)

Lord Ender (156273) | more than 7 years ago | (#17260178)

Duel boot?

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*

band-aid (2, Insightful)

bcrowell (177657) | more than 7 years ago | (#17259382)

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:band-aid (0)

Anonymous Coward | more than 7 years ago | (#17259618)

IE7 is a high-priority security update that is supposed to happen by default. Calling IE7 a "security update" is like calling Chernobyl "an improved application of nuclear energy."

Re:band-aid (1)

Jerf (17166) | more than 7 years ago | (#17259652)

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 (1)

bcrowell (177657) | more than 7 years ago | (#17259804)

Well, sure, but defense in depth is a good thing.
Agreed, but all these second-tier defenses tend to have negative effects as well. AV software hogs resources. Randomizing the locations at which modules are loaded into memory makes it impossible to do certain types of optimization to speed up booting. It's a hassle to log off of your Windows machine at home when you make a run to the store for a loaf of bread.

Re:band-aid (1)

tokul (682258) | more than 7 years ago | (#17259790)

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?
Windows Genuine Advantage Notification was high priority update too. Are you sure that IE7 is security fix and not some unstable new thing convicted monopolist wants to push to end users?

Re:band-aid (1)

Shados (741919) | more than 7 years ago | (#17260452)

Are you sure that IE7 is security fix and not some unstable new thing convicted monopolist wants to push to end users?


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 :)

Re:band-aid (4, Insightful)

Aadain2001 (684036) | more than 7 years ago | (#17259912)

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.

Re:band-aid (3, Insightful)

pkulak (815640) | more than 7 years ago | (#17260208)

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...

Say you manually verify that DEP ISN'T enabled... (1)

dpbsmith (263124) | more than 7 years ago | (#17259444)

...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.

New challenge for AntiVirus software. (0)

Anonymous Coward | more than 7 years ago | (#17259482)

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?

how nice they are... (1)

towsonu2003 (928663) | more than 7 years ago | (#17259604)

How nice those OEMs are to Microsoft, right? In the meantime, I will keep doing all sorts of clowning and turning somersaults just to make my wireless and my winmodem work in Linux.

Don't you love how market forces work for the good of the consumer ;)


ay, here goes my karma again...

Application to servers? (0)

Anonymous Coward | more than 7 years ago | (#17259608)

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

Re:Application to servers? (1)

TheAwfulTruth (325623) | more than 7 years ago | (#17261392)

It helps prevent it because every one of the 50 million windows servers out there will have different memory layouts, even if they are never rebooted. They are booted at least ONCE with a ramdom layout. That stops wide spread attacks /of this sort/ dead.

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 too? It's a Good Thing[tm]

What a pathetic approach to security (2, Insightful)

Animats (122034) | more than 7 years ago | (#17259654)

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 (3, Informative)

salimma (115327) | more than 7 years ago | (#17260064)

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:What a pathetic approach to security (2, Informative)

flynn_nrg (266463) | more than 7 years ago | (#17262002)

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.

Is still monoculture, and is defense in deep. (1)

Tei (520358) | more than 7 years ago | (#17259704)

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!

Change of plans! (1)

monkeyboythom (796957) | more than 7 years ago | (#17259954)

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.

The memory-space randomization technique will block the majority of buffer overflow tricks used in about two-thirds of all worm and virus attacks."

Not on my new Toshiba.... (0)

Anonymous Coward | more than 7 years ago | (#17260136)

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

Compatiblity? (1)

nurb432 (527695) | more than 7 years ago | (#17260258)

So what sorts of things can we expect to break due to this, and can we disable it if we want too?

ALSR, Ulcer, coincidence? (1)

r_jensen11 (598210) | more than 7 years ago | (#17260688)

Is it just a coincidence that the two sound similar?

Security through Obscurity (1)

zmod3m (996289) | more than 7 years ago | (#17260906)

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.

Re:Security through Obscurity (1)

TheAwfulTruth (325623) | more than 7 years ago | (#17261290)

Is that the same reason that Linux has implementations of it too?

Gonna make debugging & bug reporting a bitch! (1)

sbaker (47485) | more than 7 years ago | (#17261070)

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.

Re:Gonna make debugging & bug reporting a bitc (1)

badboy_tw2002 (524611) | more than 7 years ago | (#17261920)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?