To be fair, it sounds like it uses a combination of an IE bug and Flash bug.
The exploit leverages a previously unknown use-after-free vulnerability, and uses a well-known Flash exploitation technique to achieve arbitrary memory access and bypass Windows’ ASLR and DEP protections.
...
The SWF file calls back to Javascript in IE to trigger the IE bug and overwrite the length field of a Flash vector object in the heapspray.
For now. Reading into it, it seems like they found one of the useful UAFs that facilitates a memory write instead of your less useful CALL virt_func. Flash is just a means to create an infoleak by over-wrting the vector length, it is likely that you could do the same without any dependencies by just targeting IE itself.
Sharepoint 2013 and SharePoint in Office 365 already work well in other browsers. I am using Office 365 in Chrome right now. About the only thing I can think of that doesn't work is to launch document synchronization with OneDrive, but that is basically a one time operation.
Practically every site on the internet has been recommending for years to not use IE for a variety of reasons. I'd be surprised if notions of security could somehow convince IE users to install a better browser.
You cant reconciliate mandatory IE6/8 and the need for security in the corporate world. I understand some corps cant upgrade because they have software that only runs on XP.By the way this is a direct consequence of MSFT rejecting web standards in the years 200X and going VB/activeX/non standard IE apis. Some web clients will never be updated and wont run in anything but IE6-8. Whereas if your devs tried to use cross browser features only in 2005,chances are your web app is future proof and needs little update. The irony is your 2005 flash site may still run, even today, on all desktop browsers.
It would really behoove MS to rethink their lack of XP support for a hole this big.
Edit for the multiple comments: Certainly, a corporate strategy can be "We don't care that your machine/network was compromised: We warned you."
There are other strategies, and perhaps the we-warned-you strategy is indeed the path to maximum corporate profit, but like I said above: It would be good to rethink that through entirely given the magnitude of the bug.
No. It would behoove all the XP users who have been warned for the past god knows how many years to move on, to, you know, move on. I know it's a loose analogy, but Heartbleed got everyone to upgrade their services overnight. Perhaps this security hole will get people moving off XP faster.
> Certainly, a corporate strategy can be "We don't care that your machine/network was compromised: We warned you."
Except they have an option available for die-hard XP fanatics: they can pay MS for extended support. A patch will be developed and paying customers will be able to install it.
I don't see any advantage to MS for continuing to support XP at no additional charge. They have newer products and a paid service offering that keeps XP viable. Supporting XP for "free" actually competes with their other products and gains them only what... good will amongst non-paying XP users? I doubt that is worth very much.
What makes you say that? Microsoft have been providing warning of XP going End of life for years now, and (AFAIK) they already supported it for longer than other OS vendors do for desktop OSs.
It hasn't been the current offering for them for 6 years and there's been 3 major releases since it...
Ultimately there's got to be a cut off for support of any software product...
It should end when XP's market share is vanishingly small. Given that as of a couple weeks ago it still has 27% among Windows users [1], we are nowhere near that point. Microsoft should do everything they can to help customers, especially corporate users, upgrade to the current version. Presumably they're already doing this, but in the meantime they should continue at least providing XP security updates given its sizable user base.
You have been warned about XP's end of support date for several years, on top of it corporate customers can buy updates directly from MS. I'm not seeing the problem, other than the public being irresponsible, which no corporate policy can cure. We can extend support another 6 months and be in the exact same place. There's no winning here.
I also find it hard to believe those old XP machines aren't compromised already. Worst case scenario is that they leave one botnet and join another.
Also, those stats are from web user agents, many bots use XP user agents, so we really don't know how many XP machines there are. I imagine most are corporate for compatibility reasons and are receiving patches. The rest are irresponsible people unwilling to upgrade and probably aren't running updated AV either.
At the very least this can be an opportunity to scare people into upgrading or at least switching to a non-IE browser and making sure their AV is up to date.
tldr; can't save the world and you can't save people from themselves
The point of the previous EOL extension was this, basically. What Microsoft figured out was that XP's market share was not going to appreciably shrink unless they let it finally reach end of life.
They will get patched on other OSes though. Only XP will remain vulnerable forever (or until people manually disable VML which will be annoying for web developers using VML as a canvas fallback)
More and more I'd wish MS provided a extra limited version of IE6+WinXP packaged in a sandboxed VM. Any group seriously needing IE6 would switch to a combination of a modern windows + the sandoxed VM. This could already be done now, but a more compact, efficient and blessed solution from MS could make a difference.
It's horrible to have IE6 or winXP only software, but instead of just throwing it away, putting it in a confined executing environment would help desl with issues pressing right now.
My understanding is that people who _need_ ie6 still need it exactly the way it is. Trying to strip stuff out or secure it would break why people need it just as much as upgrading it would.
Putting it in it's own VM would allow to keep IE in a perfect replica of it's current environment (same OS, libraries, plugins, helpers etc), while securing it from the outside (for instance firewalling, snapshot of valid states to prevent corruption, check on the data exchange on the network interface, sanitizing of the input/output if really needed)
Then have the VM be configured to only allow traffic to/from specific addresses/dns names/whatever. There has to be a way to solve this that doesn't involve running an ancient browser/OS combination as your host operating system.
I guess it's time for another one of my periodic rants about the importance of memory safety, and the undesirability of being left alone in the ring against a team of people who know the x86 architecture like you know the back of your eyelids, and who can slice your program like a piece of sushi and spread it all over printouts and wall diagrams in some apartment in Eastern Europe. Which by the way is what happens whenever you decide to write a user-facing program in a language in which you manage the memory, i.e. C and C++.
Last time, the technique was simple: OpenSSL gave anyone a piece of the process's memory for the asking. This time, we are talking about return-oriented programming. I know that all of us here are completely up to date on exploits and defenses, but let's refresh our memory: the most typical and serious exploit overwrites the return location of some function and points it to malicious data (i.e. code), which takes over your computer. After decades of exploits, a two-pronged strategy was adopted by most hardware and OS vendors: program code became non-modifiable (after the OS loads it and sets a flag), and data became non-executable. So the exploit writers gave up... we wish. The ROP technique involves finding "gadgets" in existing program code (which is already marked executable). These gadgets are an instruction or two which do something (change a register, say), followed by a return opcode which will transfer control to the next gadget, whose address has been placed on the stack due to the buffer overwrite. There are actually automated or semi-automated tools to find these gadgets in your code, and to compile code which is targeted to the virtual machine which is made up of these little broken-off pieces of your program. A single buffer overrun is then enough for the malware writer to start playing your program like a xylophone, jumping hither and thither, without changing its code, to perform a malicious task.
Address Space Randomization, a.k.a. ASR or ASLR, was supposed to save us from this, by making the locations of all code randomly determined at runtime. Then the attacker won't know the address of his gadgets. Except that anything which is loaded into the same space as your process (which is a HUGE amount of stuff) may leak the pointer to some function to the attacker (by placing it somewhere within reach, like on the stack), which enables him to build his xylophone out of pieces of the leaking library. Or he can try any number of other techniques to derandomize the base pointer to your code (remember, if his code crashes, many processes will simply respawn and he can try again). Or ASR might be turned off for one or more of the libraries in your process space - this happens a lot and you have no control over it.
One of the articles about this bug calls the address leak from the Flash plugin "well-known". Well, it's certainly not well-known to me, or was known at all until 10 minutes ago (it's not like I am an exploit writer). But it's apparently very well known to the people exploiting network-facing code.
Your choice is to let your language runtime manage your memory, or to face attacks of this sophistication, which by the way happen against obscure programs too (only we don't hear about them).
This is one of the reasons that I'm looking forward to Servo. They're taking advantage of Rust's ability to make these types of memory errors explicit (i.e. you have to ask to be unsafe). That should cause these kinds of bugs to be much much more difficult to crop up randomly.
Have they ever explicitly recommended against a browser/application like this before? Not sure if this is common verbiage in their alerts, or whether this is an unusual occurrence.
Since we're talking verbiage, the headline is slightly wrong. US-CERT recommends using EMET, but they merely ask you to consider an alternative browser until the issue is patched.
Where's all the big corporate sysadmins here today, saying we should all be running the same OS, same browser? Herd immunity is no immunity if everyone's vulnerable.
but I only need management tools with browsers to control IE-specific settings like trusted sites, compatibility lists, active-x settings, etc and only for IE-only websites that use that junk.
Other browsers "just work" as they're build on universal technologies that really don't need a "trusted sites list" or a 3 page document on a very specific active-x setting list to make some ridiculous feature work.
Fix your web apps. This culture of IE-only built apps only causes more security woes and more administrative headaches than needed. Sadly, its still 1998 in the corporate world.
That's fine and all but I need to have something that can run in a browser and communicate over a serial port. My two options there are an IE plugin/extension/addon or a Java applet. Personally, I find that writing an addon in C# to run in IE is the nicest, cleanest solution even though I generally dislike IE as a browser.
Pardon the vagueness.. but, this use case was a hosted web app, so it only exists in a browser. Some customers required the use of driver's license scanners in order to expedite their business process. Not using Active-X or something like it would've meant writing a whole new fat client UI for the group of users that needed the DL scanners. The simpler solution is to write a little shim and have the native code populate the previously existing form fields. Aside from feeling a little bit dirty, it worked pretty well.
How about anything. Try configuring browser settings in Firefox or controlling a Chrome updates. It's a mess.
Chrome sort of has group policy management, but it's buggy. If either browser had an API, IE would fade away -- this is literally the only reason it exists.
