* Microsoft Offensive Security Research (OSR) team decide to look for security bugs in Chrome
* OSR team uses internal JavaScript fuzzer (written by the team behind Chakra)
* They find a bug that allows them to make a memory read primative in javascript
* They report bug to Chromium
* Microsoft gets bug bounty from Google
* workaround bug fix to Chomium was committed just four days after the initial report, and the fixed build was released three days after that
They also noticed the bug was properly fixed in public source code repository for Chromium approx one month before getting fixed in release version of Chrome (that’s bad!)
hmmm, the cve database shows Edge with 104 code execution bugs for 2017. Chrome has 4 for the same period.
For information leaks Edge shows 19 for 2017, chrome at 10.
Of course maybe Edge's techniques are good and other browsers should adopt them but at least looking at the CVE database it does not seem like Edge is doing a very good job at being secure.
This article seems to be focused on what happens when that number is non-zero, whether 4 or 104. Given a bug, how to ensure that an exploiter does not gain privileged access?
So yeah, Edge clearly has a way to go in patching holes, but CVE count is not the entire story, either.
Most vulnerabilities are listed as: "allows an attacker to execute arbitrary code in the context of the current user". So it would seem that Edge is good at preventing elevated privileges.
However, I don't care at all about elevated privileges. If a bug in my browser allows code executing, that means that code is executing with my privileges. So all my data is already at risk. And my data is basically the only thing that's important. Becoming part of a botnet or the propagator of virusses is annoying at worst. Ransomware or my data leaking out is infinitely worse.
And Edge seems to exceptionally horrible at preventing code execution. Perhaps their security team should focus on that for a bit.
I couldn't agree more. In fact I run browsers as separate users to prevent direct access to my data, although they still have access to my X server and could dangerously tamper with other clients.
Edge seems to be less secure by any objective measure: CVE count, Pwn2Own contests, audits, etc.
So far I'd say it's pretty clear the stronger isolation model works better than the multiple-mitigation techniques model, even though Edge actually has some relatively strong sandboxing, too, which makes the ineffectiveness of its mitigation mechanisms even worse.
Also, as they say in this post, Google is already developing an even stronger isolation model that would have prevented this type of attack. It's just not fully tested and enabled yet.
Finally, Google seems to dedicate more people for patching Chrome, or at least it has a system that fixes bugs much faster than Microsoft does in Windows. One of Edge's main weaknesses is that it essentially works as a part of Windows, not as a third-party app. This is something I've criticized them for since when they first announced Edge and said this was a mistake precisely because of this reason, of being tied to Windows updates, and thus slower to improve.
I don't really care about the part where they're supposed to wait for Google to fix it or whatever. I don't know the details for this, but I believe Google waits on some bugs for 90 days and on some highly-critical ones, like bugs being exploited in the wild only 7 days. But I suppose that's also a pretty arbitrary number, so I don't know if I should be upset at Microsoft for releasing the bug sooner than that.
All in all, it's actually pretty cool that Microsoft and Google are attacking each others' products like this. It keeps both on their toes, at least I would hope it does. I just wanted to point out that Microsoft is being rather misleading in this post when it's implying that Edge's model has better security. Chrome's security is not bulletproof but it seems to have proven itself to be quite good so far.
It's also why I was hoping Mozilla wouldn't make those "best of both worlds" compromises between sandboxing and saving 30% memory. Is saving 30% memory worth having your browser twice as exploitable? Maybe it won't be that exploitable, so we'll see. Firefox may also be able to make up for the weaker sandboxing with the Rust rewrites, but only time will tell.
> Also, as they say in this post, Google is already developing an even stronger isolation model that would have prevented this type of attack. It's just not fully tested and enabled yet.
Note that Site Isolation has to run every origin in a separate process to be maximally effective, which nobody has demonstrated a feasible way to do at scale yet. The plan as I understand it is to run just "high-value sites" in separate processes.
> It's also why I was hoping Mozilla wouldn't make those "best of both worlds" compromises between sandboxing and saving 30% memory. Is saving 30% memory worth having your browser twice as exploitable? Maybe it won't be that exploitable, so we'll see. Firefox may also be able to make up for the weaker sandboxing with the Rust rewrites, but only time will tell.
Where did you get the idea that Firefox is not committed to strong sandboxing?
It's a bit scary that a blog article that includes working proof-of-concept code is out there while the update has not even fully rolled out yet...
That's even worse than the Git commit.
> A better implementation of this kind of attack would be to look into how the renderer and browser processes communicate with each other and to directly simulate the relevant messages, but this shows that this kind of attack can be implemented with limited effort. While the democratization of two-factor authentication mitigates the dangers of password theft, the ability to stealthily navigate anywhere as that user is much more troubling, because it can allow an attacker to spoof the user’s identity on websites they’re already logged into.
Stealing the active sessions is bad enough already...
The whole idea of splitting up a complex software in multiple small processes that do one thing but do it very well is the Unix philosophy all the way.
Isn't this ironic, even hypocritical, that while they mock how chrome publicly discloses vulnerability before patch, they themselves do something even worse by publishing this blog before it was fixed, with thorough explanation of everything, also saving significant amount of the research effort for those would-be-attackers they pretend to be so concerned about.
This is such a cheap PR stunt this is disgusting. They can pretend their motives are to improve security but you would be naive not to realize their real motive is just to shove their edge in your face, showing 0 regard to the security of their own customers in the process.
I wonder if their security research team funding comes from their advertising budget, because it should.
Microsoft didn't publish the blog before the bug was fixed:
"Servicing security fixes is an important part of the process and, to Google’s credit, their turnaround was impressive: the bug fix was committed just four days after the initial report, and the fixed build was released three days after that."
It doesn't come from their advertising budget and even the Google Project Zero team has called this great research that they want to see more of, while also saying that they expect that the MS team will get the same dumb comments that the Google team gets about how what they are doing is a stunt or is somehow "wrong".
* Microsoft Offensive Security Research (OSR) team decide to look for security bugs in Chrome
* OSR team uses internal JavaScript fuzzer (written by the team behind Chakra)
* They find a bug that allows them to make a memory read primative in javascript
* They report bug to Chromium
* Microsoft gets bug bounty from Google
* workaround bug fix to Chomium was committed just four days after the initial report, and the fixed build was released three days after that
They also noticed the bug was properly fixed in public source code repository for Chromium approx one month before getting fixed in release version of Chrome (that’s bad!)