US-CERT recommends not using IE until use-after-free vulnerability is fixed

Cross fingers until next Tuesday.

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.

Previous editions: https://news.ycombinator.com/item?id=7548991 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...

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.