Forbes: Lazy Vulnerability Reporting & A Bit of Bias

It may have been almost two decades ago, I joked with colleagues that many Information Security news articles could just be done via Mad Libs. We later joked that breach notifications often appeared to be done via Mad Libs, using the same phrases with different organization names and the number of affected customers. Over the last few years, it seems Forbes has gotten lazy in their reporting on computer vulnerabilities.

First, a bit of background by querying Risk Based Security’s VulnDB, which I work on. While we track news articles on vulnerabilities, it is important to note that it is done in a best faith effort. We try to capture higher profile articles in the bigger publications within InfoSec and those outside the proverbial “echo chamber”, which includes Forbes, New York Times, Washington Post, Fox, etc. So by no means is this comprehensive, but it is important to understand the methodology which is using Google Alerts based on “CVE” strings. This started several years ago, maybe around 2015 give or take. Articles included before that were as they came across social media, referenced in modern disclosures, or some other current manner despite the publication date.

The first Forbes article we have associated goes back to June 17, 2001, covering a vulnerability in a GE Healthcare device. Up to 2010, almost every Forbes article we have is in a GE device along with one about Oracle and one about Linux Kernel. That alone is kind of interesting. From 2010 to 2020 we have Forbes articles covering a wide variety of vendors including Google, Onity, GE, Apple, Magento, PLX, and more. They also included articles covering big disclosures that covered multiple vendors of DVR systems, SIM cards, micro processors, and more. Last year, in 2020, Forbes produces a steady stream of articles for all the big vendors including Cisco, Microsoft, Apple, Google, Intel, Citrix, Zoom, and more.

This year though, it seems like Forbes got lazy. Perhaps it is burnout writing what is essentially the same article? You might think that, but no, because that is exactly what they started doing. Coverage is heavily based around Google Chrome and components in it, but disclosed via Google Chrome’s blog. Of the 48 vulnerabilities in 2021 cataloged by VulnDB, that have an associated Forbes article, only 12 are in non-Chrome products. What’s the gist of their coverage? Here’s three examples, see if you notice the similarities.

You may see the common phrase, “2 Billion Chrome Users”. Don’t worry, in a recent article that got increased to 2.6 billion! If it isn’t in the headline, you can find the phrase in almost every article talking about Chrome vulnerabilities. I get that these articles are repetitive, because there are only so many ways you can say Google fixed vulnerabilities in their browser.

That said, what’s more interesting to me is that they appear to have a single similar article for Mozilla Firefox vulnerabilities in all their time while continuing to encourage users to ditch Chrome. If I didn’t know better, I might think Forbes has chosen a side in the browser wars.

My Photography is Popular

According to Ken Rockwell, via the first result of a Google search, the definition of a professional photographer is someone:

.. who earns 100% of his income from photography. This is the definition required for entrance into the secret Nikon and Canon factory support organizations. People who earn less than 50% of their income from photography are amateurs.

I am not a professional by that standard, but I had to look because I was curious if viewership mattered. That came after Google notified me that another one of my photos had been viewed over one million times via the exciting subject line of “A lot of people are seeing your photo on Google Maps!

I’m sure there are some amazing photographers that sell their works in stores that have been seen by tens of thousands of people, and yet my quick shot of a local Qdoba has somehow been viewed by that many? That’s about 25% of the population of the greater Denver metro area.

I’ve long thought that these mails and such numbers are wrong, but no way to prove it. There certainly isn’t one million actual humans that interested in the local Qdoba. That means there is likely a lot of automated scraping of images or applications that load it for other purposes. I’m sure there is a blog out there explaining this but I think I would rather enjoy the notion that my photography is just that awesome.

