Details of a Virtual Box 0-day privilege escalation bug were disclosed on GitHub earlier this week. This was the work of independent Russian security researcher Sergey Zelenyuk, who revealed the vulnerability without any vendor coordination as a form of protest against the current state of security research and bug bounty programs. From my perspective, some of his concerns are well-founded and warrant more discussion. I believe this sentiment also reflects a growing view among many in the bug hunting community. Sergey arranged his thoughts into three main points, which I will discuss below.
1. Vendors are slow to patch
Large vendors are chronically slow at evaluating and fixing vulnerabilities, and most researchers are willing to put up with this. Google’s Project Zero with a 90-day disclosure policy has forced some vendors to accelerate patch releases. In fact, at Black Hat 2018, Parisa Tabriz shared some very promising stats to back this up. The most impressive of which was that 98 percent of reports from Google’s researchers are now fixed within 90 days, whereas before moving to a deadline driven disclosure, it was only 25 percent. Although there is no definitive causation, Parisa also anonymously referenced large vendors who have substantially increased their patch frequency and report response times. Unfortunately, this is not the treatment most of us receive, and as Sergey commented, a 6-month turnaround time for fixing a critical bug is nothing unusual. This problem is compounded by several factors. For one thing, there is a huge power imbalance between independent researchers and the organizations they contact. Some vendors definitely take advantage of this by being unresponsive or even threatening. Another aspect to consider is that big software companies that acquire smaller software firms rarely maintain security teams for each acquisition or implement common security processes across the organization. These larger firms commonly expect more time from researchers because they have a vast product portfolio – but in my opinion, we should expect faster response times from critical vendors rather than slower.
2. Bug bounty programs are inconsistent or unreliable
I like bug bounty programs, and I am a huge advocate for them. Over the years, I’ve received bounties from at least a dozen different programs, and I’ve felt good about helping secure systems while also building my own skills and getting paid. Although my experiences have been largely positive, I also have a long list of gripes about how these programs are run and what impact they have on security. I get the impression that some of the people receiving and reviewing bug bounty reports for managed programs treat it as an adversarial game rather than a cooperative process to improve security. Credible vulnerability reports are often closed as informative or invalid without investigation because the bug class or domain is ineligible for a bounty. For example, with HTTPS middlebox vulnerabilities like ROBOT, it is common to find vulnerable websites without having any way of knowing what middlebox is in use or if it is current with patches. I’ve at times submitted reports to bounty programs on things like this, even if “SSL weakness” is listed as out of scope for payment with the goal of identifying a vulnerable product and coordinating disclosure with the vendor. In these reports, I briefly explain the vulnerability and clarify that I do not expect a bounty but rather only wish to inform vulnerable device vendors, so we can coordinate disclosure. In response to this, I would receive comments like, “Sorry, this domain is ineligible for a bounty, better luck next time!” along with a notice that the report is now closed. Several organizations have also now made bug bounty platforms the sole communication method for sharing vulnerability reports. This can be problematic because bounty programs may also include detailed terms and conditions stipulating that researchers can be punished for sharing reports with third-parties without express permission from the vendor. This effectively allows vendors to use bug bounty programs to silence researchers while they drag their feet deciding how to proceed. The result is that researchers may need to decide between getting paid and actually helping people be protected from attack. The other aspect of this problem is that sometimes these vendors are paying a third-party to run the bounty program and filter submissions. Going back to the example of ROBOT, this could mean that the out of scope report is never even seen by the vendor’s security team.
3. Marketing teams overhype security research
Named vulnerabilities and hyped conference talks have become major marketing tools for firms in InfoSec. There are undoubtedly benefits from having names to describe certain vulnerabilities rather than just numbers, but in many cases, this process distracts security teams from real threats and is not in the best interest of security. (Remember badlock?) This problem of marketing-driven security research extends into the conference scene, as well, with events commonly putting an emphasis on “new” research. This drives some vendors to try and coordinate vulnerability disclosures around conference schedules rather than based on what makes the most sense security-wise. Delaying security fixes to make a bigger splash at a trade show is a disservice to everyone affected by these vulnerabilities. Software vendors and hackers have always had a rocky relationship, and things have certainly gotten a lot better, but there is still a long road ahead. In the meantime, I would urge vendors to be transparent in their interactions with researchers and to remember that the bug hunters are here to help them. Even if an organization is paying bounties, remember that people reporting flaws are investing their time with no guaranteed return on investment. If you are on the researcher side of the fence, please try to think about your research in the context of the bigger picture and try to have patience with vendors in proportion to the REAL impact from your discovery. And last but not least, if you really think patch availability makes your conference talk less interesting, consider skipping the CFP entirely rather than holding up disclosure to get better headlines.
