Defeating XP SP2 Heap Protection

hobo2k writes "XP SP2 included canary values and hardware-implemented execution protection in order to avoid exploitable buffer overruns. Now Positive Technologies has released an article describing one way that protection could be bypassed. To solve the problem, they provide a program which disables the small allocation heap as described here. CNET reports that SP2 has been foiled."

Comments

And this

[ScrewMaster]

surprises anyone?

Re:And this

[Anonymous Coward]

maybe Microsoft?

Re:And this

[Anonymous Coward]

I'm surprised it took this long...

Re:And this

[archen]

I'm surprised about the reporting that SP2 has been "foiled". SP2 is supposed to be a step to make xp more secure, not invincible. There's a lot more to SP2 than the heap protection.

Re:And this

[Anonymous Coward]

I'm shocked! I have been reading all these independent studies, and according to Forrester, Windows users have fewer vulnerabilities. Check it out yourself, if you don't believe!
http://www.microsoft.com/windowsserversy stem/facts /analyses/default.mspx#EHAA

It's a fact. So this vulnerability, and the dozen others I've been patching at the work, are just some kind of imagination. Or maybe Linux / BSD / OS X users have just amazing amounts of vulnerabilities (counted together, OS & apps).

I'm drunk. And it's not a surprise. Every hardcore Linux geek (like myself), who has to maintain Windows networks for living, have more drinking problems than those who are using solely operating systems and software which are free as speech (as opposed to beer).

Responsible for security of Windows network? Next recommendation for security enhancements: different operating systems, no more IE. If there are costs, then they're definitely worth it. Microsoft has proved that they don't care. All they care is money, monopoly and marketing (FUD / brainwashing / propaganda).

Re:And this

[camcloud1]

How can we be surprised...SP2 caused more problem than it fixed. But at least we have MS Longtime to look forward to ;)

Re:And this

[ScrewMaster]

Yeah. A bit sensationalist, I suppose. And SP2 did live up to the ideal of making Windows more secure, but the typical user mentality operates more in the realm of absolutes. "I want perfect security, and SP2 isn't perfect so therefore it's useless." Good security is a process, a continuing evolution, and that's true no matter what OS you use. Would I plug an XP SP2 box right into my cable modem? Not unless I was setting up a honeypot. But it is an improvement.

Re:And this

[t3hl33t]

You actually trust Microsoft to say that? Windows is one of the worst OSes in the world in terms of security. And everyone else can tell you that, you can trust it

Re:And this

[Anonymous Coward]

But at least we have MS Longtime to look forward to

Ooh! You're so clever!

Re:And this

[prodangle]

Windows is one of the worst OSes in the world in terms of security.

As far as I know, Windows is the only OS that actually makes use of hardware features to protect against buffer overflows. Although this has now been shown to be imperfect, it is still a layer of secure that most other operating systems (all?) do not have.

While it's common sense that situations exist where Windows is not the most secure option, baseless and overly broad statements like your's are very unhelpful.

Re:And this

[bob65]

I don't think that's typical user mentality. That's stupid people mentality.

Re:And this

[louarnkoz]

Code execution protection is one of the security features of XP/SP2. The design concept in XP/SP2 is to have a succession of protection layers, e.g. running the firewall to block ports, requiring authentications on RPC ports that are open, blocking some form of communications, etc. None of these protections is entirely foolproof: some ports will remain open, some passwords will be guessed, etc. But it is much harder for an attacker to breach several protections than just one.

The code execution protection is one of these protection layers, pretty much the last one when everything else has been breached and a buffer has overflown. It prevents the class of exploits that load code in a data buffer and somehow jump into it. But there is still a way through, using a stack overflow to rewrite a return pointer or a function pointer and direct it to an existing procedure, e.g. one in libc.

Protecting against such exploits is very hard, and the problem is by no means specific to Windows. Don't expect a quick fix.

Re:And this

[cnettel]

Isn't the point of the canary values even mentioned in the post to actually catch stack overruns? They are a far more expensive thing to do, but I was under the impression that they still are used quite extensively in SP2. Basically, if you put in a random value (varying between each function call, ideally, probably between each machine session or so in SP2) between the stack buffer and the return pointer, and that value is checked before RET is called, it gets much harder to overrun the buffer, beat the RET check and get the code to jump back to the wrong place.

Naturally, the only real solution is to avoid the overruns by sensible code. But, if one would be ready to believe that this level of checking would be enough to put native compiled code written by idiots on par with Java or .NET code written by idiots in the area of buffer overrun, it would be a cheap choice, performance-wise.

Re:And this

[Anonymous Luddite]

>> As far as I know, Windows is the only OS that actually makes use of hardware features to protect against buffer overflows.

It's nice that MS is even trying this, but really I think the onus is on the developer. It doesn't matter if were talking microsoft or not.

while((*(szShit++)=*(szHappens++))!='\0');

You can't make assumptions about the data you get passed...

Re:And this

[Anonymous Coward]

Right, there's also the security center... because clippy alone isn't annoying enough.

Re:And this

[SirTalon42]

Linux has used hardware features to protect against buffer overflows since LONG before sp2 came out. Linux also uses software protection to protect against buffer overflows (i.e. Execution-Shield).

Re:And this

[YU Nicks NE Way]

There are two different kinds of canaries, stack canaries and heap canaries. The heap canaries are the ones that this PoC claims to attack, which is relevant because heap overruns are much harder to exploit than stack overruns, not to mention less common.

Re:And this

[Anonymous Coward]

Protecting against such exploits is easy, all Microsoft has to do is fix buffer overrun holes instead of relying on SP2's stack protection to make them not exploitable. How many times have you seen an unpatched hole mentioned and people have said "but it is patched, SP2 is immune". This proves SP2 is not immune, you just need to use different shellcode. See David Litchfield's paper on defeating Windows Server 2003's protection for more information.

i know the drill

[numike]

firefox

Re:i know the drill

[freeJustin]

mayve you didnt read correctly this is a core issue, so to rephrase "I know the drill, *nix"

Re:i know the drill

[eomnimedia]

Actually:

Re:i know the drill

[Anonymous Coward]

Why is this modded funny? Microsft never thinks anything through enough to actually meet the goals they state. Firefox has and does!

Re:i know the drill

[Anonymous Coward]

People like you make it funny.

Re:i know the drill

[Anonymous Coward]

Funny. I got the joke. Why didn't you?

forst

[Anonymous Coward]

forst porsts.

Ha

[Anonymous Coward]

fr0st p1ss

EOTD

[Anonymous Coward]

Exploit Of The Day

i wonder if Nick McGrath is eating a nice hot plate of crow right about now...

Re:EOTD

[Anonymous Coward]

how dare you mod parent down as a troll you friggin WinTard...

You don't mean..?!

[Rosco P. Coltrane]

Now Positive Technologies has released an article describing one way that protection could be bypassed.

A security problem in Windows? no way...

SP2 what?

[warderz]

Protection? What protection?

Re:SP2 what?

[A beautiful mind]

it's like putting on a second condom AFTER sex when the first one proved to be leaking.

Re:SP2 what?

[ozbird]

To take the analogy further, does that make Linux the morning-after pill?

Re:SP2 what?

[NanoGator]

"it's like putting on a second condom AFTER sex when the first one proved to be leaking."

Oh....

Er.. could we use metaphors that most of us could wrap our minds around?

Re:SP2 what?

[Anonymous Coward]

It's like reaching for the tissue AFTER...

Re:SP2 what?

[NanoGator]

"It's like reaching for the tissue AFTER..."

Ooohhh!!!

Ooohhh....

Crap.

Re:SP2 what?

[Anonymous Coward]

yes but it also makes u better in bed from then on too

Re:SP2 what?

[Anonymous Coward]

> To take the analogy further, does that make Linux the morning-after pill?

More like an abortion. Atleast thats what the source often looks like.

Re:SP2 what?

[Aeiri]

No, it's more like abortion.

I guess dubya isn't going to switch to Linux now...

Re:SP2 what?

[glitch23]

Everyone knows the best way to stay safe is abstinence. Just don't use Windows at all. But if you have to do something, go for the ugly step child that no one knows about (she is younger anyway): Linux.

Re:SP2 what?

[Anonymous Coward]

> > it's like putting on a second condom AFTER sex when the first one proved to be leaking.

> To take the analogy further, does that make Linux the morning-after pill?

No. Linux is like masturbation. And BSD is like necrophilia.

Re:SP2 what?

[wxjones]

Actually, running Linux is like wearing a plaid hat with earflaps. Best birth control known to man! Come to think of it, its Saturday night and I'm posting on slashdot...using Linux. At least my ears are warm.

Re:SP2 what?

[SmittyTheBold]

Yeah, so sorry about the AIDS you already contracted.

Remember: the only safe computing is NO COMPUTING. If you feel like you have to use a computer, then staying off-line is the only sure way to stay disease-free. There's nothing shameful about it; you'll not go blind.

Now, since I know you kids are going to want to play your Counter Strike anyway, it's best to make sure you only game with people you already know and trust. Don't deathmatch with that hussy you found at the airport bar, and never accept files from strangers. You don't know who else they've swapped files with.

Can you blame them?

[Anonymous Coward]

Microsoft and security?

Chalk and cheese?

Re:Can you blame them?

[Anonymous Coward]

I happen to like Chalk and Cheese!

Re:Can you blame them?

[grolschie]

> Microsoft and security?

> Chalk and cheese?

Don't you mean simply "swiss cheese"? ;-)

Re:Can you blame them?

[AnFraX]

Don't put down the swiss cheese. Last time I tried to put a Windows CD in a sub it didn't work out so well.

Re:Can you blame them?

[CastrTroy]

I'm assuming you've never actually tried real swiss cheese from switzerland. Real Emmental or Gruyere is amazingly good cheese. Nothing like the crap "swiss" cheese they serve at subway or sell in slices at grocery stores.

Re:Can you blame them?

[grolschie]

I was refering to the cheese with the holes in it. But the Subway angle also works. Thanks. ;-)

Re:Can you blame them?

[pgilman]

>> Microsoft and security?
>> Chalk and cheese?

> Don't you mean simply "swiss cheese"? ;-)

as a swiss citizen, i must protest this defamation of our fine emmentaler cheese by its being mentioned in the same sentence as microsoft software. please find another way to say "full of holes."

thank you|danke|merci|grazie|grazia.

;-)

Re:Can you blame them?

[Presidential]

please find another way to say "full of holes."

hmm... Al Bundy's underwear?

Know the drill part II

[Anonymous Coward]

http://www.vorck.com/remove-ie.html
http://nuhi.m sfn.org/nlite.html

Just hold down Ctrl.

[agent dero]

C'mon, this has been known for a while ;)

Re:Just hold down Ctrl.

[sharkey]

Surely they thought of that! What you'll need to do is: take the case off the HDD and use a Sharpie around the edge of each platter.

bugs

[Respawner]

should bugs or exploits in windows still be frontpagenews ?

Re:bugs

[Anonymous Coward]

should bugs or exploits in windows still be frontpagenews ?

Of course they should. Useful tech stories are boring and don't come a few times an hour. You need juicy stuff to keep people coming back here.
It's like Charlotte Church vs Britney Spears. Who has the talent, and who gets the press?
People don't want to learn, they want to be entertained. /. is perfect because it caters to the geek flaw of perceived intelligence. Geeks think they're smart, so a site which entertains them while making them think they're smart is genius.

Cue the trolls!

[Anonymous Coward]

Welcome to TrollDot.

Wait. A. Minute.

[OccidentalSlashy]

Now we're trying to crash it? Isn't that, like, four steps forward for Windows?

Software includes hardware-implementation?

[StefanoB]

XP SP2 included canary values and hardware-implemented execution protection in order to avoid exploitable buffer overruns.

Gosh, every day I learn something new on Slashdot ;-). Software and hardware implementations differ in that software is executed sequential, while hardware executes concurrently.

StefanoB
-- com'along, let's go womanizing (Mr. Burns needs a chick)

NX bit?

[Anonymous Coward]

I read the .PDF pretty carefully, but I still don't understand how DEP (data execution protection via the NX bit in the page tables) fails to prevent this exploit. The 1016 bytes of memory is on the heap, isn't it? So how is any code you put there going to be executed?

Re:NX bit?

[Anonymous Coward]

The program disables the small allocation heap (meaning that the 1016 bytes of exploit code would be loaded into some other heap), which leads me to believe that perhaps the NX bit was only set for the small allocation heap pages. This will probably get fixed pretty quickly.

Re:NX bit?

[YU Nicks NE Way]

The article description is a bit deceptive. NX is independent of DEP here. The alleged exploit only works for the small heap on machines without NX, not for machines with NX. NX stops this exploit cold.

Re:NX bit?

[Deathlizard]

I agree. After reading the PDF, it seems that they were focusing on the software DEP system rather then the hardware (NX) DEP.

For those not in the know, XPSP2 has two forms of DEP. Hardware and Software. If your Processor supports it, WinXP uses Hardware DEP in the form of the NX bit to protect your PC. If the NX bit is not available on your CPU (Most CPU's fall under this category) then it defaultes to the Software DEP, or "sandboxing" as they put it.

If anyone wants to try and exploit this on an NX capable PC it would be interesting to see if it works. The Software DEP definetly is going to need some more work done to it though.

Re:NX bit?

[Anonymous Coward]

Yeah, it's kind of silly for them to focus on a problem with software DEP instead of hardware DEP.

I mean, hardware DEP is available on 5 years old at that time. But that's crazy talk - I mean, everyone replaces their system every 6 months.

Re:NX bit?

[Anonymous Coward]

Yeah, it's kind of silly for them to focus on a problem with software DEP instead of hardware DEP.

I mean, hardware DEP is available on <1% of the installed base - and the base is growing! Within 5 years this won't be an issue at all.

Well, unless you're using hardware that >5 years old at that time. But that's crazy talk - I mean, everyone replaces their system every 6 months.

Re:NX bit?

[hobo2k]

I don't have the hardware to actually test it, but I believe the 2nd code sample is supposed to deal with NX. The stack/heap never get executed. Instead it modifies the stack such that when the function returns the C library function 'system' is called with an arbitrary command line to execute.

Re:NX bit?

[Tough Love]

Yeah, it's kind of silly for them to focus on a problem with software DEP instead of hardware DEP.

I mean, hardware DEP is available on 5 years old at that time. But that's crazy talk - I mean, everyone replaces their system every 6 months.

Mod parent up :-)

Netcraft confirms it

[ICECommander]

Netcraft confirms it, it's official

Linux/NX/AMD64

[caluml]

Slightly unrelated: What about NX under Linux on the amd64 architecture. Anyone know if/when it is supported?

Re:Linux/NX/AMD64

[DaHat]

Last I checked it already was.

http://news.zdnet.com/2100-3513_22-5227102.html/
http://linuxgazette.net/107/pramode.html/
http://kerneltrap.org/node/3240?PHPSESSID=262a094f ee677def32a8cc4d1b858f99/
http://searchenterpriselinux.techtarget.com/origin alContent/0,289142,sid39_gci969248,00.html/

Just to name a few

Re:Linux/NX/AMD64

[Anonymous Coward]

if: yes
when: now (since quite a while actually)

even various software methods for x86-32 are implemented,

Re:Linux/NX/AMD64

[caluml]

I know that it has been in the pipeline for a while.
But how do apps take advantage of it?

I've compiled 2.6.10 recently, and I didn't see any options for "Enforce NX", or anything? Or is it a glibc thing?

Re:Linux/NX/AMD64

[Anonymous Coward]

I cant be sure, its all in a gentoo induced haze - but i think theres something you can pass to the kernel on boot. I know theres SOMETHING on the gentoo wiki about it. Hope that helps

Re:Linux/NX/AMD64

[Anonymous Coward]

look up the boot options in linux/Documentation/x86_64

afair, you might want noexec=on, noexec32=on

Re:Linux/NX/AMD64

[Anonymous Coward]

How about the users running standard x86? Even Celerons have NX nowdays.

Is that link to MS correct

[DJStealth]

Is that link that says 'here' to microsoft.com correct? It points to something for Windows NT4.0 w/SP4

Re:Is that link to MS correct

[DarkMantle]

You expect the links and the article to be related?

You expect too much from the editors.

Re:Is that link to MS correct

[hobo2k]

The website offers the program PTmsHORP, but the I found description of it to be cryptic:

allows restriction of lookaside list creation, governed by a special global flag.

Using regmon and filemon, I found that PTmsHORP simply modifies the DisableHeapLookaside registry value. That old KB article was the most authoritative source I could find which describes what that registry setting does.

Also I found it interesting that a performance improvement made back in the NT4.0 days, which at the time caused some poorly written apps to crash, still exists in XP and could be used to exploit poorly written apps.

This is way wrong.

[A beautiful mind]

"Published 28th January 2005."

And

"In October 2004 it was discovered by MaxPatrol team that it is possible to defeat Microsoft® Windows® XP SP2 Heap protection and Data Execution Prevention mechanism."

This is too much time to fix something. I can agree with some delayed disclosure but not anything above a month.

Re:This is way wrong.

[jschottm]

This is too much time to fix something. I can agree with some delayed disclosure but not anything above a month.

The CNET article states that they didn't report it to Microsoft until Dec 22. Which is close enough to the holidays that a substantial part of many businesses staff are out until the 1st of Jan.

Anything that modifies core memory access/rights such as this needs extensive testing. It's most likely an easy fix, but you should be well aware of the outrage that would occur if they released a fix that ended up breaking things. Recall the rushed fix to OpenSSH that was distributed only to be replaced days later with a proper fix, leading to all manner of confusion as to which versions were vulnerable and not?

Given that this is a relatively minor problem - the attacker would have to have another sucessful attack vector to be able to use this, I'm glad Microsoft is [theoretically] taking the time to do this right. If you're really that worried about it, you can run the software provided by a mostly unknown Russian company that they freely admit will affect the system negatively. And pray that there's no bugs in their code and that it's not malicious...

Re:This is way wrong.

[A beautiful mind]

Still the question surfaces, why did the people who discovered the flaw sit on the vulnerability for two months without notifying security@microsoft.com? Well, either this or they DID notify Microsoft way before dec 22 which Microsoft fails to mention. MS did this before( put the notified date to a later time) to doctor their statistics before and get more time. I don't trust neither companies tbh.

Re:This is way wrong.

[Anonymous Coward]

