Microsoft criticises Google for Windows 8.1 bug disclosure tactics

[Reefa]

Microsoft has criticised Google for its public disclosure of a Windows flaw, claiming the company's actions were irresponsible and benefited hackers.

Google disclosed a Windows 8.1 bug publicly last week having privately reported the vulnerability to Microsoft in September as a part of its ongoing Project Zero security initiative.

Project Zero is a security initiative launched by Google in July 2014 that initially discloses flaws in private to the firms concerned and gives them a 90-day deadline to release a fix before making the research public.

Microsoft Trustworthy Computing senior director Chris Betz criticised Google's January disclosure, claiming the firm had responded to Google's disclosure and was developing a fix in a blog post.

"[Google] has released information about a vulnerability in a Microsoft product, two days before our planned fix on our well-known and coordinated Patch Tuesday cadence, despite our request that they avoid doing so," he said.

"Specifically, we asked Google to work with us to protect customers by withholding details until Tuesday, January 13, when we will be releasing a fix."

He added that Google's actions would undoubtedly benefit hackers more than end users.

"Although following through keeps to Google's announced timeline for disclosure, the decision feels less like principles and more like a ‘gotcha', with customers the ones who may suffer as a result," he said.

"What's right for Google is not always right for customers. We urge Google to make protection of customers our collective primary goal.

"Even for those able to take preparatory steps, risk is significantly increased by publicly announcing information that a cyber criminal could use to orchestrate an attack and assumes those that would take action are made aware of the issue."

Betz said the disclosure is part of a wider issue with operations like Project Zero, arguing companies should instead follow a Coordinated Vulnerability Disclosure (CVD) policy.

"Releasing information absent context or a stated path to further protections, unduly pressures an already complicated technical environment," he said.

"It is necessary to fully assess the potential vulnerability, design and evaluate against the broader threat landscape, and issue a ‘fix' before it is disclosed to the public, including those who would use the vulnerability to orchestrate an attack."

Google had not responded to a request for comment from V3 when contacted.

Experts within the security community have been divided over the merits of public versus private disclosure policies for many years.

F-Secure security adviser Sean Sullivan told V3, while he is sympathetic to Microsoft's point, the firm should have made its argument earlier.

"Microsoft should have complained about Google's policy months ago if it has a problem with it. Google Online Security has recommended 60 days in some cases since at least May 2013," he said.

"On the other hand, just because Google discovered this vulnerability on September 30, 2014 doesn't mean it should disclosure exactly 90 days later - that's just evil.

"There's no reason Google's official formula can't be 90 days plus or minus some X number of days for the nearest scheduled monthly update."

Microsoft has been criticised for its slow response to privately disclosed flaws in the past.

The firm failed to patch a critical vulnerability in Internet Explorer 8 leaving users open to attack more than 180 days after researchers privately disclosed the bug in May 2014.

Source

[steven36]

New Windows 8.1 Security Flaw Disclosed By Google Security Team

Microsoft planned release of a fix on Patch Tuesday, two days after Google's date set for making the bug public

Security researchers at Google discovered a new elevation of privilege vulnerability affecting Windows 8.1, and revealed it to the public before Microsoft managed to release a patch.

If exploited, the vulnerability enables a lower privilege account to increase its rights on the machine to perform operations restricted to administrators.

This is not a critical problem on its own, but it can prove to be a valuable asset for an attacker that has exploits for flaws that could ultimately lead to taking control of the machine.

Bug is present at each log-in

When logging into Windows as a standard user, the User Profile Service is required to create the directory base profile under C:\Users for the account and to mount the registry hives with the user’s permission level.

In the case of an administrator user, only the directory base profile needs to be created because mounting the registry hives with the assigned permissions is already possible.

However, Google security researcher James Forshaw discovered that “the first few resources in the profile get created under the user’s token, but this changes to impersonating Local System part of the way through,” and that the “resources created while impersonating Local System might be exploitable to elevate privilege.”

He stresses the fact that the bug occurs at each user log-in and it is not part only of the initial process of creating a local profile.

Microsoft had three months to fix the problem

Forshaw identified several problems, one of them standing out as more serious. It refers to how the UsrClass.dat registry hive is handled and it is also present in Windows 7.

“The profile service queries for the location of AppData\Local from the user’s registry hive, then tries to create the Windows folder and UsrClass.dat file. By creating a new folder structure, changing the user's shell folders registry key and placing a junction in the hierarchy you can get this process to open any other UsrClass.dat file on the system, assuming it isn't already loaded,” he wrote in the vulnerability disclosure.

Google reported the elevation of privilege flaw to Microsoft on October 13, 2014, informing the company that there is a disclosure date set for January 11, 2015.

Google followed through with their disclosure policy, which gives companies 90 days to come up with a fix, and made the bug public on Sunday, also providing a proof-of-concept batch file that demonstrates one of the issues discovered.

Patch becomes available on Patch Tuesday

After confirming the vulnerability, Microsoft communicated to Google that it would be ready to ship a patch in February 2015.

The reply came that an extension would not be granted, regardless of the software vendor or the nature of the glitch and won’t be extended, resulting in making it public at the set date.

Microsoft then responded that the problem would be solved in January 2015. However, the update cycle for Windows is scheduled for the second Tuesday of each month, known as Patch Tuesday, which in this case meant that the date was just two days after the deadline imposed by Google.

Needless to say that Microsoft took offense at this behavior from Google. Chris Betz, senior director at Microsoft Security Response Center (MSRC) said that the customers are the ones who may suffer as a result of Google’s not being flexible enough to delay publishing the vulnerability details until the patch was pushed to consumers.

Source