Profile picture
Katie Moussouris @k8em0
, 17 tweets, 6 min read Read on Twitter
The assumption "bug collisions are so common in all software that everyone should assume that for any bug disclosed, it's probably been found by attackers & exploited already" contrasts how scientific research works. Security research is no exception.
Bug & research "collisions" can happen due to lots of low-hanging fruit. It can also occur when researchers pay attention to reach other's work. I've discussed researcher "swarming" for years, & recently on stage at BlackHat this summer.
Bug collision or correlation rates for software that has a lot of bugs (bug dense, say, because of not being well-tested) will generally model higher bug collision rates than in software with low bug density. See slides #23-27 from my RSA talk in 2015.…
In the case of #Meltdown & #Spectre , it seems to be more like the specialists in this research area were paying attention to, & building upon, publicly discussed research areas of interest. Hence, these bug "collisions" were following what we see & accept in other sciences.
Researchers will swarm areas that others show results in. Let's not assume that further variants of these or other published bugs mean that we should assume all bugs are already under attack.
Time, scientific research, & bug hunting are still experienced as linear by most humans.
An old example of this "20 year old bugs, now suddenly uncovered by many at once" due to researchers swarming is format string vulnerabilities.… Discussed openly for years, but the CVEs only really started rolling in after a critical mass of publications.
I'm seeing a forgetfulness that "bug collisions" can happen for different reasons, a lack of critical thinking when it comes to interpreting why it happened for #Meltdown #Spectre , AND an unfounded leap to say that these or any examples of bug collisions should set broad policy.
Both Harvard & RAND paper authors very much were trying to push the notion that by "measuring" bug collision rates using "real data", conclusions could be drawn across all software.
My minority report on this triad is this:
No it cannot because reasons for bug collisions vary.
1 characteristic about software itself that can statistically increase bug collisions is bug density. The characteristics about researchers that can increase bug collision rates include reading each other's work & talking through ideas. There are more factors of course.
My point isn't to list all possible factors that go into bug collision rates. My point is that it's dangerous to draw broad conclusions around this or other example of bug collisions to set policy like the government Vulnerability Equities Process (VEP) or disclosure deadlines.
Why did we (MIT Sloan, Harvard, & I) look at bug collision rates several years ago, one may ask. It was to answer the challenge posed by Dan Geer in his 2013 BlackHat keynote, where he argued that the US gov should try to outbid the black market for bugs if it would make a dent.
Sorry, it was 2014:…
We looked at bug density, supply of finders, & other factors to build a system dynamics model. Best lever for govs to improve defense wasn't buying bugs & shoving it at vendors to fix. We've already seen vendors struggle to handle their incoming bugs, even with bug bounties.
We recommended govs sponsor creation of better tools to determine exploitability & give them to vendors. Rather than force feed vendors bugs (or "fish"), instead teach them to determine exploitability ("fish or not fish"). Vendors' capabilities need more fixing than their bugs.
When the DARPA Cyber Grand Challenge was just a concept, I pointed out that AI bug hunting would devour all vendor triage resources if unleashed upon the world. Pile of rotting "fish" bugs. So the organizers added the AI fixing requirements. But performance & app compat, I warned
Back to #Meltdown & #Spectre
1. Performance hits with patches in some circumstances? Yep
2. App compat issues w third party AV playing out? You betcha
On bug collision rates:
1. Causes for collision rates vary
2. #Meltdown & #Spectre collisions don't change the fix issues above
1. Bug collisions exist
2. Bug collision *rates* vary based on variables
3. Broad policy shouldn't be set by any 1 example or data set
3. #Meltdown & #Spectre collisions likely due to researcher swarming
4. "Assume breach" is sound, but "assume bug collision for all bugs" is not
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Katie Moussouris
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!