\*The code is right there in HTML form...If there is anything malicious about the code have a look:-)*\/\/\~~~~~XPinthepot I compiled and ran it no problem~~~~it is runing just fine comrade Stalininskyovich XPinthepot/\/\*~~~zoizzz I am having trouble writing things though and my computer seems slower.....zotvodkaONiceHaveanicedaywillya

Re:This is way wrong.

[Your Average Joe]

They did not want to spend some of that $40 billion. They are trying to conserve resources...

Re:This is way wrong.

[sharkey]

It's most likely an easy fix, but you should be well aware of the outrage that would occur if they released a fix that ended up breaking things.

NT4 SP6 - No one really NEEDED their networked fax servers, did they?

Re:This is way wrong.

[Tough Love]

Anything that modifies core memory access/rights such as this needs extensive testing. It's most likely an easy fix, but you should be well aware of the outrage that would occur if they released a fix that ended up breaking things.

Sure, that's why if anything breaks Linux kernel memory protection it takes at least a month for Linux developers to release a fix. Oh wait, it doesn't.

Re:This is way wrong.

[Anonymous Coward]

A better comparison would be the length of time it takes for the fix to make it into, e.g., the mainline Red Hat release. I don't know how long that usually is, but the reality is that testing takes time, so if Red Hat do extensive testing before releasing patches, there will be a significant gap.

One nice thing about Open Source is that if you don't care about potential problems from patches, you can download and recompile right away. Most corporate IT departments would never do that, though, unless the bug posed a very severe threat (and the one mentioned in this article doesn't even come close).

Re:This is way wrong.

[Anonymous Coward]

Not to defend Microsoft's shocking security record... but you are comparing apples and oranges here. It's not about how long it takes Linux kernel developers to release a patch, it's about how long it takes a commercial distro (Red Hat, for example) to test, confirm it doesn't cause problems for others and put their reputation on the line by releasing a new kernel.

Re:This is way wrong.

[Tough Love]

A better comparison would be the length of time it takes for the fix to make it into, e.g., the mainline Red Hat release. I don't know how long that usually is, but the reality is that testing takes time, so if Red Hat do extensive testing before releasing patches, there will be a significant gap.

No there won't. Security fixes are fast tracked and available here essentially on the same time frame as patch releases to the general public.

Re:This is way wrong.

[Anonymous Coward]

Security fixes are fast tracked and available here essentially on the same time frame as patch releases to the general public.

Ah, so obviously Red Hat don't test them. A bit surprising, but perhaps Red Hat users have low expectations, or don't mind doing all the testing themselves.

Re:This is way wrong.

[Tough Love]

Ah, so obviously Red Hat don't test them. A bit surprising, but perhaps Red Hat users have low expectations, or don't mind doing all the testing themselves.

Don't act stupid. In many cases, Red Hat employees are the ones who develop the fixes. In all other cases, they work closely with those who do.

In hardware?

[MrLint]

Is it just me or is relying on hardware to protect your application heaps seem to be a bad idea. Not just because its non-portable (not that this matters for windows) but it basically offloads the work on HW that may or may not be up to the task.

We know that unix, its variants and progeny, have memory protection. How many of these rely on the hardware to protect them? Certainly 'legacy' *nixes didnt run on HW that had these features.

I guess what im saying is i dont like it as a long term strategy.

Re:In hardware?

[lachlan76]

Didn't the Alphas have NX? Or was that something else...something did I think.

Re:In hardware?

[Anonymous Coward]

How many of these rely on the hardware to protect them?

Ummm... all of them?

Memory protection requires hardware support to work, and every version of UNIX, Linux, NT (right from the beginning) and Win9x all use hardware support to implement memory protection.

It seems that you have hardware memory protection mixed up with the NX (no execute) bit. All that the NX bit does is nothing more than mark memory allocated on the heap as non executable. The application is completely free to allocate executable memory, just that a normal malloc() does not cut it for this purpose.

This is a very good feature. The reason is that 99.99% of apps never need to execute code created on the heap. The only exceptions are things that JIT code like the Java VM.

Many buffer overruns that result in exploits rely on heap memory being executable. By requiring a very small set of programs to be fixed, you can eliminate a whole type of security flaw. Is it the be all and end all? No its not. But it sure helps.

Re:In hardware?

[Anonymous Coward]

Most modern RISC processors have NX. I'm not sure if Alphas do, but most likely. Sparcs do.

Re:In hardware?

[bonch]

Is it just me or is relying on hardware to protect your application heaps seem to be a bad idea.

Welcome to part of the reason for the .NET runtime. :)

Re:In hardware?

[MrLint]

Win9x uses HW memory protection?

Re:In hardware?

[Anonymous Coward]

Yes it does. As your example demonstrates, it is crappy and not to the same standards as NT and UNIX, but it is still uses the hardware to protect memory.

Re:In hardware?

[runderwo]

MIPS doesn't. :(

Re:In hardware?

[Anonymous Coward]

How do the no mmu version of Linux work then?
Is there no memory protection at all, or does the kernel emulate a limited form of it so that Linux will run?

Re:In hardware?

[einhverfr]

Many buffer overruns that result in exploits rely on heap memory being executable. By requiring a very small set of programs to be fixed, you can eliminate a whole type of security flaw. Is it the be all and end all? No its not. But it sure helps.

Not as simple as that.

YOu don't eliminate a whole class of attacks, you just make them harder. An attacker may still be able to subvert a program using a buffer overrun, but this requires a better knowledge of the heap structure surrounding the buffer and it relies on overwriting data and pointers rather than direct executable code. So if everyone is using NX, then buffer overruns still become the same problem they are today.

But if most people don't have NX enforcement, then those that do are effectively safe for the moment.

Re:In hardware?

[Anonymous Coward]

YOu don't eliminate a whole class of attacks, you just make them harder.

Fair enough. Allow me to clarify - you do eliminate a whole class of exploitable attacks. This class of attacks are "Buffer overruns that inject code onto the heap and execute said code". NX changes that class of attacks to merely "Buffer overruns that cause the process to panic and quit".

Remember, not all buffer overruns are created equal. Not all are exploitable. While all they are all clearly bad, NX turns certain explotable buffer overruns to non exploitable buffer overruns.

But if most people don't have NX enforcement, then those that do are effectively safe for the moment.

I do not understand this statement; it seems to be assuming that the existence of exploits that attack non-NX systems will deter people from working on exploits against NX systems. I fail to grasp that logic.

Re:In hardware?

[Anonymous Coward]

I am not familiar with the non-MMU version of Linux, but (correct me if I'm wrong) I would imagine that it would not support memory protection. Which would be fine because isn't non-MMU Linux used primarily in embedded environments. Or am I just being ignorant?

Re:In hardware?

[Waffle Iron]

Is it just me or is relying on hardware to protect your application heaps seem to be a bad idea. Not just because its non-portable (not that this matters for windows) but it basically offloads the work on HW that may or may not be up to the task.

You're right. Back in the days when I used DOS, buffer overflow security issues were unheard of. Thus, it's clear that memory management hardware in CPUs has been a giant step backwards for security. In fact, I think I'll patch my kernel to zero out all of the page privilege bits, and I'll never have to worry about buffer overflows again.

Re:In hardware?

[Aeiri]

I guess what im saying is i dont like it as a long term strategy.

I don't either... after we all have protection on the hardware layer, and software developers stop caring about buffer overflows, as soon as a problem is found in the hardware implementation, we would ALL be screwed. Every single box would be vulnerable, and that would definitely not be good.

Re:In hardware?

[spitzak]

Even the first PDP-11 to run Unix had a form of hardware memory protection (basically segmented memory, a program was incapable of addressing other than the 64K assigned to it). There is no way for the most carefully written Unix kernel to prevent an arbitrary program from writing all over memory unless there is hardware to prevent it.

It appears most of the problem is the lack of this NX bit on Intel processors. If it had been there initially both Windows and Linux would be using it and nobody would think much of this at all. I don't understand why this was not included in the 80386, though, there was plenty of precedent. The VAX certainly had these styles of protection bits. The 80286 which did "virtual memory" by allowing attempts to load the segment registers be trapped, would have made it trivial to fake an NX bit, since it had a unique segment register used only by the program counter.

We now can watch the Microsoft, Intel, and even Linux guys all congratualting themselves on how smart they are, rather than pointing out that a stupid mistake was made long ago. It's in everybody's interest to pretend that mistakes are never made by designers.

Re:In hardware?

[einhverfr]

Fair enough. Allow me to clarify - you do eliminate a whole class of exploitable attacks. This class of attacks are "Buffer overruns that inject code onto the heap and execute said code". NX changes that class of attacks to merely "Buffer overruns that cause the process to panic and quit".

Not quite. If I know enough about what I am overwriting, I may still be able to overwrite addresses of dll's etc. and subvert the execution of the program. If pointers to functions are used, I can overwrite those to with pointers to other functions. Possibly might be able to overwrite other important data with data which can then cause the program to change the course of its execution.

So it changes it from an "injection of executable code" into an "injection of data which may subvert exectution of the code." The exploit is different and more difficult, but it is still possible to exploit it as a buffer overrun and subvert in at least some way the normal execution of the code.

This is a lot harder than simply "execute instrucitons in the heap" but it is still a serious security issue.

Re:In hardware?

[bluefoxlucid]

Um. you don't need hardware. And java JIT does not need an executable heap, as I've shown. Realtime emulators like Qemu and VMWare need one. You need to add good, high-entropy ASLR to NX to seal it, otherwise it's evadable.

Re:In hardware?

[omry_y]

You didn't hear anything about buffer overflow in DOS simply because there are much simpler way to run arbitrary code, whenever you want.
you can simply register an interrupt handler, for the clock, if you need to do something every clock tick, or to int21 (dos function calls) if you want to do something when a program calls dos functions.

Re:In hardware?

[Anonymous Coward]

Like MS-DOS, or any other OS written for hardware without an MMU, the MMU-less version of Linux lacks memory protection: an invalid memory reference in any process can corrupt the kernel, and there's no security at all between processes (nor is there virtual memory). Mind you, this doesn't generally matter on embedded systems, since they usually only run one dedicated app, and if it crashes, it's as bad as a system crash anyway.

Re:In hardware?

[Anonymous Coward]

This link from the site you've pointed to discusses using the x86 segmentation hardware to implement non-executable pages. Am I missing something here (I may be, since I've only skimmed the site)? It certainly sounds like they're using the hardware to me.

