Buzzword-Driven “Pop Infosec”

Posted on Tuesday August 6, 2019

Information security is complicated. When you combine that with the fact that an increasing number of people seem to also consider it to be very important, the result is something I like to call “pop infosec.”

As in pop science or popular psychology, making information security accessible often involves simplifying concepts to improve their general palatability which results in laypeople overestimating their confidence. This “easiness effect” has been studied in the context of science communication, and likely applies to information security in a parallel sense.

While helping people protect themselves from security threats is certainly laudable, it’s important to do it responsibly in order to maximize benefit and minimize harm. Unfortunately, a few recent events I’ve noticed personally suggest that this is not happening.

“The Cloud”

I recently read (part of) an article in the Wall Street Journal (before I got cut off by their paywall) about a data breach which read:

The data was stored on Amazon.com Inc.’s cloud, according to a federal criminal complaint and people familiar with the matter. The avenue of entry, the companies and investigators said, was a poorly configured firewall [...]

Both companies say controls around the data, rather than use of the cloud, were the problem. Still, the data was stored in the cloud, raising questions about whether Capital One put insufficient safeguards in place to lock down customer records when it adopted cloud technology.

Clearly, the reporter has decided to inject some good old “ZOMG all ur dataz are in teh cloud” fear mongering. That aside, this is some of the worst analysis I’ve seen. Imagine you’re trying to keep a box of papers safe; the problem isn’t you kept the box in a self storage unit instead of in your house, the problem is that you left the door unlocked. If the company had a poorly configured cloud environment, why should I expect them to properly configure a firewall in some other environment?

In other words, the WSJ has this almost right: it does raise questions about whether sufficient safeguards were in place, but these questions are orthogonal to any particular technologies or events.

This is simply confusion of correlation and causation. To cite a common example, suppose you thought drowning deaths were a large problem and you learned that there was a strong correlation between ice cream sales and drowning deaths. Recognizing that swimming and eating ice cream are simply both summertime activities, one would of course be mistaken to conclude that banning ice cream would reduce the number of drowning deaths. Likewise, as more companies start using cloud services, we should certainly not be surprised that more vulnerabilities affecting cloud services are discovered.

For the record, I certainly do not believe that “the cloud” is a panacea, but that security is only meaningful relative to a threat model which may or may not involve where hardware happens to be physically located.

“High Severity Vulnerability”

Apparently, all that needs to happen for lots of time and energy to be wasted and have a big fuss is to label something as “high severity.”

Consider this notice I saw when I logged on to GitHub one day:

Clicking “See security alert” lead me to the following notice:

I looked up CVE-2019-10742 and quickly located the relevant pull request for axios. To save you some clicks, axios is a JavaScript HTTP client library which includes an API like this:

axios
  .get('http://example.com/evil.txt')
  .then(console.log)
  .catch(console.error);

Optionally, you can use the get API like this:

axios
  .get('http://example.com/evil.txt', { maxContentLength: 100 })
  .then(console.log)
  .catch(console.error);

in which case axios is expected to abort the response and reject the promise after more than 100 bytes have been received. However, there was a bug in the implementation where the promise would be rejected but reading from the stream would continue, hence the CVE. But look at the code snippets above! This CVE only applies to codebases which actually use the maxContentLength option! If you weren’t using maxContentLength, you weren’t expecting any responses to be truncated in the first place. Nonetheless, I found lots of comments like

will need to roll out a fix for compliance asap

When will this issue be fixed? I have received tons of mail from github regarding axios.

I can help work on it if needed, but we would need to get rid of axios otherwise on an open source SDK I’m actively maintaining

we really need to get a fix out, especially seeing as we’re now getting Github notifications on this.

Thanks to the way GitHub shows references from other issues/pull requests, I was also able to see how people were responding to the vulnerability alert within their own code. Of the random sampling of projects with linked issues/PRs I audited, none of them actually used the maxContentLength option, but dutifully updated the version of their axios dependency and considered the issue resolved.

In reality, nothing about these projects’ security posture actually changed though their maintainers may have thought they did. The real resolution for many of these projects would be to first consider the impact if maxContentLength was not set or respected, and if appropriate, update the dependency and actually use maxContentLength.

Of course, this is not the fault of the developers. Collectively, one of the biggest things we tell people about protecting themselves from vulnerabilities is to keep their software up to date. In this case, developers saw a helpful message saying to update their dependencies, they updated them (possibly even with the automatic click of a button!), and they still might have been vulnerable.

In Conclusion

Information security professionals need to be judicious about how and what is communicated with or recommended to the public. As we’ve seen, “pop infosec” can be ineffective or even harmful. And journalists need to ensure that their reporting is consistent with evidence-based research.

I have said before that security is not a checklist, it is a mindset. You can’t “be secure” by following some steps you find on line or by avoiding certain technologies. The most effective way to improve your security posture is to hire smart people to think critically about your environment.