[Update: As I suspected, something else going on. Gillis explains why the numbers are high: “Comes down to the manager of the Google maps business listing. Each “view” of a business counts as a image view if you’re one of the top 6 images for the business. Whereas if you’re ‘below the fold’ views only come if folks scroll down to your pic“. He goes on to sayOh yeah, you’re the main image for the business. So everytime someone tries to navigate there manually, you get a view.” So basically, that manager owes me free queso and chips.

Search Speak for Automaton

Alternate titles for this blog could be “Doodle Transition for Machina” perhaps! For at least a decade I have thought about just such an application and today I have Google Translate for Android. Load, aim, and it will process the text and translate on screen for you. Given the state of technology you would think it would be amazing by now, and it sometimes is.

The success largely depends on the language and that can also be seen in using translate.google.com, where some languages will translate fairly cleanly and others are very rough. One language I have to translate frequently is Chinese (simplified) and it is problematic for many things including company names and technical terms. With that in mind, I would expect it to translate with the same issues via the Google Translate app, and more specifically, do so consistently.

Since I am writing this, you know what’s coming…

This is the result of holding the phone up to a mail label from Japan. That’s all! Just moving the phone ever so slightly by tilting it or moving it half an inch closer / farther will make it change the translation. I think it finally got it a bit correct on that last one since the envelope didn’t contain anything living.

Hopefully the translation technology from Google will advance more quickly on Asian languages. Until then, I am just glad I didn’t get any “Sunrise Holy Poop” in that envelope.

Thoughts on 0-days and Risk in 2020

[Stupid WordPress. This was scheduled to publish Nov 23 but didn’t for some reason. Here it is, a bit late…]

On Friday, Maddie Stone from the Google P0 team Tweeted about the 0-day exploits her team tracks. As someone who checks that sheet weekly and tracks vulnerabilities, including ones ‘discovered in the wild’, this is a topic that is squarely in my tiny niche in the industry. Also, big fan of the P0 team!

I replied to her Tweet suggesting it come with a disclaimer that it didn’t represent “all” 0-days, rather they tracked high-end 0-day used primarily in “APT” attacks. Ben Hawkes, manager of the team, replied and agreed with that assessment. Before we proceed, let’s define 0-day real quick since the term is used for a variety of vulnerabilities, often incorrectly.

In this case, the context is a 0-day is a vulnerability that was actually found being exploited in the wild before there was public knowledge of it. In Risk Based Security’s VulnDB, we track that as “discovered in the wild“. Since VulnDB is comprehensive and our goal is to track every vulnerability, regardless of software or severity, we tend to aggregate a lot more than others. As of this post, we have over 78,000 vulnerabilities that aren’t found in CVE / NVD as a point of comparison. In my reply to Maddie I pointed out that we had seen 51 this year compared to their 22.

Next, Allen Householder replied to me asking a fun point, which is how many vulnerabilities did that really represent. Out of the 20,000+ vulnerabilities aggregated in 2020, we have 51 that are flagged as “discovered in the wild”. That represents only 0.25% of all vulnerabilities this year. One point I made previously is that Google’s team likely doesn’t care about a 0-day in the “Adning Advertising Plugin for WordPress” despite it being used to compromise WordPress blogs.

So with that number in mind, it goes back to the narrative that companies need to be scared of 0-days. They absolutely do! But… and this is the big qualifier that needs to come with that fear, is that perhaps they don’t need to be as afraid of 0-days as they do of already public vulnerabilities that they missed. With only 51 0-days in 2020, that means a vast majority of organizations simply aren’t likely to be targeted. Fully patching all known vulnerabilities that impact them should be priority one.

More to the point, vulnerabilities that have functional public exploits allowing anyone to trivially launch a viable attack are consistently a much bigger risk than the elusive 0-days. That is also one reminder of how often times CVSS falls short, if your vulnerability intelligence doesn’t provide Temporal scoring or exploit availability. Organizations making risk decisions only using the CVSS Base score are missing out on an important risk attribute.

I’ll end this blog with some arbitrary statistics around 0-days for fun! These are based on VulnDB data as of 11/21/2020. Note that metadata is less complete before 2012, which includes ‘discovered in the wild’ classification.

  • 241,690 vulnerabilities, only 641 are 0days (0.27%)
  • 14 are in Google products: Chrome (5), V8 (3), Android (6)
  • 146 are in Microsoft products: Windows (63), IE (36)
  • 13 are in Apple products
  • 7 are in Oracle products: Java (4)
  • 62 are in Adobe products: Flash (38), Reader (14)
  • 18 are in security products 😞
  • The oldest is from 1975 in RSTS/E! Yes, for real.
  • The oldest you likely recognize is Sendmail in November, 1983

An Analysis of Google’s Project Zero and Alleged Vendor Bias

[This was originally published on RiskBasedSecurity.com.]


Google announced a new initiative called Project Zero. The basic premise of the project was that Google invests heavily in their own security and had for quite some time been also tasking their researchers part time work on improving the security of other high-profile products.

Project Zero is Google’s investment into a well-staffed team that they hoped to get the ball rolling as they felt that people “should be able to use the web without fear that a criminal or state-sponsored actor is exploiting software bugs to infect your computer, steal secrets or monitor your communications.” Recently, there have been questions that have been raised wondering if Google’s Project Zero is really unfair towards and targeting Microsoft?  

From reading several news articles as well as the blog from Microsoft’s Chris Betz, who runs their Product Security Response, you would definitely think that this is the case. Since Project Zero was announced, we at Risk Based Security have been following it closely as we were interested in how it might influence vulnerability research. More specifically, we were curious if the project would help improve the code that many rely on such as third-party libraries and if it might ultimately impact the Bug Bounty economy.

With all of the recent conversations about Project Zero, we decided to publish some of our own analysis of with an attempt at using data to see if there is a bias towards targeting Microsoft, or any other company. One of the great things about Google and Project Zero is that they are generally pretty transparent with their research and try to clearly communicate their intentions about disclosure as well. But have they really been clear with their disclosure policy?

We know there is a 60-day Google company-wide intention for security disclosures that was published back in July, 2010. But what about the policy for Project Zero? We aren’t aware of a clear policy that has been published for the project or any sort of blog post on the requirements (nothing on their main blog, or the wiki in their tracker). In a Wired article last year, it mentions that Google staff stated:

“… they’ll alert the company responsible for a fix and give it between 60 and 90 days to issue a patch before publicly revealing the flaw on the Google Project Zero blog. In cases where the bug is being actively exploited by hackers, Google says it will move much faster, pressuring the vulnerable software’s creator to fix the problem or find a workaround in as little as seven days.”

Based on reading the individual tickets you can see that they have been communicating the 90-day policy since ID 44, opened on Jul 9, 2014 and since ID 89they have been very consistent about telling all vendors about the 90 day deadline and started automatically including the boilerplate text:

“This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.”

In the initial announcement of Project Zero, there was no mention of a hard line of 90 days for a disclosure timeline, but it does mention they want to get things fixed in a “reasonable time”:

“Once the bug report becomes public (typically once a patch is available), you’ll be able to monitor vendor time-to-fix performance, see any discussion about exploitability, and view historical exploits and crash traces. We also commit to sending bug reports to vendors in as close to real-time as possible, and to working with them to get fixes to users in a reasonable time.“

Chris posted a blog update in November 2014, where he highlighted many bugs that were fixed well within Project Zero’s 90-day disclosure deadline and that it represented a solid security response by the teams responsible for Adobe Flash, Microsoft Office, Internet Explorer, and Microsoft Windows. A more important point to mention is the following:

We calibrate our deadline to balance two important factors: the right of end users to know about a risk versus giving vendors a fair chance to cleanly fix a bug under a reasonable embargo. Given the ratio of deadline hits to misses, we think we’ve calibrated correctly for the current state of the industry but we do hope to tighten the deadline in the future.”

It seems that they could benefit from posting a formal policy at some point in the future to clarify their disclosure process, but regardless, they have been making vendors well aware of their expected timelines. What we can say with certainty is that by publishing details about their research, it allows us to get a better insight into their work, their focus, as well as a limited view of their interaction with vendors. 

Show Me The Data

Project Zero has a tracker that they show their work in, and in some cases publish very detailed information for us to see their process. As of January 25, they have assigned 206 IDs in their tracker. One aspect that was not clear is the reason that so many IDs, especially earlier assignments, were restricted, meaning they were not open for viewing to the public. We speculated that these restricted IDs were ones that Google was not sharing for some specific reason, as they could have just been IDs that have been abandoned, or they were still being resolved with the affected vendors.

Considering they still have “Issue 1: This is a test” public, it didn’t seem that they were cleaning up older entries that are not relevant. We decided to reach out to Chris Evans who runs the Project Zero team asking for clarification on why so many entries were restricted, and he responded very quickly offering some great insight on the situation. Chris shared that most of the early IDs that are shown as restricted were due to a bunch of spam reports that were received when the project was officially launched.  He mentioned that there are a few other causes of early bugs not being made public.

  • The first few IDs were not filed as well as the project team would have liked, so they filed a new ID again and marked the earlier issues as invalid.
  • A couple more bugs were marked as duplicates because they unfortunately filed the same report twice.
  • There were a few more issues that he shared were valid, but just needed to be made public. In fact, our mail prompted him to open up (ID #125) which he described as “a very interesting Flash bug that has been fixed several days ago”. We thank Chris for opening it up tonight, even though it made us redo our statistics!
  • And finally, as we expected, every ID currently from 144 onwards is still less than 90 days old which aligns with their stated 90 day disclosure timeline.

When looking at the 206 Project Zero IDs, the breakdown of tickets is as follows:

ID Status# of Vulnerabilities
Total Fixed83
Total WontFix4
Total Restricted73
Total Invalid26

  The “WontFix” designation means that the vendor does not consider the reported issue to be a security problem, or does not cross privilege boundaries.  In terms of the severity and impact to organizations of the vulnerabilities that they have discovered, we looked quickly at the VulnDB assigned CVSSv2 score for each ID.

cvss

For those that don’t like seeing just a CVSSv2 average (as there are currently still a lot of issues with this version, and a new version hopefully around the corner), we pulled more data from VulnDB to help us understand Exploit availability.

Note that the high percentage of Proof of Concept (PoC) is largely due to Google researchers developing them to demonstrate the vulnerability, which typically makes it easier for the vendor to diagnose and understand the problem.

Microsoft

As mentioned, there are theories being voiced that Google is specifically targeting Microsoft and not practicing Coordinated Vulnerability Disclosure, putting customers at risk.  A post from ErrataRob reminds us that Microsoft seems to be enjoying a double standard with their views on vulnerability disclosure. Additionally, it has been noted that Microsoft’s latest plea for CVD is as much propaganda as sincere, in a response to Microsoft’s Betz’s article published on the OSVDB blog. It is important to understand where this perception comes from.

Articles posted like the one from PC World that talk about a “third unpatched Windows zero-day” being released within a month is polarizing in the context of the vulnerability disclosure debate. It also makes it sound like this is a straight rivalry with one party intent on hurting the other. From what we can see by analyzing the data, this doesn’t appear to be the case. The disclosures are a byproduct of Google’s stated policy of disclosing after 90 days, fix or no fix. The use of “0day” denotes that Google published full details of the vulnerability (after ~90 days) without a vendor-supplied fix available.

StatisticsMetric
Total 0Day19 Vulnerabilities
Average Disclosure Time59.68 Days

It is critical to remember that not all vulnerabilities are created equal, even within the same organization. While Microsoft may be able to patch a particular product such as Office or Internet Explorer quickly, they may not be able to do the same for Windows depending on the numbers of platforms and versions affected. The life cycle of a privately disclosed vulnerability varies wildly as it has to be confirmed, patched, and then heavily tested.

Organizations want and really need Microsoft to test those patches adequately before releasing, or you run into updates that can do more harm than good. So this supposed “vulnerability disclosure war” as some are calling it between two companies is also mixing in one Google employee’s spare time activity with his day job.  No matter how many times someone may say that “their thoughts and tweets do not represent their employers”, it can be a very fine line specifically when you are a researcher working for a company where a strong focus is on discovering vulnerabilities in other company’s products. It can lead to questions as to what constituents their employer’s versus their own time, and is it decided who has ownership when it is more convenient. This is especially true since that researcher’s day job and hobby are heavily intertwined.

In doing further analysis on the Google Project Zero tracker, we find that they have disclosed 20 vulnerabilities in Microsoft products as of this blog. Of those 20, Microsoft labeled 4 as ‘WontFix’ (they don’t consider them to be a security issue, and Google actually agrees with most), 13 were fixed within 90 days, and 3 were released without a fix due to the 90 day deadline being exceeded (the dreaded 0day!).  On the surface, considering ~81% have been handled in a coordinated fashion that actually makes it seems Microsoft is doing pretty well. Not only have they gone through the process with Google many times already, they are obviously well aware of the 90 day disclosure deadline.

While it is still debatable that Google should provide extra time for companies when requested, it has become clear that this is not an option in the eyes of Project Zero. Since Microsoft now knows that Google is basically not flexible on that deadline, the onus is solely placed on them moving forward. If Microsoft does not want to have a 0day disclosed by Project Zero they are going to have to determine how to improve their response timeline and potentially dedicate more resources to a given vulnerability than they have for the three that were not fixed in time. It would be hard for anyone at Microsoft to argue that producing secure products isn’t critical and that they are short on resources to correct known vulnerabilities that may impact their customers. But the real question that begs to be asked; is Microsoft all alone in this supposed ‘war’ and being unfairly picked on by Google? Again lets take a quick look at the data to help us answer the question:

Vendors# of Vulnerabilities
Apple39
Adobe36
Microsoft20
Linux Kernel7
LibreSSL2
glibc1
PHP1
Red Hat1

The data suggests that there is a simple answer; of course Microsoft is not being solely targeted. In fact, just a few days ago, Project Zero hit the 90 day deadline on a trio of Apple Mac OS X issues that went public without a fix. Ars Technica covered it in the same style as other articles covered the “0day” dropping on Microsoft.  We found it very interesting that there is no mention in this article that these aren’t the first Google Project Zero “0day” dropped against Apple. In fact, between July 4, 2014 and September 30, 2014, Google released eleven vulnerabilities in Apple products without a patch.  While Apple and Microsoft have each had “0day” issue due to missing the timeline.  

We are also able to see that Project Zero has sent a substantial amount of  vulnerability reports to the Adobe Flash team and they’ve hit all the deadlines, which is very impressive. That was the initial reason that prompted Brian Martin, our Director of Vulnerability Intelligence to really dig even further than we had previously into all of the public Project Zero vulnerabilities. The analysis focused on the vendor, vendor notification date, disclosure date (when the vulnerability was disclosed, which was by Google for some, and by the vendor for others), CVSSv2 score and exploit availability. 

Conclusion 

From our analysis of available information, we believe it removes some of the emotional arguments and allows one to make their own educated statements which appear to support that Google is not singling out Microsoft with their Project Zero efforts. Furthermore, it shows that  Apple has received the most attention with Adobe close behind, both of whom have received considerably more attention than Microsoft. It just appears at this point, Microsoft is the only vendor that is failing to meet the 90 day disclosure deadlines sometimes, and then publicly criticizing Google for their work (or as some may say, providing free security work to improve their products and ultimately ensure their customers are better protected).

We sincerely hope that cooler heads will prevail as we all work together to better secure our organizations and protect consumer confidential information. Google’s work at Project Zero is impressive, and clearly making a positive impact on the security of high-profile products. We hope that companies will continue to work with Google and understand the importance of fixing issues as soon as possible to reduce the time of exposure customer’s face. But as with all policies, there are times when some level of flexibility does make sense when the purpose of the project is to improve security.

If you look at companies that Google has recently acquired, such as Dropcam, even their disclosure policy states, “We ask that you give us a reasonable amount of time to respond to your report before making any information public”. Of course, “reasonable amount of time” has been the cornerstone of the coordinated vulnerability disclosure debate for decades and doesn’t appear to be going away anytime soon.

[Update: Since starting a dialogue with Chris Evans, 24 issues have been published in the last 15 hours. Some of the stats quoted in this blog are already considerably different (e.g. Time to disclose). Further, we are now tracking additional information with each entry in order to generate more metrics.]

Microsoft’s latest plea for CVD is as much propaganda as sincere.

[This was originally published on the OSVDB blog.]

Earlier today, Chris Betz, senior director of the Microsoft Security Response Center (MSRC), posted a blog calling for “better coordinated vulnerability disclosure“.

Before I begin a rebuttal of sorts, let me be absolutely clear. The entire OSVDB team is very impressed with Microsoft’s transition over the last decade as far as security response goes. The MSRC has evolved and matured greatly, which is a benefit to both Microsoft and their customers world-wide. This post is not meant to undermine their efforts at large, rather to point out that since day one, propaganda is still a valuable tool for the company. I will preface this with a reminder that this is not a new issue. I have personally blogged about this as far back as 2001, after Scott Culp (Microsoft at the time) wrote a polarizing piece about “information anarchy” that centered around disclosure issues. At some point Microsoft realized this was a bad position to take and that it didn’t endear them to the researchers providing free vulnerability information to them. Despite that, it took almost ten years for Microsoft to drop the term “responsible” disclosure (also biased against researchers) in favor of “coordinated” disclosure. Again, Microsoft has done a phenomenal job advancing their security program, especially the last three to five years. But… it is on the back of a confrontational policy toward researchers.

Reading yesterday’s blog, there are bits and pieces that stand out to me for various reasons. It is easy to gloss over many of these if you aren’t a masochist and spend most of your waking time buried in vulnerability aggregation and related topics.

In terms of the software industry at large and each player’s responsibility, we believe in Coordinated Vulnerability Disclosure (CVD).

Not sure I have seen “CVD” as a formal initialism until now, which is interesting. After trying to brand “information anarchy” and pushing the “responsible disclosure” term, good to see you embrace a better term.

Ultimately, vulnerability collaboration between researchers and vendors is about limiting the field of opportunity so customers and their data are better protected against cyberattacks.

And this line, early on in the blog, demonstrates you do not live in the real world of vulnerability disclosure. Microsoft has enjoyed their ‘ivory’ tower so to speak. Many researchers find and disclose vulnerabilities for entirely selfish reasons (e.g. bug bounties), which you basically do not offer. Yes, you have a bounty program, but it is very different from most and does not reward a vast majority of vulnerabilities reported to you. Microsoft has done well in creating a culture of “report vulnerabilities to us for free for the honor of being mentioned in one of our advisories”. And I get that! Being listed as a creditee in a Microsoft advisory is advertising itself as far as researcher talent. However… you are talking about a minority of researchers in the greater picture, that chase that honor.

Those in favor of full, public disclosure believe that this method pushes software vendors to fix vulnerabilities more quickly and makes customers develop and take actions to protect themselves. We disagree.

Oh sorry, let me qualify, your black and white tower. This absolutely does work for some vendors, especially those who have a poor history in dealing with vulnerability reports. You may not be one of them for the last 10 years, but you once were. Back in the late ’90s, Microsoft had a reputation for being horrible when dealing with researchers. No vulnerability disclosure policy, no bug bounty (even five years after Netscape had implemented one), and no standard process for receiving and addressing reports. Yes, you have a formal and mature process now, but many of us in the industry remember your beginnings.

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.

This is a great point. But, let’s read on and offer some context using your own words…

Of the vulnerabilities privately disclosed through coordinated disclosure practices and fixed each year by all software vendors, we have found that almost none are exploited before a “fix” has been provided to customers, and even after a “fix” is made publicly available only a very small amount are ever exploited.

Wait, if only a very small amount of vulnerabilities are exploited after a fix, and ‘almost none’ are exploited before a fix… why do you care if it is coordinated? You essentially invalidate any argument for a researcher coordinating disclosure with you. Why do they care if you clearly state that coordination doesn’t matter, and that the vulnerability will “almost [never]” be exploited? You can’t have this both ways.

CVD philosophy and action is playing out today as one company – 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.

And this is where you move from propaganda to an outright lie. The issue in question was disclosed on December 29, 2014. That is 15 days, not two days, before your January patch Tuesday. I’d love to hold my breath waiting for MSRC or Betz to explain this minor ’rounding error’ on dates, but I have a feeling I would come out on the losing side. Or is Microsoft simply not aware of public vulnerability disclosures and should perhaps invest in a solution for such vulnerability intelligence? Yes, blatant sales opportunity, but they are desperately begging for it given this statement. =)

[Update. Apparently Microsoft is unhappy over Issue 123 which was auto-published on January 11, as opposed to Issue 118 linked above auto-published on December 29. So they are correct on two days, but curious they aren’t complaining over 118 at the same time when both are local privilege escalation vulnerabilities.]

One could also argue that this is a local privilege escalation vulnerability, which requires a level of access to exploit that simply does not apply to a majority of Windows users. Betz goes on to say that software is complicated (it is), and that not every vulnerability is equal (also true), but also glosses over the fact that Google is in the same boat they are. A little over four years ago, the Google security team posted a blog talking about “rebooting” responsible disclosure and say this:

As software engineers, we understand the pain of trying to fix, test and release a product rapidly; this especially applies to widely-deployed and complicated client software. Recognizing this, we put a lot of effort into keeping our release processes agile so that security fixes can be pushed out to users as quickly as possible.

To be fair, Google also did not publish a timeline of any sorts with this disclosure. We don’t know anything that happened after the September 30, 2014 report to Microsoft. Did you ask for more time Google? Did Microsoft say it was being patched in January? If so, you look like total assholes, disclosure policy be damned. If they didn’t mentioned January specifically and only asked for more time, maybe it was fair you kept to your schedule. One of the two parties should publish all of the correspondence now. What’s the harm, the issue is public! Come on.. someone show their cards, prove the other wrong. Back to Microsoft’s blog…

What’s right for Google is not always right for customers.

This is absolutely true. But you forgot the important qualifier; what is is right for Microsoft, is not always right for customers.

For example, look at CVE-2010-3889 (heavily referenced) aka “Microsoft Windows on 32-bit win32k.sys Keyboard Layout Loading Local Privilege Escalation”. This is one of four vulnerabilities used by Stuxnet. Unfortunately, Microsoft has no clear answer if this is even patched, four years later. That CVE identifier doesn’t seem to exist in any Microsoft security advisory. Why not? Did you really let a vulnerability that may have aided an attack on an Iranian nuclear power plant go unpatched? Think of the ethics questions there! Or is this a case of the Microsoft security response process not being as mature as I give them credit, and this is a dupe of CVE-2010-2743? Why does it take a third-party four years to figure this out while writing a blog on a whim?

It is a zero sum game where all parties end up injured.

What does this even mean, other than propaganda? It is rarely, if ever, a case where “all parties” are injured. If a researcher discloses something to you and publishes prematurely, or publishes on their own without contacting you, usually that party is not ‘injured’ in doing so. That is simple fact.

Betz’ blog goes on to quote the Microsoft CVD policy which states:

Microsoft’s Approach to Coordinated Vulnerability Disclosure
Under the principle of Coordinated Vulnerability Disclosure, finders disclose newly discovered vulnerabilities in hardware, software, and services directly to the vendors of the affected product; to a national CERT or other coordinator who will report to the vendor privately; or to a private service that will likewise report to the vendor privately.

Perhaps you should qualify that statement, as US-CERT has a 45 day disclosure policy in most cases. That is half the time Google gave you. Quoting from the US-CERT policy:

Q: Will all vulnerabilities be disclosed within 45 days?
A: No. There may often be circumstances that will cause us to adjust our publication schedule. Threats that are especially serious or for which we have evidence of exploitation will likely cause us to shorten our release schedule. Threats that require “hard” changes (changes to standards, changes to core operating system components) will cause us to extend our publication schedule. We may not publish every vulnerability that is reported to us.

Note that it does not qualify “the vendor asks for more time”. That is the United States government saying a vendor gets 45 days to patch with rare exception. Oh wait Mr. Betz, before you go quoting “changes to core operating system components”, I will stop you there. Vulnerabilities in win32k.sys are not new. That 3.1 meg binary (on Windows 7) is the cause for a lot of grief for Windows users in that file alone. Given that history, you cannot say that changes to that file meet the US-CERT criteria.

Finally, this isn’t the first pissing match between Google and Microsoft on vulnerability disclosure. While Microsoft has routinely played the victim card and Google certainly seems more aggressive on their disclosure policy, there is a more than one bit of irony if one looks deeper. In random order…

Microsoft disclosed a vulnerability in Google Chrome, but didn’t do proper research. This vulnerability may be in WebKit as one person notes, meaning it could affect other browsers like Apple Safari. If it does, then Apple would get blindsided in this disclosure, and it would not be ‘coordinated’ or ‘responsible’, and would qualify as ‘information anarchy’ as Microsoft once called it. While we don’t know if it was ultimately in WebKit, we do know this vulnerability exists because Google Chrome was trying to work around issues with Microsoft software.

Look at MSVR11-011 and MSVR11-012 from 2011, where Microsoft “coordinated” two vulnerabilities with the FFmpeg team. To be sure, the FFmpeg team is outstanding at responding to and fixing vulnerabilities. However, in the real world, there are thousands of vendors that use FFmpeg as a library in their own products. While it may have been fixed in the base code, it can easily take somewhere between months and a decade for vendors to learn about and upgrade the library in their software. Only in a completely naive world could Microsoft call this “coordinated”.

Even better, let’s go back to the inaugural Microsoft Vulnerability Research (MSVR) advisory, MSVR11-001. This was a “Use-After-Free Object Lifetime Vulnerability in Chrome” that in reality was a vulnerability in WebKit, the underlying rendering library used by Chrome. The problem is that WebKit is used by a lot more than Chrome. So the first advisory from MSVR conveniently targets a Google product, but completely botches the “coordinated” disclosure, going to a single vendor using WebKit code, because the Microsoft researchers apparently didn’t diagnose the problem fully. No big deal right?

Wrong. I am sure Adobe, Samsung, Amazon, Tizen, Symbian, BlackBerry, Midori, and Android web browser users would disagree strongly. Do you really want to compare the number of users you blindsided with this “coordinated” disclosure to the ones you protected? Microsoft was a bigger jackass on this disclosure than Google ever was, plain and simple.

Finally, do I even need to go into the absolute mess than you call the “Advanced Notification Service” (ANS)? In case readers aren’t aware, this is not a single program. This is several different programs with various names like MAPP and others. Just three days ago, you Mr. Betz announced that ANS was changing. This is after another program got changed drastically, multiple companies were kicked out of the MAPP program, and who knows what else happened. All of which was founded on Microsoft giving advanced and sometimes detailed vulnerability information to questionable companies, that may not be friendly parties.

The entire notion of “coordinated” disclosure went out the window as far as Microsoft goes, when they first implemented these programs. You specifically gave a very limited number of organizations details about vulnerabilities, before other customers had access. That, by definition, is not coordination. That is favoritism in the name of the bottom line, and speaks strongly against any intent you outline in yesterday’s blog post.

While Microsoft has taken great effort to improve their security process, it is disingenuous to call this anything but propaganda.

Stop Using Google, It’s Dangerous!

[This was originally published on the OSVDB blog.]

Reported Phishing/Vulnerable Site! The web site http://www.google.com has been reported as a vulnerable site that may pose a threat to your web browsing. Vulnerable sites do not prioritize security and don’t care about their users and customers. These sites may pose a risk to you, exploit the trust between you and their site and may cause your computer to perform actions you did not approve.

To carry on the scary wording in the style of others; Some web sites are high profile and may seem trustworthy, but you shouldn’t trust them at all. They are full of buggy code, don’t care about protecting their users (that’s you!) and generally suck. Despite using their site as a virtual crutch, you should clearly stay away from them unless it is to send nasty mails or mock them. Again, do not trust Google’s web sites or search engine, because they have been known to be vulnerable. What assholes!

On a more serious note, if anyone at Google is reading this, I hope you pass this on to the jackasses that develop Google Toolbar or whatever hook they use to integrate with Firefox. Not only is it worse than malware (every piece of software tries to get me to install it), it uses misleading wording to scare customers from visiting perfectly safe and innocent web sites (namely this blog). While it caters to morons, it doesn’t give users a real opportunity to learn why a site was ‘blocked’ other than vague wording in the diagnostic page:

My only guess as to why this warning occurs was an incident earlier this year, in which the OSVDB blog fell victim to a zero-day exploit in WordPress. I blogged about the incident to make our readers aware of the incident and clear up any confusion. I assume that Google’s crawl of the this blog noted the script code and subsequently declared us an “attack site”, even though that is hardly the case.

The discouraging part is the “diagnostic page” says that Google visited ONE page in the last 90 days and 0 of those pages resulted in malicious software being downloaded. Google, if you are going to play Lord of the Browser, visit more than one page before you make that determination. To do anything less is a disservice to your users and a fast way to miss obvious malware. The third question mentions “intermediary” which is technically accurate as far as the script code that was injected in a few blog posts. However, the big red warning says nothing about ‘intermediary’ and explicitly labels us as some kind of malware hosting site with the intent of attacking people. That is libelous to say the least. Under ‘How did this happen’, Google mentions that sometimes third parties can inject such code, but doesn’t take the time to help clear this up. If the previous script injection issue is the cause of this, the fact that the script loaded content from a third party domain (in China no less) should be a good indication that WE did not host the malware. Sure, most users are dumb as a rock, but the few smart cookies that click for details should get just that.. details.

What Google Toolbar users may see when visiting this blog:

Finally, I opened the blog post calling Google’s search engine a threat, and I was serious. Google has a track record of vulnerabilities far worse than OSVDB does. Not only in their popular search engine, but their various products too. Besides, the mechanism for reporting potentially dangerous sites is a bit dubious to say the least.

Update: Ends up, we had another iframe injection into one of our posts (which is now removed), and the hunt for how this is happening now begins. That said, while Google’s warning that this site is “dangerous” may have been accurate, their mechanism for warning users in a vague manner (as shown in the image linked off ‘vague warning’) and not warning the site administrator is far from friendly. I can see that Google doesn’t care about warning sites of issues before warning the public, a far cry from ‘responsible disclosure’, something that Google pretends to care about:

This process of notifying a vendor before publicly releasing information is an industry-standard best practice known as responsible disclosure. Responsible disclosure is important to the ecology of the Internet. It allows companies like Google to keep users safe by fixing vulnerabilities and resolving security concerns before they are brought to the attention of the bad guys. We strongly encourage anyone who is interested in researching and reporting security issues to observe the simple courtesies and protocols of responsible disclosure.

Next time OSVDB is informed of a vulnerability that impacts Google products or services, I sure hope it doesn’t slip our mind to contact them. Perhaps the apparent race condition between the vague wording and the not-so-vague wording (below) that users may see constitutes a bug. If they can read this blog, they can see the bug in action and then contact us if they have more questions.

Update 2: Google apparently tried to send mail to our domain: From: Google Search Quality

OSVDB Chosen for Google Summer of Code 2007

[This was originally published on the OSVDB blog.]

For the second year now, OSVDB has been selected to participate in the Google Summer of Code program. It’s pretty neat to be in this program along with other relatively unheard of projects like Debian, FreeBSD, GNU, KDE, NetBSD, OpenSolaris, PHP, PostgreSQL, Python, Samba, Apache, EFF, Fedora and X.org. =)