The use of the segmentation hardware is also what OpenBSD does for W^X (which means the system won't allow memory to be both writable and executable) on x86, but it's acknowledged to be a crappy hack far inferior to using the page-level execution bits on hardware that offers them (e.g. amd64, even in 32-bit mode).

Re:In hardware?

[Anonymous Coward]

Just out of curiousity, have you been reading my posts? I've made it clear that this technique does not eliminate the security implications of buffer overruns, it just prevents executable code from being executed on the heap. Nothing more.

Re:In hardware?

[Anonymous Coward]

Can you support your point? Your first link describes x86 segmentation, a hardware technique. Your second link is merely a link to a Google search. To my knowledge, Kaffe will spit x86 instructions into a JIT buffer on the heap. While I'm not familiar with the source code to Kaffe, I'm willing to bet that they do not use an old fashioned malloc() to allocate that memory on platforms with the NX bit (or they do another step to mark that memory as executable.) Can you correct me?

Re:In hardware?

[Anonymous Coward]

Erm, he was obviously joking. Nobody with any significant knowledge of PC hardware would seriously be against the inclusion of memory management hardware in PCs.

Re:In hardware?

[Anonymous Coward]

I am reading the posts, but I guess we are talking past eachother. I was hearing you say things like "buffer overruns can only cause applications to crash" but I guess I was mistaken. Sorry for the misunderstanding.

It shouldn't be a suprise.

[TeeJS]

that it's easier to bypass a patch over a hole, than get through a barrier that was built solidly from the beginning. I have a mental image of a steel door with a big piece of cardboard taped to it....

Re:It shouldn't be a suprise.

[Anonymous Coward]

yep, with ENTER HERE written all over it

Re:It shouldn't be a suprise.

[ZorbaTHut]

Taking your analogy to its extreme, it seems like you're suggesting rewriting the entire piece of software every time a bug is found.

I think I'd prefer a different analogy.

It's much harder to get through a barrier that's been tested and reinforced appropriately than one that's never been tried out - no matter what the skill is of the person who constructed it.

Software has bugs. Software gets fixed. Software is stronger for it. This is true of Windows, Linux, OpenSSL, and any other piece of software you care to name. Microsoft is fully aware that rewriting Windows would be a ludicrously stupid move on all fronts, and so they're not going to do it - and they shouldn't, either.

Re:It shouldn't be a suprise.

[Jane_Dozey]

Hmmm...IMHO the software cycle goes more like: software has bugs. Software gets patched. Software gets fixed and lots more features added in the next version. Software has more bugs....

Generally software does not get stronger. People keep adding (more code) to it before it can get there.

And yes, I'm talking about all software here, not just MS.

Re:It shouldn't be a suprise.

[a_n_d_e_r_s]

When a serious bug is found that affects the whole design - the best solution is to do a redesign and rewrite.

Every expert programmer knows that. Those that write agile software are highly aware of that.

Sadly companies often wants to get a fast fix out and that fix very seldom are 100% correct.

Re:It shouldn't be a suprise.

[ZorbaTHut]

I disagree. Refactoring sounds like a much better solution. And I highly doubt this is a serious bug that affects the whole design - why would the introduction of a new CPU flag require the complete reconstruction of an entire OS kernel? Or more?

I don't see how you could possibly suggest a full redesign and rewrite and then, in the same post, complain that fast fixes are rarely 100% correct. As if the rewrite won't be a thousand times worse!

Re:It shouldn't be a suprise.

[null etc.]

I have a mental image of a steel door with a big piece of cardboard taped to it....

Are you saying that taping a piece of cardboard to a steel door makes it easy to bypass? Wow, I'm gonna get me to a bank...

Re:It shouldn't be a suprise.

[TheLink]

Well that's fine if people who really know what they are doing do the redesign and rewrite.

If it's the same people who didn't spot the serious bug that affects the _whole_ design, the odds are much worse that starting again would actually help much.

Ask a crappy team to redesign and rewrite and they'll just come up with more crap. Let's be nice and say the team is good only the politics/process is broken, whatever, you still end up with more crap.

So far the evidence is that more often than not the same people who wrote insecure software will still _rewrite_ insecure software even if they start anew. Go look at Bugtraq over the years.

It's hard for most programmers to write secure software in certain programming languages - C being the most infamous example. Trouble is most still keep doing so for various reasons.

Never though of it.

[sn0wflake]

I've never though of why my Windows with *all* patches and a positive Microsoft Windows Baseline Security Analyzer check doesn't produce those annoying "are you sure" questions. Can't say that I miss them though because I know my system is up to date :)

I wonder....

[futuresheep]

I wonder what Nick McGrath's opinion on this is, and who is HE holding accountable?

smart++

[PaulBu]

at which time company Chairman Bill Gates called the update "a significant step in delivering on our goal to help customers make their PCs better isolated and more resilient in the face of increasingly sophisticated attacks."

The increasingly sophisticated attacks just threw me over the edge! It sounds so much like a Big Brother representative would sound when informing the world of a successful (real) attack, and even in the last time it happened (9/11 ;-( ) it was referred too as "unpredicted", not actually "sophisticated"!

Do not you think it is appropriate for Bill a) not to use anti-terrorism language and b) remember that buffer-overflow attacks were in the books, when, like 1969? (AFAIR, Morrisson's warm used that).

Paul B.

Windows not Linux?

[uodeltasig]

Perhaps Nick McGrath was misquoted he was actually saying "Windows security is highly exaggerated"

And yet

[HackNack]

When asked about the problem Steve Ballmer said that Linux sucks.

Re:And yet

[SirTalon42]

Linux has for a good while. It also has 'Execute-Shield' which also makes buffer overflows much harder (implemented in software, and I believe works on more than just x86/x86_64).

foiled?

[gardyloo]

CNET reports that SP2 has been foiled.

Shouldn't that read tin-foiled? C'mon, slashdot, standards?

Re:foiled?

[gardyloo]

Sorry, all. I must've been thoroughly drunk when I wrote that crap about standards on here.

Re:foiled?

[drumist]

Wow, and you sobered up in just 2 minutes.

Evil

[XanC]

All the attacker has to do is set the evil bit, and it overrides NX.

Re:Evil

[TobyIRC]

http://slashdot.org/articles/03/04/01/133217.shtml

Don't forget...

[bonch]

www.apple.com/switch :)

Re:Don't forget...

[Anonymous Coward]

Tired of bullshit Slashdot comments? Browse at +3!

Tired of a constant stream of /. groupthink? Tired of zealoutry, opinions you already agree with and mindless open-source advocacy? Tired of never reading anything you find challenging? Then lobby for a 1 threshold option :)

Re:Don't forget...

[Anonymous Coward]

If you really read comments at +3, you're reading the same stupid-ass crap that gets posted in every fucking story.

What's the mother fucking point of reading the comments if you're going to let other people decide for you which ones are good enough to read?

Re:Don't forget...

[A beautiful mind]

Well, new information obviously. Don't get me wrong, im reading at 0. Some are just too lazy/don't have time/have no need to formulate an own opinion.

Re:Don't forget...

[prockcore]

Neither OSX nor the PPC hardware have any sort of page execution protection.

Saying "XP's No eXecute can be foiled so I'll switch to a platform that doesn't even offer it" seems a little odd to me.

Plus, AMD's NX bit will catch this, so XP2 on AMD64 doesn't have this problem.

Re:Don't forget...

[Anonymous Coward]

Photoshop runs better on PC than Mac these days. Internet, unfortunately is also built into Windows, as is crappy jukebox software. PC laptops are just as portable. No sale.

Re:Don't forget...

[Badanov]

I like -1, raw and uncut. It gives me a far broader picture of what is boing said about a particular subject.

If you browse at +3, you will miss a lot of funny as well as lot of rather intelligent posts you wouldn't get to see at +3.

Also, reading at -1 raw and uncut shows in rather stark clarity that the moderating system at slashdot is broken

Yep...

[rbochan]

...probably Nick McGrath ;o)

And yet

[Anonymous Coward]

Linux is not invulnerable to this type of problem either. Hell, does Linux even have executable stack protection AT ALL?

Oh no!

[Anonymous Coward]

It's time for linux fags to come out yapping. I guess they're probably done jerking off to the earlier GPL article.

Re:Oh no!

[HackNack]

