Skip to content
Naked Security Naked Security

Google drops new Edge zero-day as Microsoft misses 90-day deadline

Microsoft wasn't able to come up with a patch within Google's non-negotiable "you have 90 days" period, so the flaw is now public.

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 2017, 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 is 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 have 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.
Just 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 depends 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.


Does Google holds itself to the same standards? If they find a bug in their own Chrome browser, would they release it to the world if they missed their own 90 day deadline?


If Google is so strict on this why don’t they hold Cell Phone Vendors and Providers to the same standard over Android flaws that take months, years, or quite often never get sent to users? Seems hypocritical that they allow Android devices to remain unpatched for well after the 90 day mark.
And yes I understand that creating a patch and delivering said patch to the end user are technically different. But the end result is the same. What good is a patch that never makes it to the device due to incompetence or indifference of the phone oem and the carrier? Not everyone can afford $1,000 cell phones every year or so. Users shouldn’t be forced to buy those overpriced and overhyped high end phones just to get security updates in a timely fashion.


You can’t tell me that a giant like Microsoft wouldn’t have had the resources to fix that bug within the 90 day window if they really wanted to. It may have turned out more complicated than they anticipated, but they probably also didn’t put as much priority on a fix as they should have. If Google would have given them more time, they wouldn’t change that in the future. Now they might.


You might be right, who knows, but more resources does not necessarily lead to faster execution or higher quality (as made famous by the Mythical Man Month).


That is true of course. I just think 3 month is a lot of time, and they should have plenty of experienced people to have a good estimate on how much work fixing this bug might be. I don’t think Google chose the 90 days arbitrarily either.


Obviously you have never written a complex program. Fixing obscure bugs could be tricky. First, you need to fix the bug without adversely affecting the operation of the software. Second and more importantly, you have to ensure as much as possible not to introduce new security holes into the software. These can’t be rushed and are not always possible within an arbitrary time frame imposed by a competitor.
On another note, no amount of self-proclaimed righteousness justifies exposing innocent users to unwarranted risks just because the ETA of the fix is a few days after the end of the “allowed” grace period.


I never said it can’t be tricky. But if you can’t fix a bug in 3 months, with Microsofts ressources, how is anyone ever supposed to fix anything. And if Google would extend their deadline for some cases it would make their program useless in the end, as everyone would try to get an extension rather than get on a fix asap. And given enough time, the chances that some crooks already know about a vulnerability also increases even if it isn’t disclosed. So I wouldn’t 100% call it “exposing innocent users to unwarranted risks” because the risks are there to begin with, and them knowing about it may be worth something too. For example, they could stop using the software until the actual fix is here.


I still like Edge, although I appear to be a minority these days it does what I need it too. Stopped using Chrome because couldn’t tolerate the creepy stuff Google does with my data. Maybe a safe secure browser but privacy not so much. Every browser faces potential exploits and you can live month by month by which one is safest this month. Or pick one and do your diligence at staying safe online. For myself, Chrome is such a big target these days with such a big market share. Sort of like Internet Explorer once was.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!