Submitted by Ars Technica has analyzed recently publicized Vista’s security flaws. “Unfortunate, yes, but not as was reported in the immediate aftermath of the presentation evidence that Vista’s security is useless, nor does this work constitute a major security issue. And it’s not game over, either. Sensationalism sells, and there’s no news like bad news, but sometimes particularly when covering security issues, it would be nice to see accuracy and level-headedness instead. … Furthermore, these attacks are specifically on the buffer overflow protections; they do not circumvent the IE Protected Mode sandbox, nor Vista’s (in)famous UAC restrictions.”
The article mentions that some apps/plugins choose to ‘opt-out’ of Vista’s security features. Why would somebody choose to do that? Does it take a lot of extra coding to write something that uses those features? Does it slow down the app?
They crash, that’s why. I’m presuming some software behaves in such a way as they try to execute software that is stored in data pages. (I’m no programmer. I just read Wikipedia…http://en.wikipedia.org/wiki/Data_Execution_Prevention That, and I know that having DEP on crashed an older version of flash.)
The article mentions that some apps/plugins choose to ‘opt-out’ of Vista’s security features. Why would somebody choose to do that? Does it take a lot of extra coding to write something that uses those features? Does it slow down the app?
Because it’s more difficult. I’ve written most of my code in C (long ago). I tried Ada and even Java, and there’s lots of short-cuts you get used to in the permissive environment C provides that more structured languages make impossible. It’s not just coding, sometimes you have change the way you think about solving the problem. When coupled with a business environment where re-learning means you miss your deadline, or flip a switch and have it work, you know which will be chosen.
(I don’t know if this is exactly what happens in Vista, but I would guess it is)
Did I miss something? The article pretty much supports the idea of: game over and tries to call the articles about the hack “sensationalism”. And then tries to say that XP is crap… so it’s ok that Vista can be hacked because Vista has more security features than XP
I found the article to be rather humorous… in a sad/funny way… like watching a chicken dance around with its head chopped off.
Nah! It’s never game over. Microsoft will manage to fix those issues or, at least, will give the impression that the issues are fixed. Even if Microsoft manages to patch those holes in the security system, the hackers will manage to find even more holes. The end result will be even more pop-ups asking the user whether he wants to continue or not.
Uh, wait, so the problem is that security researchers find them? Not that they exist to begin with?
You can opt out? That’s brilliant security design, right there.
Really? What the hell does? While it’s not really game over it sure is a big problem.
And neither does understating the seriousness.
Oh the irony.
So what? Exactly how dos the fact that “this would work on XP too” make this less serious?
Oh ok then. Since it only circumvents them I guess that’s ok.
No shit Sherlock. Unfortunately, again, that doesn’t make this any less of a problem.
Except when it runs code with buffer overruns, I guess?
It would appear Mr Bright is none too.
“it’s not really game over ”
So then he wasn’t ironic. You agree with him. He wasn’t understating then. Anything short of ‘game over’ is SSDD. We would need a kickass exploit turned wurm ASAP to get anything out of this… and since XP doesn’t have buffer overrun protection anyways, if 0Day of that caliber already existed it would be out there. Or have hackers really been waiting for DEP to be circumvented before they release exploits? So they can maybe someday hit that extra 15% marketshare?
FAIL
No I don’t. “Not game over” is not the same as that it’s not a serious matter. Game over would be an error that could not possible be corrected while a serious/major error can.
Yes he is. He is trivializing it with statements like “it’s not a major issue” and “it worked on XP too”.
Indeed you do.
I don’t think he was saying that it wasn’t a serious issue, just that this isn’t the mother of all security flaws that the original article made it out to be. From what I gather, the exploit only works with certain applications (the article mentions IE7 and FF2, but mentions nothing regarding Opera and FF3, so I’m not even sure if those are affected), and even if you’re using said application/plugin, there’d still have to be a buffer overflow vunderability built into the app before any damage could actually be done. So, let’s look at the criteria:
1. You must be using an application/plugin that ‘opts out’ of random memory addressing
2. That application must have a vunderability to exploit
Sure, it’s a serious issue, but it’s a far cry from the ‘all Vista users are screwed’ tone of the original article, which was the author’s entire point.
Edited 2008-08-11 18:17 UTC
You trivialize it by saying “it’s not really game over” and agree with the author on that point! no take backs.
A serious error and game over are not the same thing. I’m not aware of any public unpatched exploits that take advantage of this. There may never be one. There are critical exploitable, common, bugs patched monthly, and they don’t get the coverage and hype of this. The act of installing flash/plugins has screwed people from a security standpoint well before this bug was public.
not this time.
If IE7 and FF2 “opts out” of this (DEP, ASLR) AND that this is exploitable, then I think this is pretty serious. When you say “Ah, no problem, this exploit works only on certain apps” you can bet your ass that this will be major problem if those “certain apps” include IE7 and Firefox. These 2 “certain apps” are the most used apps over the internet (Heck, I’m even writing this on FF3). So, if IE7 and FF can be exploited in Vista, then I believe it’s pretty much game over for Vista.
From reading the post linked by a user a couple of posts before yours, I think the problem is actually the plugins Java/Flash moreso than the browsers. To be able to take advantage of this, you still need an exploit that is unpatched.
Basically, it’s like this – a vunerability in IE7 wouldn’t be an issue if it’s running in the UAC sandbox. But vunerability in Java/Flash could be a problem.
So technically, from the standpoint of somebody who has been running XP for the past 7-8 years, this is nothing new
Again, not to say that the issue doesn’t need attention, but it’s still nowhere near game over. It basically brings us back down to the Windows XP level, and even then, that is only true in certain/liminted scenarios.
So here’s the deal, really simply:
All newish programs that are compiled with the correct settings get certain protections against buffer overflows and other memory vulnerabilities. For most of these programs, these protections are effective enough that finding a buffer overflow exploit is usually only good enough to crash the program and it’s hard to make it into a self-propagating worm (it’s still a crash, so it’s a must-fix bug in the program).
For reasons having to do with the way they accept data and plugins, by their nature browsers are not all that amenable to these memory protections. Dowd and Sotirov have shown that in certain relatively common situations, it is possible to make an exploit work despite the protections, in particular due to the way that Java and Flash work (there’s still an element of luck involved for the attacker).
IE7 on Vista still uses Low Rights, so an exploit here wouldn’t be able to write to your user profile or to the rest of the system (unless they also come up with an attack to break out of the sandbox). It should also be mentioned that other OSes do not ship with the protections that Sotirov and Dowd bypassed at all, so if it’s game over for Vista, then it has always been game over for Mac OS X or Linux.
These problems are fixable, but it’s not an immediate patch. The .NET loader issue would need to be fixed and the Java and Flash runtimes would probably need some working over. To be honest, these problems probably wouldn’t exist right now if the MSJVM were still around. Unfortunately, we’re now at the mercy of the Java and Flash developers until they can harden their plugins.
so if it’s game over for Vista, then it has always been game over for Mac OS X or Linux.
Not perse,
http://en.opensuse.org/Security_Features
“Address Space Randomization is used for the stack and library mappings since SUSE Linux Enterprise 10 and SUSE Linux 10.1”
“The “Fortify Source” extensions in gcc and glibc are enabled for all packages by default (using -D_FORTIFY_SOURCE=2) since SUSE Linux 10.0 and SUSE Linux Enterprise 10. ”
“Runtime stack overflow checking using -fstack-protector is used in some critical packages in SUSE Linux 10.1 and SUSE Linux Enterprise 10 and enabled by default for all packages starting with openSUSE 10.2. ”
etc etc
Which makes me think..
I believe Linux has had (aparently, for a long time) both:
* Non-executable stack forced by compiling with gcc, and
* Virtual Adressspace Randomisation forced by the kernel
I cannot speak for MacOS X though.
If you look around you’ll find Vista ain’t so revolutionary after all. Might pay to explore outside that MS cubicle from time-to-time.
This is not a particularly well informed comment.
Firstly, building something with gcc does not guarantee a non-executable stack [1].
Secondly, heap and address space randomization was only introduced mainline as of 2.6.25 (released 17th April 2008) [2] and, in order to leverage fully, it requires a complete PIE userland – which almost all distros fail to provide (Hardened Gentoo being a noteworthy exception) [3].
Thirdly, the Linux kernel has supported the NX bit on x86 processors since 2004 (around the same time that XP SP2 was released which introduced its DEP implementation). Even then, it requires PAE OR HIGHMEM64 to be enabled – one wonders exactly how many stock distro kernels do this.
Further, based on the implementation in the kernel alone, if you do not have a hardware NX bit then you are out of luck. Besides which, the protection is really quite limited; the mainline kernel only provides a subset of the functionality provided by the Exec Shield project and, arguably, the protections offered by Exec Shield are arguably inferior to PaX (which is never going to go mainline) [4].
Fourthly, Win32 has defined a formal memory protection sheme and supported various memory protection attributes upon allocation of pages from the very beginning [5]. The only thing that has changed now is that the resultant policy is actually capable of being enforced on x86. The point is that the framework for allocating memory in the right way has always been there for application developers to use.
[1] http://www.gentoo.org/proj/en/hardened/gnu-stack.xml#doc_chap2
[2] http://kernelnewbies.org/Linux_2_6_25#head-fc71477174376b69ac7c3cd1…
[3] http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml
[4] http://en.wikipedia.org/wiki/PaX
[5] http://msdn.microsoft.com/en-us/library/aa366786(VS.85).aspx
* Hardware based NX (No eXecute, also known as DEP) support is enabled for Stack and Heap since SUSE Linux Enterprise Server 9 on:
o all AMD64/EM64T processors.
o on x86 machines using the “bigsmp” kernel and the processor being able to support the NX bit.”
There aren’t a lot of CPU’s these days that doesn’t support hardware NX and 64-bit.
True. I don’t disagree that you may know more than I about this, this is not my area of expertise. However, the parent stated that neither Linux nor Mac had memory protections. I know enough to see this is incorrect – so that fact you may know more than me doesn’t make my point any less valid.
Why someone who knows more than I would not point these out makes their statements come across as insincere (especially coming from a Microsoft employee).
True. But has been possible for a while to make a non-executable stack with gcc. You are not forced to but any network facing application should do this. Keep this ‘possible but not forced to’ point in mind when I get to your last point.
But some do. So choose your distro wisely. How hard is that is network security is your concern?
Honest question: will Vista’s NX protection work without NX being present in hardware?
See my response to the first point above. It similar to having capabilities in gcc but not being forced to use it. Since you argued that gcc’s stack-protection wasn’t any use because it wasn’t mandatory it would then follow that the equivalent must be true for the Win32 memory protection scheme. Logical?
Vista’s memory protection may be superior to Linux (or not, if the recent hyped news articles are to be believed). Fair enough, but to flat-out deny that Linux (and possibly Mac) has similar schemes is incorrect, yes?
> However, the parent stated that neither Linux nor Mac had memory
> protections. I know enough to see this is incorrect – so that fact you
> may know more than me doesn’t make my point any less valid.
In that case I apologise as I hadn’t realised the context of your comment. The parent would be incorrect to say so (although I cannot speak for Mac OS X) and indeed, to counter that is absolutely valid.
The part I was really concerned about was the assertion that Linux had had address space randomization for a “long time” and the closing remark. This led me to believe that perhapse your view of the situation with Linux was somewhat rose-tinted
For the record, the main reason for my response was to sound a cautionary note. Yes, there are some excellent hardening technologies – maybe even best-of-breed – that can be used in conjunction with Linux (see below). However, they are not mainstream and, where they are adopted by the well-known distros or in the mainline kernel itself, they seem to be implemented only partially or sub-optimally. That said, the situation is improving, albeit slowly.
> Honest question: will Vista’s NX protection work without NX
> being present in hardware?
Well, sort of. The term DEP is a little misleading in this case as it does not offer the W^X memory protection that hardware-enforced DEP does. What it does do is to offer a form of stack protection via SAFESEH (Safe Structure Exception Handling). As I understand it, Microsoft’s C++ compiler supports a /SAFESEH flag which, where the x86 architecture is concerned, instructs the linker to integrate a table of safe exception handlers into the header of the application binary. Of course, only applications that are built in this manner will benefit from this protection (which touches again on the interesting matter of some hardening technologies requiring co-operation over in userland). There is an interesting paper about it here:
http://www.nextgenss.com/papers/defeating-w2k3-stack-protection.pdf
Going back to the topic of W^X memory protection, note that both PaX and Exec Shield helpfully support the emulation of a NX bit in software on x86 so that, where a hardware NX bit is not available, there need be no impact on the level of security provided. PaX itself supports two different schemes, one of which entails a performance tradeoff (PAGEEXEC) and the other of which entails a memory tradeoff (SEGMEXEC). For anyone interested, there is an old-but-still-relevant article about it here:
http://www.pjvenda.org/linux/doc/pax-performance/
EDIT: changed “was incorrect” to “would be incorrect” so as to avoid any potential misunderstanding of what the aforementioned parent had intended to say
Edited 2008-08-12 22:44 UTC
Thank you for taking the time to explain the details further.
I agree with you. Like most things in Linux, you can get a really good solution to the problem – but only if know what you are doing and expend effort. Unfortunately most of us have limited time and expertise, but it is not to say it can’t be done.
Credit where credit is due, Vista certainly is an improvement for the “Average Joe” that involves no effort on their part.
I’m quite aware of what Linux and OpenBSD have support for. The /GS cookie in VC++ after all originated in ideas from Crispin Cowan’s stackguard in gcc. The real question is, ‘What ships by default?’ How does FireFox on Ubuntu (probably the most popular Linux browser combo right now) ship? I haven’t bothered to investigate this, but if they ship in a more locked down config than IE7 on Vista and yet still work properly with popular plugins, I’d be impressed.
Please be a bit more respectful of me… you can insult Windows all you want (there are obviously things that were screwed up over the years), but you don’t know me well enough to imply that all I know about and use is Windows.
Point taken. My apologies.
It is a necessary decision. DEP breaks software. It shouldn’t–software should do the Right Thing (e.g. use VirtualProtect to set page permissions appropriately). But it does. This is why other platforms also allow opting out of non-exec protection. It’s a necessary compromise between compatibility and security.
You might be interested to know that 64-bit processes have a much lesser ability to opt out of protection.
How about “something that can compromise a system”? That’d be a big flaw. If it were due to some systematic problem with the OS (i.e. something that could not be fixed without radically redesigning key portions of the OS), it’d definitely be game over. The methods detailed in the paper cannot. They are not buffer overflows; they are not privilege escalations; they are not any other kind of security flaw.
What they are is a way of making buffer overflows that are exploitable on Linux, Mac OS X, and Windows XP, also exploitable on Windows Vista. If there is no buffer overflow there is no problem. It is a technique for maximizing the impact of existing security flaws (my making them exploitable on Vista), not a flaw in and of itself.
If Windows XP is already susceptible to exploitable buffer overflows, and yet Windows XP remains essentially secure (which it does), then it is obvious that the ability to exploit those same buffer overflows in Windows Vista is not game-ending.
I think you must have misread or misunderstood. ASLR and DEP are not UAC or IE Protected mode. Bypassing ASLR and DEP does not mean that UAC or IE PM have been bypassed.
Yes it does.
No, even when it runs code with buffer overruns. Just because you’ve made my browser execute arbitrary code does not mean that you have made my browser elevate its privileges to allow it to escape its sandbox.
“It is a necessary decision. DEP breaks software.”
The article make it sound like this is a decision that can be made by the application without the user interfering.
I never said it was game ending, that’s the very notion i was against.
Note that the fact that these exploits havent been exploited in XP is no proof that they cant and wont be exploited in the future.
So if the locks to your apartment cant be made completely burglar proof that makes it less of a problem when you’re burglarized?
The fact that a security feature cant be made fool proof doesn’t make the consequences of it failing any less important.
Indeed it can. Just as on Linux et al.
To be honest, it’s hard to tell what you were against. One of the key points of my article was that it’s not game over, and yet you’re claiming that the article is fundamentally wrong in some ill-defined sense.
I don’t follow. You don’t need to do anything to defeat ASLR or SafeSEH on XP, because XP doesn’t have ASLR or SafeSEH at all. The ASLR-defeating attacks work just fine on XP, they’re just not necessary because there’s nothing to defeat.
[quote]So if the locks to your apartment cant be made completely burglar proof that makes it less of a problem when you’re burglarized?[/quote]
Your analogy is incoherent. Instead of trying to make meaningless analogies to burglars, why not stick with the topic at hand–buffer overflows. If an exploited buffer overflow can’t do anything bad then yes, it makes it less of a problem that there is an exploitable buffer overflow. Not no problem at all–it’ll probably result in a crash or some other bad behaviour at a minimum–but less of a problem. Being able to run arbitrary code in a sandbox is not as bad as being able to run arbitrary code as root/Administrator. The sandbox means that it can’t steal data, it can’t modify system files, it can’t do much of anything.
That’s why, y’know, MS created the sandbox in the first place.
It isn’t “failing”; it was never proposed as a 100% guarantee. The ability to execute code after buffer overflows is expected–because on x86 it’s the default. Take away DEP, take away fail-fast heaps, take away ASLR, take away /GS, take away SEHand you have buffer overflows that are almost always exploitable. The problem is not the countermeasures–it’s the buffer overflow itself. The countermeasures are designed to make the buffer overflows harder to exploit. That is all. They continue to do so even in the light of this paper.
Even if all the protections described in the paper were disabled for every single process that used them (which they’re not; the paper depended on the high level of control that browsers give to attackers–a web server or database server or other daemon wouldn’t have the same set of issues) that isn’t enough to compromise even a single machine. You still need an exploitable buffer overflow to start off with.
Ten it’s rather pointless then since any old rogue application can just exempt itself from it.
I would have at least hoped that there was a popup prompting the user to allow it.
OK, sure. And…?
It’s not like opting out of UAC or something like that (which applications can’t do). It’s just opting out of some of the buffer overflow protection.
Disabling DEP doesn’t all of a sudden let an application do bad things. It makes it more likely that buffer overflows will be exploitable (not guaranteed, just as enabling DEP/ASLR/etc. doesn’t guarantee that they _won’t_ be exploitable)
This isn’t a protection agianst rogue apps… that’s your misunderstanding.
This is a protection for good apps (like Firefox or IE7) which might have flaws. The goal of the protections is to make those apps crash rather than letting them get taken over.
“Internet Explorer 7 and Firefox 2 both opt out of DEP”
You can opt out? That’s brilliant security design, right there.”
I hope that you know that your whole rant makes no sense whatsoever?
You can opt out any security option in any OS you want: run OS as a root, without firewall, without hardened kernel, run services with root privileges, and so on.
This has nothing to do with security design.
DEP or ASLR are not mandatory.
These are options only. Linux kernel has ASLR as an option for very long time (PAX), but not every distro includes this.
If you would spent 2secs reading and trying to get what arstechnica is saying instead of masturbating with words, you would understand that MS fscked design, so they can either fix this or try something else.
As ASLR is not new (or the only way to protect system), they (MS) can take peak on better implementation (same way as they do it usually).
MS also can leave it as is and ignore the problem.
“There’s no news like bad news”
Instead of perpetuating this notion, you could instead go to http://goodnewsnetwork.org and get some inspiration. (NOTE: I’m not related to the given site in any way, except as a user.)
Newsed up, we could all use a little happiness in our lives.
“Good news, everyone! I’m being brought up on disciplinary charges!
….er, wait, that isn’t good news at all!”
I wrote up a comment to a similar effect on the last story, summarizing the contents of the paper:
http://www.osnews.com/thread?326313
A bit of a plug but I figure most people had long moved on from the story by the time I made the post
The part the really irked me about this article is the instance that C/C++ are ancient languages and that if code were only written in the pure light of .Net or JAVA then security would be assured.
Yeah that irked me too, there are plenty of ways to write good, pretty safe, pointer burdened code in C and C++, utilising dynamic memory allocation, without incurring the overheads of garbage collection or excessive automatic compiler-inserted checks…
The ‘safety’ of the language really isn’t even one of the main appeals of C# or .NET.
Edited 2008-08-12 02:07 UTC
The ‘safety’ of the language really isn’t even one of the main appeals of C# or .NET.
It is one of the main appeals of .NET when you are talking about buffer overflows.
I found that notion hilarious when contrasted with further down in the article where it mentions that Java marks all it’s memory as executable. Heh.
This issue doesn’t do anything w/o other bad software. If you’re running other bad software you’re potentially (actually, probably) screwed anyways. (hope you have active defense, AV etc.)
The only thing this ever did, was make slighly bad software (they compiled with DEP support etc.) crash instead of root/access your box.
Alexander Sotirov is one of the authors of the “How to Impress Girls with Browser Memory Protection Bypasses” paper that had so many Microsoft haters orgasming in the “Vista’s Security Rendered Completely Useless By New Exploit” thread (http://osnews.com/comments/20167 ). Turns out those orgasms were premature.
http://arstechnica.com/journals/microsoft.ars/2008/08/12/black-hats…
Alexander Sotirov states:
“The articles that describe Vista security as “broken” or “done for,” with “unfixable vulnerabilities” are completely inaccurate. One of the suggestions I saw in many of the discussions was that people should just use Windows XP. In fact, in XP a lot of those protections we’re bypassing don’t even exist. XP is even less secure than Vista in this respect. [What] we established is that the security advantage of Vista over XP is not as great as [previously] thought. Vista is still very good at preventing vulnerabilities.”
Details are found here:
http://blogs.zdnet.com/Bott/?p=512
Edited 2008-08-13 18:40 UTC
Ah, excellent news that the facts are getting out. Sure it is unlikely to be reposted on most sites like Slashdot and OSAlert (as corrections are dull and non-sensationalistic ones are doubly so), but at least there are some very official statements to clear this whole confusion up. Makes my day
Well, I guess that was a stupid thing to say, as OSAlert already did correct the story by this one we are commenting on. Replace OSAlert with some other random site in the above