I don't know about the others but I'm still choking it like it owes me money. That GPL is so hot!

Re:Oh no!

[Anonymous Coward]

The difference is MS software is like a hooker, you have to pay to get jerked! Open sores is what you wind up getting after you realise you have been shafted.

Service Pack 2 kills my Celphone "Modem".

[Forge]

Windows XP Service Pack 2 has only 1 problem (for me) beyond those of regular XP.

My celphone can no longer be used as a cerial divice, aka; Dialup modem.

Yes, The same hardware works on Linux (Dell Inspiron 8200, Sony Erricson T220 on a USB cable) and removing the pack got it working in Windows again.

Re:Service Pack 2 kills my Celphone "Modem".

[Anonymous Coward]

My cerial celphone won't work either

So?

[FinchWorld]

Who are M$ going to blame?

When Are they going to blame them?

When will they bother to fix this?

Place bets NOW

is it

A: Hackers, right away

B: Hackers, from the Open Source community, when they make something better than them (Eg Someone failing asleep on there keyboard)

C: Themselves (Odds at 1 to 10^67^687^3945^Pi for this)

Source please?

[game kid]

Just curious exactly where, though Microsoft's guys have said things like this a lot.

That said, I can't wait for NX flags and other hardware measures to go mainstream. Unless you have a hardware firewall (or Linux?) software like Windows can still be teh flimsy, though in SP2 I have seen VERY few 0xC0000005 errors or STOP bluescreens. (But that's just my eXPerience(TM) with XP(TM).)

BTW, if you dont like adware, don't go to just-free-games.com; their "freeware" games use Gator et al. to pay their bills.

Re:Source please?

[SirTalon42]

If you don't like adware/spyware don't use IE (use FF/Mozilla/non-free Opera), and make sure you don't install any programs that have it bundled with them.

Heap protection broken for a while

[diginux]

Heap protection has been broken virtually everytime it has been implemented. The reason for this is, you still have system libraries from which have execution powers that can still be used for writing shellcode.

Fixed Quickly?

[EventHorizon]

The patch may be quick. It will still take a long time to deploy.

Anyway you have to wonder about this kind of technical oversight. If you are implementing an NX heap, you obviously need to NX the WHOLE heap for it to be useful.

Basically it looks like Microsoft is incapable of secure development at the core OS layer. I find that absolutely mind boggling given their resources.

Re:Fixed Quickly?

[Anonymous Coward]

Stop trolling, there have been plenty of Linux kernel exploits. You'd think they could develope secure OS layer code considering you've got all those "eyes" looking at the code.

Re:Fixed Quickly?

[a_n_d_e_r_s]

Why mind boggling ?

They did spend a lot less on research and development so they could get a decent profit for 2004.

And look where it lead them!

Re:Fixed Quickly?

[Anonymous Coward]

Ok. Let me get this straight: a program can bypass security in its own process. And this is a bug how? And we're worried that some malicious piece of code will do this to itself to allow people to exploit the hole? Why wouldn't it just do the damage itself? Or open a port to allow someone direct access?

Some people seem to be forgetting that the whole point of the NX flag is to prevent buffer overflow exploits in programs that used standard memory allocation. It'll always be possible for a program to allocate executable memory, but you only do that if you're writing a JIT compiler or such.

Re:Fixed Quickly?

[Anonymous Coward]

> I find that absolutely mind boggling given their resources.

Consider the history, not the resources.

Re:Fixed Quickly?

[Anonymous Coward]

The patch may be quick. It will still take a long time to deploy.

If only they had some way of remotely executing said patch on millions of windows machines...

Re:Fixed Quickly?

[peasleer]

Don't make it sound like Linux is problem free either. Just this morning, *11* Linux kernel vulnerabilities were posted to security focus. Yes, the number of vulnerabilities in Linux have historically been fewer in number, but no operating system is perfect. Windows does what it does well: Providing a stable (yes, XP is stable,) operating environment for beginning to advanced users.

Re:Fixed Quickly?

[TelJanin]

And how long will it take to fix the Linux problems, compared to the Windows problem descibed in the article?

Linux way of fixing things:
1) Discover there is a problem
2) Send a patch to kernel maintainers
3) Kernel is patched

Windows way of fixing things:
1) Discover problem
2) Tell Microsoft
3) Two months later, when Microsoft has done nothing, tell the world
4) Get possibly sued by Microsoft (if MS can to a Russian company)
5) After several viruses have exploited the vulnerability, Microsoft makes a patch that won't install correctly.

Re:Fixed Quickly?

[Anonymous Coward]

He never mentioned Linux at all. A bit defensive now are we? Must be another employee trying to defend the undefendable...and yes, the coding oversight here was pathetically sad.

Re:Fixed Quickly?

[Zeinfeld]

Thanks to the abortion thread, this is the first comment that actually addresses the real issue.

The patch may be quick. It will still take a long time to deploy.

No, Windows has had automatic update for years now. Every machine I have is fully current with patches.

What would be the proportion of Linux systems running with heap protection?

Re:Fixed Quickly?

[quarkscat]

(...putting on my tinfoil hat...)

Why wouldn't Microsoft parlay vulnerabilities
in their core OS (and the long delays in their
providing patches) into a big push to adopt
their "Trusted Computing" initiative?

With DRM in BIOS, and no ability to use any
OS, application, or media file not explicitly
approved by Microsoft, any/all of MSFT s/w
vulnerabilities become a moot point. They will
have no legal or moral compulsion to fix any
of their s/w vulnerabilities, as all security
concerns (and responsibility) will be passed on
to the BIOS/M-B/Processor manufacturer.

What is really, truly needed is a class action
lawsuit against MSFT in the USA court system
for their EULA. The EULA the end user must
agree to gives total absolution of any MSFT
fuduciary responsibility for their crappy s/w.

Between neccessary 3rd party utilities like
firewall, anti-virus, and anti-spyware tools,
and the tens of millions of man-hours wasted
in fixing vulnerabilities/exploits/etcetera
in MSFT OSes/Apps, the true cost of TCO to
endusers could easily drive MSFT into bankruptcy,
should the courts find MSFT willfully negligent.
IANAL, but findings of willfull negligence
usually draws treble damages ...

plus, there's a chicken-and-egg impediment

[js7a]

I don't think Windows users should lose too much sleep over this. How is an exploit supposed to unprotect the heap segment in order to execute the buffer overrun code -- before such code has been executed?

Re:plus, there's a chicken-and-egg impediment

[CastrTroy]

It could be part of an actual program that is running. Like some active X code, that the user told the browser it was allowed to run.

Re:plus, there's a chicken-and-egg impediment

[LO0G]

Exactly: In order to exploit this, you need to find a program with:

1) An exploitable memory overwrite error in a system component.
2) A heap allocation pattern that exactly matches the pattern demonstrated here.

If you don't have BOTH of these criteria met, then it won't matter.

Software DEP was never intended as anything more than a really big speedbump.

As a PoC, it's interesting, but as "the end of XP SP2?" I don't think so....

Re:plus, there's a chicken-and-egg impediment

[tepples]

If you don't have BOTH [a buffer overflow in a driver and a widely-distributed app with this sort of heap allocation], then it won't matter.

Remember that we're talking Windows here. The OS core hasn't been audited near as closely as OpenBSD, and neither have its bundled apps.

stackguards should be last line of defence

[auzy]

This is probably a good thing, because it proves that even with stackguarding, etc.. Treating your system as if they dont exist is the best thing you can do. Microsoft unfortunately chooses to use stackguarding as a first line of defence to allow them to take their time patching software, which is a terrible idea.

So basically, nothing has changed in the security world in the past year. The only thing is that the attitude of programmers have in some cases, become slacker because of technologies like this, believing they can get away with it now.

If you ask me though personally, I'm betting Microsoft didn't run major tests on the security of DEP anyway, only simpler ones

Better colours

[Anonymous Coward]

http://shit.slashdot.org/article.pl?sid=05/01/29/2 038207

I blogged another way too

[bluefoxlucid]

I did blog on another way using only a stack overflow on my blog. My way was more "all existing exploits work as-is after just a little extra step" than "exploits still exist that get around DEP" though.

My way was to just slap DEP in the face by using a ret2libc with a constructed stack frame that gave the shellcode a nice, clean, executable area of memory to execute in, then copied the memory there, then returned to it. This is done by 1) Return to VirtualAlloc(), 2) Return to memcpy(), 3) return to shellcode.

They noticed this in October; it took me until January and I'm not a security expert.

Re:I blogged another way too

[Anonymous Coward]

Yeah, same here, except I posted anonymously to /. instead. ;)

Anyway, that's why you put VirtualAlloc (and VirtualProtect) in an ASCII-armor protected region. Even in the less safe (on little-endian machines) 0x00nnnnnn region, that stops you from returning to memcpy.

Its just you

[iamnotacrook]

I mean this in the nicest possible way, but please dont post crap like this. You just embarrass yourself.

You even mentioned non-portability as an argument. Yours ranks among the stupidest posts I have seen in a long time.

For the geeks...

[Jugalator]

... the juicy bits are here. Scroll down to the bottom for the appendices where there are C code examples on how to bypass these measures.

So, will M$ take a stand?

[cvd6262]

Since MS claims Linux companies can't be held responsible for Linux security, will MS claim responsibility for this?

An agrarian view on alternatives for XP SP2

[Anonymous Coward]