As always, Google continues to give back to the community in ways most companies will never understand or appreciate.

Google VulnSearch?

[This was originally published on the OSVDB blog.]

Fall behind and someone will always beat you to the punch! Gadi Evron posted an entry over at Securiteam on the topic of using Google’s Codesearch to find vulns. Since he and others are writing about this, I don’t have to! However, i’ll post a few more thoughts before anyone else maybe!

First, we have this great ability to (ab)use Google’s Codesearch to find vulnerabilities through fast code analysis. Is this a fun but very short fad? Or will we see people use this to disclose vulnerabilities and give credit to their method? Will it lead to a lot of false positives> like we’re seeing with remote file inclusion? Several ‘researchers’ are grep’ing for a single stringle, finding it, and posting it as a remote file inclusion vulnerability without really analyzing the code or testing their own “proof of concept”. Hopefully, researchers will use this new tool to not only find vulnerabilities, but truly validate their finding before disclosing.

Second, who is going to be the first to create an interface that smoothly links the Google Codesearch with a robust static code analyzer? Imagine a web interface where you choose a few key things like what language, what types of vulnerabilities, and click click for all the results. The program would then use the Codesearch results to pipe into the code analyzer and spit out a list of high probability vulnerabilities.

Some of these ideas courtesy of email discussions with Chris Wysopal, Mudge and others.

