This article is more than 1 year old
You're doing open source wrong, Microsoft tsk-tsk-tsks at Google: Chrome security fixes made public too early
Redmond wags its finger
A few weeks ago, Google paid Microsoft $7,500 after Redmond's security gurus found, exploited and reported a vulnerability in the Chrome browser – a flaw that would allow malicious webpages to run malware on PCs.
Now Microsoft isn't entirely happy with the way Google handled it, and having been schooled a few times on security by the web giant, the Windows goliath has taken the opportunity to turn the tables and do a little finger wagging of its own.
As it turns out, the Chrome bug is pretty interesting. The Microsoft Offensive Security Research fired up its internal ExprGen fuzzer, normally used to hunt for vulnerabilities in Edge's Chakra JavaScript, and pointed it at Google's browser. The Redmond gang found that they could reliably crash Chrome's V8 JavaScript interpreter, but couldn't work out what the exact issue was.
They found that the Chrome programming cockup appeared in code dynamically generated by V8's just-in-time compiler, but only when, on a 64-bit Intel system, the processor's rax register was zero and used as a base pointer. This wasn't good news, because it looked like a classic null-dereference bug – rax had been set to null but used anyway – which is a pain to exploit because today's operating systems forbid access at and near address zero.
Google cyber-knight lances Microsoft for bug-hunter 'hostilities'
READ MOREThe issue was traced to a memory slot being used before it is initialized with a valid pointer, and the team found it could spray enough values over memory to fill in the slot with their own pointer. The team then found a way to exploit this to read and write as they pleased in memory. This arbitrary access was, as usual, the bridge the gang needed to place their own code in memory and then change a function pointer to that code, so it is executed by the browser. Now they have control of Chrome from data injected from a webpage: straight up remote-code execution, and a ticket to compromising the browser and potentially the underlying system.
You can read the full, highly detailed, explanation here.
Google fixed the issue within days of being alerted to the bug by Microsoft, and paid a bug bounty to the researchers, along with another $8,337 for other uncovered blunders. And the team may have been tempted to go for dinner and lots of drinks, but instead donated the dosh to charity. But while the problem was easy enough to fix, it was what happened next that had the Microsofties raising their eyebrows.
The team sent its bug report to Chrome engineers on September 14 and it was acknowledged and fixed within a week. The fix was pushed out to the public Chrome GitHub source code repository days before new builds featuring the security patch were released to the world. This approach, this delay between security fixes appearing in the GitHub repo and updated binaries going out to the public, Redmond felt, poses a real danger.
Eagle-eyed miscreants watching the GitHub repo can spot fixes applied publicly in the Chrome source code, and develop and deploy malware exploiting these bugs before people get a chance to download and install corrected versions of the browser. During that delay, their Chrome installations are vulnerable.
For example, the above V8 hole was fixed publicly in the source code here, and Chrome was updated and released three days later. Microsoft gave another example, though: this private security bug report with an accompanying public patch. The code wasn't released as a stable build until a month later.
On Wednesday this week, Microsoft team member Jordan Rabet said:
Servicing security fixes is an important part of the process and, to Google’s credit, their turnaround was impressive: the [V8 engine] bug fix was committed just four days after the initial report, and the fixed build was released three days after that. However, it’s important to note that the source code for the fix was made available publicly on Github before being pushed to customers. Although the fix for this issue does not immediately give away the underlying vulnerability, other cases can be less subtle.
Case in point, this security bug tracker item was also kept private at the time, but the public fix made the vulnerability obvious, especially as it came with a regression test.
This can be expected of an open source project, but it is problematic when the vulnerabilities are made known to attackers ahead of the patches being made available. In this specific case, the stable channel of Chrome remained vulnerable for nearly a month after that commit was pushed to git. That is more than enough time for an attacker to exploit it.
Somewhat primly, Rabet noted that Microsoft's own Chakra JavaScript engine is open source, and Redmond would never release a flaw report before it was fixed for just this reason.
"Some Microsoft Edge components, such as Chakra, are also open source. Because we believe that it’s important to ship fixes to customers before making them public knowledge, we only update the Chakra git repository after the patch has shipped," said Rabet.
"Our strategies may differ, but we believe in collaborating across the security industry in order to help protect customers. This includes disclosing vulnerabilities to vendors through Coordinated Vulnerability Disclosure (CVD), and partnering throughout the process of delivering security fixes."
Back in old Blighty, we'd call that a score draw, Google. The advertising giant did not respond to a request for comment. ®
Biting the hand that feeds IT