Plowing for several large companies, I'd always done my work on Windows. Recently however, a top online investment firm asked us to do some work using FreedBSD. The concept of having access to source code was very appealing to us, as we'd be able to modify the kernel to meet our exacting standards which we're unable to do with Microsoft's products.

Although we met several fertilization challenges along the way (specifically, FreedBSD's lack of Token Ring support and the fact that we were unable to defrag its ext2 file system), all in all the process went smoothly. Everyone was very pleased with FreedBSD, and we were considering using it for a great deal of future internal projects.

So you can imagine our suprise when we were informed by a labourer that we would be required to publish our source code for others to use. It was brought to our attention that FreedBSD is copyrighted under something called the GPL, or the GNU Preventive License. Part of this license states that any changes to the seed are to be made freely available. Unfortunately for us, this meant that the great deal of time and money we spent "touching up" FreedBSD to work for this investment firm would now be available at no cost to our competitors.

Furthermore, after reviewing this GPL our labourers advised us that any products compiled with GPL'ed tools - such as gcc - would also have to its source code released. This was simply unacceptable.

Although we had planned for no one outside of this company to ever use, let alone see the source code, we were now put in a difficult position. We could either give away our hard work, or come up with another solution. Although it was tought to do, there really was no option: We had to rewrite the code, from scratch, for Windows 2000.

I think the biggest thing keeping FreedBSD from being truly competitive with Microsoft is this GPL. Its mercurial requirements virtually guarentee that no business will ever be able to use it. After my experience with FreedBSD, I won't be recommending it to any of my associates. I may reconsider if FreedBSD switches its license to something a little more fair, such as Microsoft's "Shared Source". Until then its attempts to socialize the software market will insure it remains only a bit player.

I welcome you for your time.

Re:An agrarian view on alternatives for XP SP2

[Anonymous Coward]

??? As far as I can read (at 03:00 hours in the morning) I can't find anything about this issue in any GPL... I'm not a f***ing lawyer but I think that someone has misunderstood something...

Re:An agrarian view on alternatives for XP SP2

[Anonymous Coward]

Off topic? I think the reply is a hoot! Is everyone else humor-impaired, or am I just easily (and cheaply) amused?

Best,
Mal the Elder

Re:An agrarian view on alternatives for XP SP2

[bluefoxlucid]

BSD is under the BSD license. You may rewrite it, steal their code, and not give it out.

You can build things with GCC and not GPL them.

You can build things and link to libraries that are GPL and not GPL them.

So, you can develope apps for linux, using only your own code and any code that BSD people threw under the BSD license, and build them against open source libraries to use those, and have an MS style EULA and closed source.

Re:An agrarian view on alternatives for XP SP2

[Anonymous Coward]

How many times are you going to publish this same tripe?

Re:An agrarian view on alternatives for XP SP2

[goMac2500]

Mac OS X uses GCC for its compiler, and last I checked, a lot of Mac OS X programs are closed source. Mac OS X itself is compiled with GCC and there are huge chunks of closed source there.

Time for a re-post

[MrYotsuya]

This would be an excellent time for a re-hash of another article posted just today

http://linux.slashdot.org/article.pl?sid=05/01/29/ 1511218&tid=109&tid=172&tid=106

Your sig..

[Anonymous Coward]

Tired of bullshit Slashdot comments? Browse at +3!

And no one would ever see your posts.

Re:Netcraft confirms it?

[Anonymous Coward]

Well Laaa-Deee-Daaa, "Netcraft confirms it" you say. Is that one of your Linsux companies? If you didn't hear it from us, then it's not official.

Steve Ballmer

Conjugate "blog" worm!

[Anonymous Coward]

"I did blog"?

Okay worm, you owe it to us to conjugate blog.

Now!

Err... Anyone else notice something funny here?

[pla]

Err... Anyone else notice something funny here?

During the first execution this program shows the list of applications which already have this flag set.

I have DEP set to protect "essential Windows programs and services only"...

Yet, running this util, the list of programs looks nothing like a list of "essential" Windows programs. In fact, I honestly don't recognize any of the programs listed, and I say that as someone that knows what a normal Windows XP SP2 install "should" have running, even down to the device-driver level.

So what gives? Has Microsoft pulled the DRM-wool over us all in the form of DEP, and it has nothing to do with "security" at all? Okay, call me paranoid, but, something looks not quite right here (and I don't even mean the possibility of an exploit, I mean the uses of DEP itself, working or not).

Re:Err... Anyone else notice something funny here?

[hobo2k]

The suggested security hole exists in the windows heap manager. But there is a registry setting which makes windows use a really old heap manager for specific applications. The PTmsHORP application is simply letting you view and set that registry setting.

Um...

[Anonymous Coward]

...doesn't the processor need to support NX for the XP PS2 protection mechanism to work as it was intended? Until that time, this is a feature that can't be fully utilized.

Re:Um...

[bluefoxlucid]

Yes, because MS is too lazy to emulate one properly.

How does linux fix this?

[jojo tdfb]

So Windows could be exploited by this but how does Linux not get hit by this. My memory on os design and assembly programming isn't what it use to be, especialy since I do mostly web apps these days and avoid lower level things like the plauge.

What does Linux have in the way of heap protection? The NX bit is on AMD 64 and Itanium chips only (as far as I remember), so what's to stop this from working on any x86 based OS?

On a sidenote, I've always wondered how Linux protects, or doesn't protect, it's exception and interup handlers. After briefly dabbleing in User Mode Linux I've had this sinking feeling that my box never could be secure from this sort of attack.

Re:How does linux fix this?

[Anonymous Coward]

Excuse moi... If I remember this right (pleas correct me) writing to the heap is a result of a buffer overrun... Avoiding buffer overruns is a part of the skill called "good programming". The whole NX-bit issue is a non-existing thing, they are trying to prevent something that shouldn't have happened in the first place if the program was written correctly and doublechecked. And btw the history of buffer overruns is much older than Windows, it has been exploited on UNIX about 20 years ago.

Re:How does linux fix this?

[Anonymous Coward]

1. The 2.6 kernels have exec-shield support, which is a kind of emulation of the NX bit for processors that don't support it in hardware.
2. Modern distros do address-space randomization which stops ret2libc type attacks.
3. Linux doesn't have exception handlers so these don't need protecting.

Re:How does linux fix this?

[bluefoxlucid]

"1. The 2.6 kernels have exec-shield support, which is a kind of emulation of the NX bit for processors that don't support it in hardware."

Exec Shield protects the stack, unless something's mapped above it, or unless it thinks you need an executable stack. It protects other things, randomly; the protections randomly fail. Spender also has a working exploit that takes out ES, but he can't distribute it or disclose the method because (as he needs food) he sold it for $1000 to a security firm.

The stack can be used for code or for some data. The stack can be stuffed with 0x02020202 (NOPNOPNOPNOP) so that the shellcode can be shifted off and you either A) jump to the shellcode, or B) jump to NOPs and run to the shellcode. For things using the stack for data (like shell returns to preexisting code that's not randomly placed under most systems), you can rely on the stack being aligned to 16 bytes. "/bin/sh /bin/sh /bin/sh /bin/sh /bin/sh "

PaX has proper NX protections.

"2. Modern distros do address-space randomization which stops ret2libc type attacks."

You need to use GrSecurity's brute force deterrance to do this on fork()ing daemons like apache, else the randomization is breakable. PaX' can be broken in 216 seconds; the one from ES normally can be broken in one step by stack stuffing (64k or 2M rand, one of those two).

Brute force deterrance is useless for small randomization, because you can use a certain trick to evade them involving holding off the attack until you set up for doing it several times in parallel.

PaX has better ASLR.

"3. Linux doesn't have exception handlers so these don't need protecting."

Your right, the OS doesn't. The programmer has to code for exceptions and signals. The OS can't protect them, but you can create a compiler modification that does so. It's pointless though, really. The same things in PaX that kill your normal exploit kill your mucking with signal handlers.

Re:How does linux fix this?

[Anonymous Coward]

Spender also has a working exploit that takes out ES, but he can't distribute it or disclose the method because (as he needs food) he sold it for $1000 to a security firm.

Great, Linux's answer to the buffer overflow problem is supplied by a pay-for-exploit blackhat. Forgive me if I don't trust his code...

Re:How does linux fix this?

[Anonymous Coward]

So then you don't trust my agregation of facts because i got paid $75 for the article I wrote?

Spender didn't write PaX, he just built the code around it to add many additional useful protections to produce a complete security solution.

It's good to deploy stack smash protection as well. This protects stack based overflows in general, very high quality :)

I don't feel like going into details right now, as it's 2am.

Re:How does linux fix this?

[jojo tdfb]

So if I'm understanding this right, Linux has some moderate protection for the stack that is breakable by just filling the stack with junk until you hit something that's going to be executed? But that doesn't protect the heap and it sounds like the stack is still exploitable, just in a different way.

This isn't very good news at all. :(

By the way, thanks for answering my questions. I think I have a better understanding of the problems described.

Re:How does linux fix this?

[jojo tdfb]

From my understanding Linux is exploitable by the same class of bugs. The only difference is instead of attacking the heap via IIS you attack the heap via PHP or ImageMagik. In Windows you want to overwrite the little descriptors at the bottom of the heap. In Linux you want to fill the stack with junk till you hit something you can use, at least it was last time I checked.

I really would like to understand how Linux stops something like that from happening. It would make me feel ever so warm and cuddly.

Damn man...

[b374]

http://kerneltrap.org/node/3240?PHPSESSID=262a09 4f ee677def32a8cc4d1b858f99/

... you should have first log in to your kerneltrap acount so I could still it!!! Yeah... I'm talking about the PHPSESSID parameter.

Re:Damn man...

[DaHat]

That'd only work if I had a kerneltrap account. Being rather anti-linux... me having such a thing would be quite sad.

Merit?

[gmuslera]

Whats the merit of a paper speaking over defeating some windows technology "protection"? You just need to sneeze over a windows machine and it become infected by some virus, come on.

I suppose that the real merit is not how to defeat it, but how fix it, maybe the article should have been titled "Fixing the XP SP2 Heap Protection",

What the shit?

[Anonymous Coward]

Okay, so in order to disable the heap protection either the user has to execute arbitrary code while running under the context of a user with sufficient permissions, or be enticed to follow a fairly obscure set of instructions to edit the registry.

How the shit is this a vulnerability exactly? The only way to exploit it is to have already 0wned the machine so there would be no need to disable memory protection at any scope.

Also, as mentioned, this doesn't work correctly on hardware that supports NX. There is no pure software method to carry out NX and all existing measures, such as DEP, can be defeated through complex means. Microsoft makes no claims to the methodology being 100% secure, but it will help stop 60% of buffer overrun scenarios which account for the vast majority of said vulnerabilities. But that is the only way to carry it out in code without imposing huge amounts of overhead, which would still be defeatable without hardware support. Developers practically have to go out of their way in order to embed such vulnerabilities. These proofs of concept are irrelevant; they are not representative of the forms of vulnerabilities accidentally introduced into software.

In other words, another non-story from the shit-eaters at Snatchrot.

Re:What the shit?

[Anonymous Coward]

Which isn't hard since almost everyone who have a Windows runs it with administrative rights (it's so much easier, I've been told)...
I think that 50% to 70% of all "security issues" are caused by this... if you don't run as admin you can't write to HKEY_Local_Machine, to %WINDIR% and to Program Files...

Re:What the shit?

[Anonymous Coward]

Running as admin only really matters on multi-user systems, and has bugger all to do with memory protection. What attackers are interested in is user data, not system binaries, and a user obviously has access to his own data, and the full address space in every one of his processes.

On a multi-user system, running as admin is a very bad idea because if an attacker can compromise one of your processes, he can then attack every other user on the system. However, I've never seen a multi-user Windows system (a Terminal Server) in a production environment where users were allowed to run as admin. The same applies to single-user Windows systems that are used by different people at different times (never seen one where users were allowed to run as admin).

Re:What the shit?

[Anonymous Coward]

As far as I have understood this, the "problem" could only be exploited when you in fact are logged in as an admin... and compromising one machine in a NT domain may in fact give you access to the whole domain.
I know several companies (and a large bank) that allows users administrative rights locally on their PCs... compromise one of them and you may have access to all the data in the domain... ...and you know very well how easy it is to get people to click on something... don't you ?

OK, I checked that out! Here is what I think...

[rbarreira]

I checked out the "Top 10 reasons" to change to a Mac, because I was really curious. After I read it I just thought "Was this the best they could do?".

Let's see:

"1. The Mac...It Just Works"

Thanks, my computer works too.

"2. It Doesn't Crash"

This might have been an argument against PC's with Windows a few years ago, but not so much now. I won't even mention Linux, of course.

"3. It's a Digital Jukebox"

Wou grate!!!11!!!

"4. Delivers The Promise Of Digital Photography"

This one really turns me on too...

"5. Best Solution, In Fact, For All Things Digital"

Maybe they could stop repeating themselves... BTW, the best programs to produce music and multimedia content exist for PC too, and the quantity of plugins is much greater on the PC.

"6. Built To Go Everywhere -- Because That's Where You'll Want It"

On this section they say:
Consider this: Can your PC laptop go coast to coast with just one battery? Can you put the system to sleep just by closing the lid? Does it wake up instantly? Can your PC laptop automatically switch between Ethernet, dial-up and wireless connections on the fly? Without a restart? Ours can.

Yep, my PC can do all that too...

"7. The Internet Is Integrated"

Fact is, most of our customers are up-and-surfing within 15 minutes.

I can do that easily too. So maybe this would only be valid for people who know nothing about computers. Even then, I doubt it's much easier to configure an internet connection than in a PC in most cases. Prove me wrong.

"8. Office is Office and then Some"

OK, so this section tells me that some of the programs I use on the PC are also available for the MAC. This is hardly a reason for me to switch.

"9. It Works Effortlessly With PCs"

See previous answer.

"10. It's Beautiful"

11- Fuck That.

Re:OK, I checked that out! Here is what I think...

[rokzy]

good for you. some of us have switched and will never look back. it's not just about things working, but working well.

Re:OK, I checked that out! Here is what I think...

[hazah]

"Fact is, most of our customers are up-and-surfing within 15 minutes."

Hmm... hell, I can just boot the cd for internet. I'm sure it took me less then 15 minutes.

Re:OK, I checked that out! Here is what I think...

[Anonymous Coward]

Does it wake up instantly? Yep, my PC can do all that too

And now you've just proven you have no fscking clue.

Waking up a PC from hibernation (the closest x86 equivalent to PPC sleep) takes at least a couple minutes as it loads the memory dump off disk, sets registers back to their original state, yada yada yada. It takes a very noticeable amount of time.

On a Mac the only delay is however long it takes your HD to spin up. Everything after that is the difference (time-wise) between PC & Mac sleep modes. Crap, while the Mac is waiting for the HD to spin up, it is responsive - whatever tasks that don't require a swap to disk are running and responding. Less than a second after waking up from sleep.

But hey, far be it from me to poke more holes in the swiss cheese version of reality you've placed yourself in. Keep fooling yourself that quantity is a reasonable substitute for quality.

Re:OK, I checked that out! Here is what I think...

[throx]

Waking up a PC from hibernation (the closest x86 equivalent to PPC sleep)

Actually, you've just proven you don't have a clue.

In hibernation, the PC can be removed from the power supply completely - battery out on the floor style. Do this to a Mac in sleep mode and it dies.

The closest thing to "sleep" mode on the Mac is (believe it or not), "sleep" mode on a PC. Anyone who tries to tell you different is either self-deluded or simply trying to delude you.

Just in case you don't believe me - have a deep, deep think about why the PC coming out of hibernate needs to load RAM from the disk and why the Mac coming out of sleep doesn't? Yep - you got it! The Mac still has power going to RAM!

Thanks for playing, but you lose. Better luck next time.

Re:OK, I checked that out! Here is what I think...

[ReallyNiceGuy]

Should I fear? I got the sig... ;)