Google Device Vulnerabilities, EULA and More…

[This was originally published on the OSVDB blog.]

H D Moore recently wrote that he discovered several vulnerabilities in Google Search Appliances. You can find details of these on the Metasploit Vulnerability Page, as well as search OSVDB for the corresponding entries. Normally this wouldn’t be worth posting about, however Moore’s comments on the Google EULA and how it impacts vulnerability research is worth noting. From his mail:

I found some fun bugs in the Google Search Appliance and uploaded the results in preparation for a Monday morning release. To get an idea of how many affected systems there are, just Google for inurl:proxystylesheet. Google released a patch on August 16th and I agreed to wait at least 60 days past that before disclosing the bugs.

A warning to anyone who owns one of these appliances – the EULA and confidentiality agreement prohibit any form of security research or publication of results. After I reported the issue, their security team offered to send me a Mini for patch verification, but agreeing to the license terms would prevent me from publishing any information about the product in the future. I got a beach towel and shirt instead 🙂

This also brings up why Google won’t publicly release their security advisories. Searching Google for “GA-2005-08-m” finds one reference to someone having problems with the latest patches, but no copies of the advisory. Seems Google is all about organizing and sharing world information.. unless it’s information on their own vulnerabilities? Oh wait, “the Google Search Appliance does not create security issues”!