A specially crafted web page can cause a content security policy bypass resulting in an information leak. An attacker can create a malicious webpage to trigger this vulnerability.

He included technical detail on how to pull off the CSP bypass – he said attackers could create a data disclosure in Edge if they modified the CSP header with the “unsafe-inline” directive to allow inline script code.

And perhaps to lend some support for his conclusion, Grødum noted that a similar flaw existed in earlier versions of Apple’s Safari and Google Chrome, which both companies patched.

Grødum, who made the vulnerability public this last week, included a timeline that said he had notified Microsoft on November 28 last year, but was told in March that the “vendor says this is by design and does not consider it a vulnerability”. He asked the company to reconsider, and wrote on June 7 that Microsoft had re-opened the case to do so. But after more than two months went by without any further response, he went public.

There is still no official response from Microsoft so far (we tried), so that is apparently how it stands. The bug, or the feature, will remain – at least until the next version of CSP is made official. CSP2 is the current standard, while CSP3 is in draft form.

But a bit of the company’s rationale came from a source who would be identified only as “a middleman”, who said:

This behavior was undefined in CSP2, which has been used by modern browsers across the industry.

The severity of the issue is low since it requires a modifier on the policy that relaxes it. In order to address this, some have implemented a draft of CSP3.

Given the low severity and draft state of CSP3, we will intend to implement CSP3 when the standard is final.

According to “the middleman” there is no word on when CSP3 will be finalized.

Microsoft had posted a statement at the beginning of the year announcing its support for CSP2, calling it “another step in our ongoing commitment to make Microsoft Edge the safest and most secure browser for our customers. CSP2, when used correctly, is an effective defense-in-depth mechanism against cross site scripting and content injection attacks.”

All of which sounds like another example of the ongoing debate about compliance standards. One side says if organizations have met the letter of the law in a standard, then they have taken all reasonable measures to make their products secure. In this case, Microsoft said the vulnerability that Cisco Talos describes is “undefined” in the current standard.

But that, observers have been preaching for decades, amounts to a “check-the-box” security mentality. Their argument is that “compliance is not security”, and that what is intended as a security floor too often becomes a ceiling.

The dispute over the severity of the Edge vulnerability is not the only one for Microsoft this past week. Security firm enSilo reported it had found a kernel bug that it said affects Windows versions going back 17 years, from Windows 2000 to the current Windows 10.

They said the vulnerability affects PsSetLoadImageNotifyRoutine, a function that should notify registered drivers in different parts of the kernel when a PE image file has been loaded. But, they said, “after registering a notification routine for loaded PE images with the kernel, the callback may receive invalid image names”.

2 comments on “When is a bug not a bug? When Microsoft says ‘it’s a feature’”

Microsoft does not like to be reminded that some of their code has bugs. Ran into a bug in Winword on an IBM 3270 PC many years ago. The bug was reported and documented with a repeatable example. It took 2 new releases before the bug was fixed.