Penguins do NOT kill babies

[tepples]

Please do not compare Linux to murder; it only makes conservative organizations buy products from a convicted monopolist. Please do not compare viruses to children if doing so makes you compare Linux to murder.

Re:Penguins do NOT kill babies

[koreaman]

I didn't know there was anyone on /. who actually agreed with me on this. Welcome to my friends list.

Re:Penguins do NOT kill babies

[Mr. Slippery]

Please do not compare Linux to murder

He didn't. He compared it to abortion.

Murder is the deliberate, unlawful, and malicious killing of a human being. While arguments can be made over whether a fetus is or is not a human being (not very good arguments, mostly, often rapidly descending into supernaturalism), despite the best efforts of "pro life" organizations abortion is still legal. And abortion is not, generally, malicious.

Still - the comparion is in poor taste.

Re:Penguins do NOT kill babies

[AlanS2002]

I didn't know there was anyone on /. who actually agreed with me this sort of shit. Welcome to my enemies list.

Re:Penguins do NOT kill babies

[AlanS2002]

Hopefully there's not too many. Welcome to my foes list.

It's a bit more complicated than that.

[Anonymous Coward]

Press up, up, down, down, left, right, left, right, B, A, B, A, START in succession to disable the NX protection.

Re:stackguards should be last line of defence

[enosys]

The support the NX bit where it's available. However, many CPUs don't support that. In those cases stackguarding is the only thing that they can do.

Re:This is way wrong. Free DEP

[Anonymous Coward]

Using Knoppix to have a go that C:boot is the go - DEP is optional.

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=" Windows XP Unprofessional" /fastdetect /NoExecute=AlwaysOff

Official response from Microsoft

[Anonymous Coward]

That's okay; we planned to release this version to those owning the pirated version of XP anyway. Next question.

Incorrect

[Mark_MF-WN]

He compared it to the morning after pill. The morning after pill doesn't "abort" anything -- it simply causes the egg to fail to implant itself in the uterus. This is EXACTLY what IUDs and "The Pill" do, and what happens in 90% of all fertilizations anyway. The morning after pill is just interventive birth-control. It has absolutely nothing to do with abortions.

Re:Incorrect

[Mr. Slippery]

He compared it to the morning after pill.

One poster did. A reply made the abortion comparison.

The morning after pill is just interventive birth-control. It has absolutely nothing to do with abortions.

Actually, some radical "pro-life" pharmacists are refusing to fill prescriptions for birth control pills now, and some doctors refsuing to issue them in the first place.

