STE WILLIAMS

Google’s Project Zero team has dropped a Microsoft Edge bug for the world to see.

Google originally shared details of the flaw with Microsoft on 17 November 2018, but Microsoft wasn’t able to come up with a patch within Google’s non-negotiable “you have 90 days to do this” period.

Ironically, Google may give you a 14 day grace period to extend the deadline to 104 days, but if you admit you aren’t going to make it within 104 days, you don’t get any of the extra 14 days of non-disclosure.

Last week, right at the 90-day deadline, Google quoted Microsoft as saying:

The fix is more complex than initially anticipated, and it is very likely that we will not be able to meet the February release deadline due to these memory management issues. The team IS positive that this will be ready to ship on March 13th [2018-03-13], however this is beyond the 90-day SLA [service level agreement] and 14-day grace period to align with Update Tuesdays.

As a result, Google published details of the bug immediately, so Microsoft Edge users are now adrift without a patch for nearly a month.

How bad it it?

Fortunately, this bug isn’t a remote code execution exploit all on its own.

It’s a security bypass that could allow an attacker who has already wrested control from your browser to vault over Mirosoft’s second layer of defence, known as ACG, short for Arbitrary Code Guard.

ACG is supposed to head off remote code execution attacks before they can make any headway.

Even if a booby-trapped web page, image, or script manages to wrest the CPU away from Edge in an effort to grab control, ACG means that the attack can’t easily transfer control to malware of its own choice.

That’s a bit like having a backup security system at home that throws a net over crooks who manage to pick your front door lock and get into your house: they’re already in, which is bad, but their hands are pinned to their sides, so they can’t pick anything up or open any more doors, which is good.

Very simply put, ACG works by locking down the memory that Edge uses to run its own software code.

In theory, an attacker who gets control via a web page that Edge just loaded:

• Can’t modify executable code that’s already in memory.
• Can’t allocate new memory blocks in which to store rogue code.

But today’s browsers aren’t that simple: Edge itself (in common with Chrome, Firefox, Safari and others) includes what’s called a Just-In Time compiler, or JIT, that can convert remotely-provided JavaScript programs from interpreted source code into native binary format.

This conversion happens on demand while you’re browsing, so the JIT-generated code is created and executed after the browser itself has loaded.

In other words, the browser needs to be able to allocate new memory blocks for executable code, and to modify those blocks at runtime…

…but it also needs to stop attackers who has already compromised the browser from creating their own blocks of executable code.

Microsoft therefore elected to separate Edge’s own “shove new code into memory and run it” JIT feature from the rest of the browser by running the JIT compiler in a separate process.

But Google researchers nevertheless found a way to guess roughly where Edge’s JIT compiler was going to allocate new memory, and to exploit it that way.

Jut to be clear, though: you need to find a remote code execution vulnerability (RCE) in Edge first.

This ACG bypass doesn’t give you remote code execution on its own.

Should Google have waited?

Google’s approach is that 90 days ought to be enough for anyone to fix any security bug, so after 90 days it’s OK to reveal publicly how the bug works.

The theory is that by ‘dumping’ bugs according to an inflexible algorithm, you can never be accused of favouritism by giving some companies more time than others.

This means that the pressure of unwanted disclosure – the stick that you’re wielding in the hope of forcing software vendors not to sweep bugs under the carpet – is unswervingly objective.

But there’s a somewhat inhuman aspect to bug-dumping-by-numbers.

What you might call Google’s soulless approach doesn’t differentiate between a company that’s not trying and has missed the deadline because it simply doesn’t care about security, and one that has been trying hard but hasn’t quite made it in time.

Of course, rules are rules, so you can argue that Google is right to apply this one without fear or favour.

On the other hand, you can argue that Google is being high-handed by applying its own opinion in the first place as if it were an objective industry-wide standard.

Should you stop using Edge?

As explained above, this hole doesn’t give crooks a direct way to take over your browser immediately.

Simply put, you can regard it as a vulnerability that could make a bad thing worse, rather than a bad thing in the first place.

Nevertheless, keep your eyes open for Microsoft’s forthcoming patch.

For all you know, Microsoft might yet get a fix out before next Patch Tuesday, so watch this space, and grab the patch as soon as it’s available.

PS. We were wondering if turning off Edge’s Just-In Time compiler would prevent this bug from being exploitable – because the sequence of operations on which it dependa would then never arise. We can’t find out how to turn off the JITter, or even if it’s possible, let alone whether it would work if it were. If you have any hints for a workaround, please let us know in the comments.

Follow @NakedSecurity
Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/gwHpj6uUm-s/