
US-CERT recommends not using IE until use-after-free vulnerability is fixed - sajal83
http://www.us-cert.gov/ncas/current-activity/2014/04/28/Microsoft-Internet-Explorer-Use-After-Free-Vulnerability-Being
======
Torn
Analysis from the FireEye research team outlining how it's done:
[http://www.fireeye.com/blog/uncategorized/2014/04/new-
zero-d...](http://www.fireeye.com/blog/uncategorized/2014/04/new-zero-day-
exploit-targeting-internet-explorer-versions-9-through-11-identified-in-
targeted-attacks.html)

~~~
codeulike
TLDR: Its done with Flash. Quelle Surprise.

 _Disabling the Flash plugin within IE will prevent the exploit from
functioning._

~~~
tlrobinson
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._

------
ihsw
While they're at it, they should recommend businesses and government agencies
to not build IE-only web applications.

~~~
JTon
Yes, please. Although SharePoint has been my largest pain point. I'm not very
optimistic that will get better any time soon

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

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

~~~
Thrymr
Unfortunately IE is still required for a great many corporate intranets, and
users will tend to keep using it for external sites as well.

edit: If they even can install other browsers. If they're lucky they will have
a LTS release of Firefox available.

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

------
nnq
..fist time I've heard of EMET. Is it of any use to a regular (power)user?

~~~
KwanEsq
I'd say so, it's easy to set-up, and adds another layer of protection.

[http://support.microsoft.com/kb/2458544](http://support.microsoft.com/kb/2458544)

------
bananas
A company I deal with have the following mitigation in place:

Cross fingers until next Tuesday.

~~~
bradford
While you're probably joking, this seems incredibly incompetent since a better
mitigation exists:

Disable Adobe's flash plugin on IE.

~~~
bananas
Unfortunately I'm not joking. They have 2500 workstations running something
written in Adobe Air so no banana with removing flash.

~~~
Already__Taken
AIR should still run with flash. Just the IE plugin needs disabling you don't
have to remove flash.

~~~
bananas
The page they hit to launch it uses flash as well. The thing is a giant turd.
We're currently rewriting it.

~~~
Already__Taken
Can you register a custom protocol handler like air://example.com/airApp.air
and use that link?

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

~~~
higherpurpose
It's not just XP, though. This bug applies to all IE versions.

~~~
pilif
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)

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

Previous editions:
[https://news.ycombinator.com/item?id=7548991](https://news.ycombinator.com/item?id=7548991)
[https://news.ycombinator.com/item?id=2686580](https://news.ycombinator.com/item?id=2686580)

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

Maybe I'll write a FAQ about this...

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

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

~~~
SubZero
Its a fairly common recommendation for them to make, but don't let the
frequency dissuade you from following their advice.

------
adambware
Can they recommend people to stop using IE versions 6-9 altogether?

~~~
veidelis
Why do You think IE10 and IE11 are ok?

------
niels_olson
> consider employing an alternative web browser

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.

------
Spooky23
Too bad none of the other browsers play well with management tools.

~~~
metaobject
To which management tools are you referring?

~~~
callahad
I suspect the parent is referring to Windows Group Policies:
[https://en.wikipedia.org/wiki/Group_Policy](https://en.wikipedia.org/wiki/Group_Policy)

------
higherpurpose
Negative Microsoft stories seem to be flagged at rapid speed today.

------
circa
In other words.. be careful when downloading another browser.

