Vista's Security Rendered Completely Useless 415
scribbles89 sends in a story that originally ran in SearchSecurity; it sounds like it could be a game-changer. "While this may seem like any standard security hole, other researchers say that the work is a major breakthrough and there is very little that Microsoft can do to fix the problems. These attacks work differently than other security exploits, as they aren't based on any new Windows vulnerabilities, but instead take advantage of the way Microsoft chose to guard Vista's fundamental architecture. According to Dino Dai Zovi..., 'the genius of this is that it's completely reusable. They have attacks that let them load chosen content to a chosen location with chosen permissions. That's completely game over.'" Update: 08/08 14:23 GMT by KD : Changed the link, as the story first linked had been lifted without attribution.
Well.... (Score:2, Interesting)
".NET loads DLLs into the browser itself..." (Score:4, Interesting)
So in other words, like 80+% of the other exploits on web, the exploit only works if you use Internet Explorer?
Re:Details... (Score:5, Interesting)
In the days of the Web there is a rule that if someone tells the press before they publish the paper, they are full of it. They haven't told Microsoft, so they can't even claim that they are not releasing the details to allow for a fix.
CF all those 'studies' that 'prove' porn is bad or watching TV turns kids into Martians or whatever. Every time that stuff hits the press the paper is 'to be published' which is a good way to prevent opponents getting in a response.
Re:Before the Slashdotters rip this article apart. (Score:5, Interesting)
I suspect you're right. Reading the article, it sounds like they have a way of using browser plugins as a way to get around the address space randomization features in Vista. That's a big deal, and it really might be as hard to patch as they claim. But address space randomization was never a silver bullet and even without it, all they've done is put is back to a Windows XP world.
What would be interesting is if they can extend the attack to Linux, which also does a certain amount of randomization. If they can do that, then they've got a reusable, general purpose attack. But, as it stands, it certainly doesn't sound like anything too new. People have been attacking Flash, ActiveX, Java applets, and other plugins for years.
Re:Details... (Score:4, Interesting)
Well, if they can really get past "all memory protection safeguards", that means the code can just overwrite your running kernel. I doubt that sentence was really intended to say that, though. it probably means specifically the ones new to Vista over XP that were listed.
Re:Vista "Shatter" Attack? (Score:5, Interesting)
It definitely sounds like a shatter attack [wikipedia.org], but I thought that Vista's new security model was supposed to prevent this. (No, not being facetious, I really thought this).
I sense a new alert message in your future... (Score:3, Interesting)
Hmm... (Score:5, Interesting)
Looks to me more like a .NET and IE design flaw that could be easily fixed, than what this article is making it out to be. ABSOLUTE worst case is that it requires better authentication of the system's own code, which... shit, isn't that already part of Vista's security model? Just expand the scope. (Granted, THAT could break stuff.)
And, there's even a quick and dirty fix Microsoft could do, albeit at a possible extreme performance hit.
Sandbox .NET apps, don't trust any of the framework.
It could break OLE horribly, but not if they do it right - and how much is old-school OLE used anyway? And, for ActiveX plugins that are also used as standalone apps (such as Adobe Reader,) just fire up a second copy of the process in the sandbox.
An incredibly worrying response from Microsoft (Score:5, Interesting)
From TFA:
"While Microsoft hasn't officially responded to the findings, Mike Reavey, group manager of the Microsoft Security Response Center, said the company has been aware of the research and is very interested to see it once it has been made public."
So, Microsoft is
a.) Not currently aware of the details of the exploit and
b.) Doesn't plan (or, apparently, want) to GET the details until the details are PUBLISHED.
Apparently, Microsoft's "Security Response Center" has no idea that they have a window of opportunity to fix the problem BEFORE the details are in the wild. Why would we want that? Nah, we don't need to be pressing for details. We'll figure it out when our customers start screaming about exploits.
I've thought MS was somewhat incompetent on security, but this is mind boggling.
Re:Yeah, wasn't there some important necessity... (Score:5, Interesting)
TFA does imply that the exploit takes advantage of an assumption at the OS level that .NET objects are automatically safe, and gives them the same privileges as the browser itself. It also says that the exploit takes advantage of a multi-homed attack using different scripting methods. Given that information, I'd venture a wild-assed guess that the exploit most likely uses JAVA and/or ActiveX to load a downloaded/forged .NET object which in turn loads arbitrary code as described.
If there's truth to the assumption about .NET objects, then it's a monumentally stupid decision on Microsoft's behalf. But there is a (temporary) fix that can be patched into the OS by requiring a signature. Yes, those can be forged. Yes, it's a stop-gap measure. But if you require authentication from online servers (remember, this is a drive-by online exploit, so it's safe to assume that anybody who needs to validate a signature like this has Internet access), then it is an improvement until it can be fixed properly.
IT DOESNT JUST AFFECT VISTA (Score:1, Interesting)
At least potentially. That's the whole point. I'm seeing a lot of comments saying this is just MS bashing or that "I have Firefox and Noscript, I'm safe" and so on.
You Are Missing The Point
The *entire* point to this being a problem is a *process* problem not a *code* problem. It is a methodology. Technically, it is actually patentable in the USA. The specifics on what you'll do to launch the attack will change based on the platform, but the actual attack *plan* remains the same.
In otherwords, this is a *design* flaw, and one that Microsoft is not alone in making.
I'm very interested in seeing the work on this. They're right in that it has the potential to change the entire playing field. Note, that's *potential* not a guarantee. At the moment we see attacks based on a specific code base. You go after one platform using one app and make a specific attack. Maybe you get lucky and more than one app has that vulnerability. Or maybe you design it to go after a specific OS because it handles code a certain way that leaves it vulnerable.
In both those situations, you have a short window before it gets patched once its discovered what you are doing. That's where this all changes. This doesn't care what OS you are running nor what app you are using. There have even been a few viruses that can make the hop out of a VM box so combine the two and even people that use VMs to browse the web are vulnerable.
I bring that up because Microsoft is putting a lot of virtualization in Windows7. Who wants to bet that IE in Windows 7 runs in a VM to sandbox it?
Anyways, until we get the finite details play it safe. Do not just shrug this off. If it is what it promises, we're in for a heap of trouble until we can find a way to counter it. If it IS all that it promises that may mean a new OS is required (and this will be *great* for FOSS).
Hopefully you folks are right, and its just hype. But this is a threat with some serious potential and it won't affect "just Vista boxes."
Re:Details... (Score:3, Interesting)
Re:Details... (Score:2, Interesting)
Neowin Plagiarists? (Score:5, Interesting)
Too funny, not on is this article blog spam, it's plagiarised blog spam!
This comment is at the bottom of their board.
nice
Is this really a surprise? (Score:3, Interesting)
XP was vaunted as Microsoft's most secure operating system ever. And it was, for about a year. Then it went through several really horrible security incidents. Eventually the holes were patched and, even though XP will never be anyone's idea of a secure operating system, at least we know where XP's weaknesses are and how to mitigate them.
So now we're finding the Vista security holes. I'm sure there will be a stretch of security horror shows and we'll figure out how to run Vista in a semi-secure fashion. At least we'll know where the vulnerabilities are.
It's really nice running Linux when things like this come along. You can watch in a detached, slightly amused fashion. Although I'm sure our day will come.
But not today. :)
This is not strictly Microsoft's fault... (Score:5, Interesting)
... although a large part of the blame does rest with them.
The real problem with Windows security is that there are LOTS of programs out there that will not run unless the user is an administrator.
This is a relic of the old MS-DOS mindset, where any program could put anything anywhere on the disk that it wanted to, or mess with anything in memory that it wanted to. This attitude moved along with the coders to the Windows platform, so you have programs that try to put log files in the same directory as the executable instead of in the user's home directory. When the user calls support and asks how to fix this, the fastest way to get them off the phone is to say "run as administrator", so that's what happens.
Microsoft's part of problem is that rather than saying "Don't do that - fix your program so it can run under a normal user account", they made it so you can run as administrator, and then tried to intercept user actions that might hose things up.
Re:So, um... (Score:1, Interesting)
Re:Dai Zovi is Completely Wrong (Score:3, Interesting)
"using a variety of scripting languages, such as Java, ActiveX and even .NET object"
I gave up the credibility of the author just after that sentence. But the topic is of major interest regardless of the stupidity of the author. Slashdot at work, we flame the authors and discuss the topic anywho.
Re:Details... (Score:5, Interesting)
OpenBSD uses ksh. Bash isn't installed by default, and iirc goes into /usr. In any case, scripts should only assume that /bin/sh is available.
Clever, but not devastating (Score:5, Interesting)
This presentation was how to get around features that try to prevent exploitation of memory safety bugs [squarefree.com] in applications. The intent of these features is that even if you find a buffer overflow in Notepad, you won't be able to do anything other than make Notepad crash.
These compiler and OS features try to disrupt the exploitation of memory safety bugs in various ways. Some work by detecting memory corruption (e.g. checking "stack cookies" before returning from a function that uses a string buffer). Others work by making it hard for an attacker to place shell code at a predictable memory address (e.g. DEP [wikipedia.org] or ASLR [wikipedia.org]).
The presenters demonstrated clever ways to get around many of these protections, but by showing how tricky it was to do so, they actually showed how effective the protections are against applications other than web browsers. To create memory that was both under their control and marked as executable, they had to take advantage of weird behavior of .NET controls (IE-only), Flash, and Java applets. The .NET control behavior looked like a bug Microsoft could fix without breaking any controls, since it involved lying about the .NET version a control was created for. The Flash behavior (a missing compiler flag) is already being fixed. The Java issue is that all Java memory is marked as executable; I don't know how hard that would be to fix, but I imagine most Slashdot users don't have to worry about this because they have already disabled Java applets.
I don't think this is devastating even to web browsers. I work on Firefox, and I know these protections haven't made us complacent about looking for and fixing memory safety bugs. Meanwhile, not all web browser security holes are memory safety bugs, so most browsers all have automatic update systems in place to ensure users receive new versions quickly.
(I attended the Black Hat presentation but did not read the full paper [taossa.com].)
Re:Dai Zovi is Completely Wrong (Score:4, Interesting)
Re:Yeah, wasn't there some important necessity... (Score:3, Interesting)
If there's truth to the assumption about .NET objects, then it's a monumentally stupid decision on Microsoft's behalf.
It's not stupid. It's just Microsoft.
They never really learned the lesson of allowing ActiveX in browser. They still go through pains of flagging all possible ActiveX components as not accessible from browser - instead of flagging the ActiveX components which are allowed to be loaded in browser.
Apparently, the same now happening with .Net stuff.
Re:Sceptically speaking... (Score:2, Interesting)
I would treat this 'news' with a healthy dose of scepticism for now. It looks like the standard shit-talking that goes ahead of all major black-hat conferences.
Are the speakers at black-hat conferences known for spouting crap? I would think they wouldnt put those kind of claims without proof.
Re:Details... (Score:5, Interesting)
From reading this, it seems to me that what they published is code that, one by one, bypasses every memory protection feature on Vista. This means a process that is allowed to start, using these techniques, can get full system privileges.
However it does still require that code be run in the first place. The document does include apparently recent exploits, for JavaScript, Flash, .NET, for recent versions of IE and Vista.
The question is, do they work on other browsers? For example, the .NET code probably wouldn't. The JavaScript exploit relies on filling the IE heap with 100mb of code, which I'm not sure would work on Firefox.
So the bottom line is that before, if an exploit broke through IE, it landed with user-based privileges on the system. Using this code, an exploit that breaks out of IE lands with Admin access.
Is this a foreshadowing of cloud computing issues? (Score:2, Interesting)
Re: It doesn't require a bug in the browser... (Score:3, Interesting)
The browser could be secure, but because it allows optional on/off status of plugins, BHOs, JVMs, etc, it was still insecure overall.
I really think the lesson here is: Security Should Not Be A Compiler Option.
Imagine the next update to GNU C:
gcc -IEn myhack.c -o crashit
(Make this app as insecure as IE version 'n')
in windows xp these flaws are always exaploitable (Score:2, Interesting)