(Of course it's a stupid idea that a competent adult needs a doctors permission slip to be able to buy medicine in the first place, except maybe antibiotics...)

Re:Incorrect

[caveat]

Well, the rabid anti-abortion crowd defines life as beginning at fertilization - which usually happens up in the fallopian tubes. the MAP and IUDs prevent the fertilized zygote from implanting, and are therefore forms of abortion in their book. Course, most of them are also anti-birth-control ("against the will of god" or "the bible says wasting sperm is evil" or something), so it's a moot point.

oh, the pill prevents ovulation by tricking the body into thinking it's pregnant, nothing to do with implantation. happy fux0ring!

Re:Incorrect

[Anonymous Coward]

Who modded this 'informative'?

It's 'Off Topic' - I want to read about the heap, not about the fricking Pill ...

Re:Incorrect

[BriniestMark]

Technically speaking, there are different formulations of the pill. Most use a cocktail of several different hormones, one of which prevents eggs from implanting into the uterus, while another prevents ovulation completely. The cocktails are best, because even if one hormone fails, there's a backup.

I looked into this because my GF was on a pill that did not prevent ovulation. A lot of women are more comfortable with this formulation, because it does not cause their period to end. Personally, I'd think women would be happy to rid themselves of their period, but there it is.

Hmmm

[Mark_MF-WN]

Hmmm, let me check what is says in my copy of the Windows EULA...

Sement protection in the 386

[aryaabraham]

The Intel 386 processor implements protection bits in their segment descriptors. The OS can use this to mark a segment for read, write, execute or any combination, thereof. Windows, like a lot of Unix implementations, does not leverage the benefits of proper segmentation on the i386.

Each process is given 1 segment that is logically segregated into executable space and heap space. Since each process has a different segment, one cannot overwrite another -- voila! better inter-process separation and reliability (first seen in winnt for Windows).

To prevent a buffer overflow that results in the execution of malicious code, we need to separate the data and the executable code within a process. In order to implement this correctly, MS would have had to use more than one NON-overlapping segment. The code segments would have to be marked for execution/read only, while multiple data segments would have to be marked for read/write only. If this were done, the processor would raise an exception when a non-executable segment descriptor was loaded into the CS (code segment register). If the application/malign software tried to read/write to a code segment, which was did not have the read/write bits set, the processor would raise an exception. If the code and data segments pointed to non-overlapping regions in memory, code segments could be setup to prevent write access. The use of properly marked segments gives you tremendous power over what can be executed and what can be changed.

Windows uses virtual pages extensively and has separate pages for code and data. I bet that the NX bit that is mentioned in previous comments is a modifier for the page register. The i386 does not support execution protection at the page level. The i386 expects the OS to use segments properly to partition the logical address space (4GB most of which does not map to physical hardware), and page registers to implement virtual memory in limited physical memory.

Windows does not wield the power of segmentation correctly. We should not blame intel for it.

(Note: I am not in any way affiliated with Intel, though I did look for a job there when I got out of college.)

Re:Sement protection in the 386

[Anonymous Coward]

Virtually everyone agrees that the segmentation architecture in the i386 is an awful design. The primary reason portable systems like NT and UNIX have avoided it is that it's non-portable. A per-page execute bit is, and has always been, a far better design. It's rather like ring 1 and ring 2 in the i386, which on the surface might have seemed like a good idea, but were horribly implemented and are almost universally avoided.

Re:Sement protection in the 386

[Waffle Iron]

Windows does not wield the power of segmentation correctly. We should not blame intel for it.

Everything to do with the x86 segmentation features sucks. Programming the 286 was just horrible.

When Intel came out with the 386, they encouraged people to ignore segments and use the new paging features instead. All OSes gladly complied.

Now, after several generations of architecture revisions, the segmentation logic has almost certainly atrophied to the point where if anybody actually tried to use it to do fine-grained access control, there would probably be a major performance hit of some sort. Since nobody has really used the stuff in over a decade, the CPU designers probably haven't invested the time or die space to make segment operations keep up with the rest of the chip. I would predict that trying to heavily use segmentation would result in a lot of extra pipeline stalls and cache flushes as the CPU designers' assumptions about code behavior are broken.

Re:Sement protection in the 386

[spitzak]

You are talking about the '286 memory protection scheme. I did mention that this allowed "NX" memory because you could only execute by loading the segment number into a particular register and this could be trapped and prevented by the OS.

The problem is the '286 scheme was useless due to the '86 design that overlapped the segments. Most MSDOS programs assummed and relied on this overlap, making it impossible to write a '286 version of any system that could emulate MSDOS enough to run old programs. The '86 should never have overlapped the segments, and it is a mystery why they did, since it required additional circuitry to do the addition.

The virtual memory that appeared in the '386 allowed MSDOS to be emulated since the overlap could be preserved and was unrelated to the virtual memory scheme.

There are, I believe, a whole lot of technical reasons why the '386 style vm is better, but the inability to emulate MSDOS was probably the real reason the '286 scheme was not attempted by anybody.

Question about the stack

[wirelessbuzzers]

The method of attack for most stack buffer-overflows is to write enough data into a stack-allocated object to clobber the return pointer, which is allocated above it.

So why not make the stack grow upwards instead of downwards?

Re:Question about the stack

[pe1chl]

This decision was made long ago, when there was only a single address space and it was convenient to have the program at a fixed address at the beginning of memory, and the stack fixed at the end.

The "stack grows down" has been embedded in the hardware design and now it cannot be changed easily.

Re:Question about the stack

[Anonymous Coward]

ARM processors have configurable stacks. You could make the stack grow down on them. I don't know about Xscale though.

SP2 & hardware implemented ?

[Anonymous Coward]

How can a software (SP2) implement something in hardware? Does it activate hardware-implemented (but unused prior SP2) protection? Or does someone not know the difference between hard/soft-ware, but keeps posting anyway?

Re:SP2 & hardware implemented ?

[Anonymous Coward]

AMD64 CPUs and very recent x86 CPUs offer page-level execute permission. On these systems, SP2 turns on the flag, and the OS can then disable execute permission for writable pages. Earlier x86 CPUs don't have this feature, but SP2 uses various software techniques to reduce the risk.

This article appears to be about attacking only the latter, and also appears to essentially require that a system has already been compromised in order to attack it.

Dear Microsoft...

[dmneoblade]

Dear Microsoft,

Please stop producing horrible versions of windows. Please stop continually patching the code. It is just a pile of band-aids now. Trash and renew, THEN you will have a good product.

Until then, penguins will haunt your dreams.

Re:Dear Microsoft...

[Anonymous Coward]

Trash and renew, THEN you will have a good product.

Ideally, this is what Longhorn's about. We'll see in 2019 anyways...

Get a spell checker!!!

[Anonymous Coward]

...use to be... used to be
...especialy... especially
...plauge... plague
...it's exception... its (it's = 'it is')
...interup handlers... interrupt
...dabbleing... dabbling

Whooops, was that a typo?

[cronius]

You can build things and link to libraries that are GPL and not GPL them.

Whoopsie daysie, that's not true. From gnu.org:
If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL?

Yes, because the program as it is actually run includes the library.

You can link non-GPL programs only with LGPL libraries.

It's Core Wars again!

[hpulley]

Microsoft and the hackers are just playing CoreWars, for real, on our systems. Isn't that great?

In fact, Windows XP's heap boundary checking sounds like little more than the old RADAR-X REDCODE program...

This article is idiotic.

[Ash-Fox]

Unfortunately, I don't see how this is a security risk.

All my users run under "limited" accounts, not administrator accounts, in other words...

Have no access to write such things in that part of the registry.

Much like linux's magical root, which can override all.

Re:They could fix the holes in the first place

[Anonymous Coward]

They could patch the security holes themselves rather than relying on stack protection to make them not exploitable. There are many unpatched security holes in Windows because MS is relying on SP2's stack protection rather than patching the buggy code itself.

The curse of Daniel Webster

[jojo tdfb]

No, I don't think I will.

The whole idea of spelling is a somewhat new development. Why should I be forced to conform to a completely imaginary set of rules that do nothing but to stop us from worrying about the content of our writing and instead worry about if the style conforms to the somewhat arbitrary standards set by bitter old english teachers? You may wish to be bound by such things but I do not.

Alternative implementation strategy

[real gumby]

A better way to defeat this class of attack is to move the metadata (in this case the link table) elsewhere to another, noncontiguous page. You could still induce a buffer overflow, but such an overflow would not corrupt the whole allocation mechanism.

For extra security you could put it in kernel space and give the library a new system call to do memory allocation, but that would increase memory allocation overhead, likely unacceptably.

Analysis and solution depend heavily on what attack you wish to defend against.

No software can be 'Hack Proof'

[shreyasonline]

I would like to tell people who comment without having knowledge of the topic that, there is no software which can be declared "Hack Proof". And buffer overflows are bound to happen in most of the software. You cannot have code to prevent buffer overflows in all the step of the procedure the simple reason is because the software will start to crawl. If you want to get more info on how buffer overflows happen exactly, you can search in alstalavista.com for 'buffer overflow video'. You will get man video download links. Download a 7 min avi video and you will get very clearly how this happens (to learn this you dont have to be albert einsteins, its a very simple video)

Yes, good security is a process that evolves...

[Anonymous Coward]

...making it a footrace between crackers and the kernel team at MS, but only one of those parties entered the race with their shoes tied together and you don't need three guesses to figure out which.