Monday, June 19, 2017

Introducing Qualys Project Zero?

Google's Project Zero team was announced in July 2014. Since then, it has become very well known for publishing offensive security research of exceptional quality. This is especially welcome to defenders at a time where top quality offensive security research is drying up. For most important software targets, it's getting harder to find and exploit bugs. And for those individuals who remain in the pool of people still capable of playing this game, many have been attracted by positions that seek to abuse vulnerabilities rather than get them fixed.

Perhaps, too few positions exist where top-tier researchers:
  1. Are left alone to self-select research on whatever they deem important.
  2. Get to work alongside other top-tier researchers.
  3. Are expected to openly publish everything they discover.
  4. Are never given bounds or direction from management.
  5. Are supported by their organization when navigating the minefield of vulnerability disclosure.
  6. Are given good resources and top tier corporate pay.
Google deserves a lot of props for hiring a decently sized team that broadly hits the above points.

And there is nothing to stop a different company from doing the same.

Has Qualys done the same?

Since the inception of Project Zero, I've personally seen it as a team called Project Zero, that just happens to be generously funded by Google. Also, an umbrella term under which any team could operate if they adhere to the principles of openness and freedom of employed researchers.

Qualys keeps pumping out research that I find surprisingly cool. Today, we had The Stack Clash, a great read, which finally tipped me over the edge to write this post. Previously, I had noted and enjoyed attacks against the OpenSSH client and a glibc resolver buffer overflow. Three strikes and you're out, perhaps?

So Qualys clearly have one or more very talented hackers on the payroll. (We don't know who because the publications in question are not credited with individual names. I suspect some old-school hacker.) How does Qualys' observable behavior stack up against the list above?
  1. Left alone to self-select research: YES. Hard to imagine management saying "hey, how about you go find, like, 10+ CVEs across all the most popular UNIXes, covering crashing the stack into the heap, and don't forget about 64-bit?".
  2. Top-tier team: YES. This is defined by output. As one example, Stack Clash is top-tier output. The writing in that report uses "we", suggesting a top-tier team instead of a single top-tier individual.
  3. Open publication: YES. (A presumption that all things of significance are published, but seems likely.)
  4. Lack of management direction: MAYBE. Hard to tell whether the Qualys Labs team is left alone to research 100% of the time, or if they are directed to take certain audits at certain times, or even contracted out. Some of the research targets are a bit weird, such as "Trend Micro Interscan Web Security Virtual Appliance" (link). This does not sound like a research target that a top-tier researcher would self-select.
  5. Organizational support for disclosure: MAYBE. We haven't yet seen if Qualys would be willing to stand up to a (e.g.) Microsoft or Apple trying to bully Qualys or one of their individual recruiters. There's also the worrying signal that Qualys unilaterally extended a disclosure embargo, going back on an agreement with Solar (see oss-sec post here). There's also the question of whether "customers" get access to details before patches are available -- which would be counter to Project Zero principles.
  6. Good resources / pay: YES. (A presumption that Qualys pays reasonably relative to the hot market for security professionals.)
Conclusion

With just a few public clarifications and maybe tweaks, Qualys would be able to use the term "Qualys Project Zero" without violating the spirit behind the name.

I'd be delighted at any such outcome: multiple Project Zeros, each funded by some benefactor with an interest in security, is one way to scale this thing.

No comments: