Four RCE Zero-Day Flaws Plague Internet Explorer (opens in new tab)

At some point I prototyped a tool that used Ron Rivest's timelock puzzles (repeated squaring modulo the product of two large safe primes takes a long time and isn't parallelizable, but is quick to compute if you can factor the modulus) to encrypt compressed tarballs of zero-day disclosures.

The idea would be that if you found a vulnerability in a product whose vendor was likely to pour more money into gag orders and legal threats than into fixing the vulnerability, you would publish the vulnerability encrypted in such a way that it would take several years of continuous computation to get the decryption key. Legal threats and/or general foot dragging couldn't put the cat back in the bag.

Sometimes I regret not publishing the tool.

I'm sure there's a lot that goes into fixing these, but Adobe surprised many in the security community with their fast and responsible reaction to the zero-day flaws unveiled by the Hacking Team leaks.

Microsoft has the resources to fix these; I'm not sure what their excuse is (and it may be valid), but vulnerabilities like this should take highest priority.

This is standard description of a UAF (use-after-free) flaw. Reliability can vary from "30% of the time, it works every time" to perfectly reliable. It just depends on the instance of the bug. It is one of the most common exploitable bug classes found via fuzzing.

Because so many browser fuzzing crashes are UAFs, people have put a lot of effort into developing reliable techniques for exploiting them.

See e.g: http://www.rapid7.com/db/modules/exploit/windows/browser/ms1... for a reasonably reliable example.

"but can anyone suggest how much risk is in these risks."

Twenty years ago maybe this argument carried the day. Don't even consider using it today. The tooling, techniques, and skill are far higher than you could dream if you are not in this world.

This is not quite the same thing we are talking about, but let me give you a different example. An obscure cross-site-scripting attack is no big deal, right? Well, courtesy of BeEF [1], if the XSS can be leveraged to get you to download a script, which is a low bar, BeEF can then be used to proxy web access in, allowing an attacker to lever up from "small XSS" to "crawling your intranet with the internal credentials of the compromised user".

Yow!

Do not ever count on difficulty of exploit as a defense anymore. In many cases the reason why these people aren't providing off-the-shelf exploits for this sort of thing isn't that it's too difficult to make practical, it is that in the security world it is now too trivial to be worth spelling out. Attacker capabilities (and pen testing capabilities) have skyrocketed in the past ten years, but the defense team still for the most part is operating like it's 1995 and the idea that a program might be used on a network is still like some sort of major revelation.

(I'm on the defense side personally. It feels about like this: https://youtu.be/MPt7Kbj2YNM?t=2m11s In theory, I am powerful, in theory I control the field, in theory all the advantages should be mine, but....)

[1]: http://beefproject.com/

Usually you set these up by aggressively spraying the heap by allocating objects so that copies of the code you're trying to execute are thousands or more of places that are also aligned to the page boundary. The heap doesn't do things that are that random (depending on how new the browser is, obviously) so the intention is to make it so your free'd object is replaced with an evil one that has a malicious virtual memory table and will jump somewhere in that heap (to a specific address which will work if you sprayed the heap correctly, and sometimes to one which is calculated with ASLR.)

If you get to an attacker controlled website, it shouldn't be that hard to pull off most of the time, though definitely not deterministic.

(Man, remind me to check that this isn't all horribly wrong after defcon...)

There is an entire industry of exploit frameworks waiting for this sort of thing to be slotted in and then deployed on compromised ad network servers to download CryptoLocker or similar for-profit malware. Things can go bad very quickly.

Since IE11 comes with Windows 10 - yes.

I find it hard to believe this is a lack of engineering talent. MS has some extremely talented people and has pushed out some very neat security stuff well before, say, Apple has. I cannot believe MS has people sitting around saying "well darn we just don't know how to fix this bug for 6 months now". There's gotta be more to the story... I hope.