Vulnerability determination for insecure default configurations

[zmanion]

Current rule under discussion:

4.1.4 Insecure default configuration settings SHOULD be determined to be Vulnerabilities.

Concerns: The word "insecure" is subjective (varies over time and across opinions and contexts) and lacks sufficiently broad consensus, difficult for CNAs (CNA-LRs) to render a vulnerability determination decision.

Additional concern: Suppliers might make sub-optimal choices to avoid CVE ID assignments for insecure default configurations, perception that CVE ID assignments "nitpick" foundational design and implementation choices primarily made for functional reasons.

There are many examples of existing historical assignments for insecure default configurations. History does not necessarily dictate the future, but we should consider the precedents as part of this change. We may want to list some of these and other examples to help decide this change.

The CVE Program does and must continue to handle subjectivity, this is unavoidable, even if we are unable to define "insecure" tightly enough to guide assignments.

A point that came up repeatedly in SPWG discussions is the "element of surprise." If an "insecure" default behavior is well-known, clearly documented (including security considerations), and consistent over time, this would tend towards a determination of no vulnerability. In contrast, "security surprise" default configurations would tend towards a determination of vulnerability (and subsequent CVE ID assignment).

The current 4.1.4 guidance is a "SHOULD" recommendation, so strictly speaking, CNAs are free to use judgment and determine vulnerabiliity or not. A party that disagrees can dispute. So one option is to make no changes and wontfix this issue.

Another option is to remove the current 4.1.4.

A third option is a modification, here is a draft based on the "security suprise" concept and possibly removing the word "insecure" (even though we still trying to define a secure/insecure boundary).

4.1.4 Default configuration settings SHOULD be determined to be Vulnerabilities if the settings introduce surprising or unexpected security behavior.

Optional extension:

For example, consistently well-documented and widely known open default configurations SHOULD NOT be determined to be vulnerabilities.

[zmanion]

Individual opinion: I have very little concern for any Supplier making suboptimal decisions just to try to avoid a CVE ID assignment for an insecure default configuration. Suppliers should make their own decisions. The CVE Program should identify vulnerabilities. Suppliers are free to ignore CVE ID assignments or dispute them. The broken parts of vulnerability management and compliance are free to remain broken.

Another individual opinion: While I agree that "security surprise" should be a factor in all vulnerability determination (not just limited to insecure defaults), the proposed 4.1.4 change doesn't address my primary concern. If some caching database software installs wide-open (e.g., no authentication, listens on all interfaces), and that is well-documented and well-known behavior, statistically, those defaults increase risk. Despite warnings and documentation, someone is going to install without taking the necessary actions to secure the deployment, increasing risk to themselves and others (this is the internet after all).

If the expectation of some "wide open" software is that users (admins, installers) must take action to secure the deployment, then there is no additional effort to ship with more restrictive (secure) defaults. If the real expectation is that it just works out of the box in all situations, that is perfectly valid, and also an insecure default vulnerability that warrants CVE ID assignment.

There have been plenty of incidents of exploitation of "open by default" software.

Requiring intentional user action to enable potentially unsafe functionality is a basic safety and risk transfer concept used in many other domains.

[zmanion]

4.1.4 Default configuration settings SHOULD be determined to be Vulnerabilities, especially if the settings introduce surprising or unexpected security behavior.

[zmanion]

Insecure defaults are clearly an at-scale problem. In this case, even the Supplier thought so and changed the defaults. The question here is ("simply") whether or not this is a vulnerability in CVE terms.

https://snyk.io/blog/mongodb-hack-and-secure-defaults/

[JLLeitschuh]

Proposal:

4.1.4 Vulnerabilities that arise from default configuration MUST be determined to be Vulnerabilities, especially if the settings introduce surprising or unexpected security behavior.

I'm going to push for a MUST, even though I'm likely to be overruled on this matter, because without a MUST you get the argument "it's only a suggestion!"

[darakian]

I feel like this rule shifts the onus of responsibility from consumers to producers and I can see why that's desirable in the context of someone purchasing software in a commercial transaction, however in the context of open source software that burden often falls on volunteer developers. It should not be the responsibility of an open source developer to absorb accountability from some large organization without compensation.

Suppliers are free to ignore CVE ID assignments or dispute them.

Not in practice they are not. Users often pester open source developers for fixes on anything that carries a CVE
example (not a config issue, but undue support burden).
caolan/async#1975

The CVE Program does and must continue to handle subjectivity, this is unavoidable, even if we are unable to define "insecure" tightly enough to guide assignments.

Agreed, but this often requires domain expertise. How does the program intend to handle the subjectivity of the domain in an accountable way?

[JLLeitschuh]

History does not necessarily dictate the future, but we should consider the precedents as part of this change.

I think we need to consider that the norm of what should be considered a vulnerability has shifted as an industry and push towards a world where vendors ship features in a state where the insecure thing requires opt-in, not opt-out.

A point that came up repeatedly in SPWG discussions is the "element of surprise." If an "insecure" default behavior is well-known, clearly documented (including security considerations), and consistent over time, this would tend towards a determination of no vulnerability. In contrast, "security surprise" default configurations would tend towards a determination of vulnerability (and subsequent CVE ID assignment).

"Element of surprise" is also subjective, and is frequently something that CNA LR triages aren't in the best place to make a determination around. Frequently, insecure default configurations ARE documented, but separate from the code. These foot guns lying around is one of the reason why we have so many SAST tools and SAST alerts.

Several SAST alerts I've read, and even some I've written myself have needed to be written purely because some library chose to ship a feature, documented or not, with an insecure default.

Want a concrete case, have a look at the insane charts that Semgrep put together for how to adequately protect your Java XML parser against XXE: https://semgrep.dev/docs/cheat-sheets/java-xxe

No single configuration protects all XML parsers against all 10 attack payloads.

You literally need to use this cheat sheet to ensure you're adequately protected.

For example, consistently well-documented and widely known open default configurations SHOULD NOT be determined to be vulnerabilities.

The problem with this is that this documentation is often shipped external to the system/code that needs to be secured. Vendors shouldn't be shipping software and systems that need to be "hardened" to be secure, they should be hardened by default and we should be granting users to, optionally, lower those guards.

---

Fundamentally, this whole thing ties back to what Steve Gibson of SecurityNow! calls "the tyranny of the default", where vulnerabilities frequently arise due to the fact that many end users will never reconfigure their system to provide adequate protection. If it's working, why fix it?! We, as an industry, need to be doing everything possible to reduce the load on end users of "hardening". We need vendors to be building more secure systems by-default, and by design.

https://www.cisa.gov/securebydesign

[JLLeitschuh]

To quote from an article I published on this matter:

One of the most frustrating things in security tooling — especially static analysis (SAST) — is how much noise we’ve normalized.

In many cases we’ve built this whole industry around flagging the symptoms of insecure defaults rather than fixing the actual root causes.

We see the same footguns pop up again and again in SAST output because the underlying libraries and APIs were never hardened. Why are we training engineers to duct-tape around dangerous behavior in libraries instead of fixing the damn thing upstream?

That’s one of the things I try to do now: follow the alert upstream, figure out why it exists, and patch the real bug.

It’s slow. It’s messy. It’s janitorial.

But every time a dangerous default gets fixed at the source, we eliminate hundreds or thousands of future alerts. > We make security better for everyone — quietly, invisibly.

- What’s an OSS Vulnerability Janitor?

Furthermore, I've had several engineers come up to me at conferences and thank me for finally getting the 5-year-old insecure-by-default RCE vulnerability fixed in SnakeYaml. Rules like 4.1.4 lend this sort of work weight, and give security researchers some leverage in convincing software maintainers they really need to fix insecure defaults.

[kernelsmith]

I always think of MS SQL Server's ol' "SA" and there's no password (CVE-2000-1209 I believe). Worst part was SQL was being installed in the background of other installations w/o the user's knowledge. "SA No Password" was eventually well known, but users didn't always know SQL was even being installed. They changed the installation process so the user had to interact w/the set SQL "sa" user password window, but the user was allowed to simply hit enter, which resulted in the same configuration. Then folks discovered that the required password was being written in clear text to a log file, and then later to a 2nd file. Or maybe those came first? Chronology might be wrong. Anyway, at a minimum, all of those things need to remain vulns in future similar determinations.

[darakian]

Ya, that's bad design for sure. I've seen some users claim SQL injection in functions which take SQL as input.
ex.
https://www.cve.org/CVERecord?id=CVE-2022-40827
bcit-ci/CodeIgniter#6161

There's another case I recall seeing, but can't find where someone was building a SQL database and some user came around claiming it was vulnerable to SQL injection. In a sense sure it is, but entertaining this sort of "vulnerability" nonsense. A SQL database should not be considered "insecure" if one can use SQL on/in it even if there is risk and that risk is present in a default configuration.

[dwelch2344]

Suggestion from today's meeting: add a glossary definition and link to it.

Insecure default configuration settings are default system behaviors or configurations that, when deployed as shipped, reasonably result in an unsafe security posture without requiring operator misconfiguration or deviation from documented best practices.

It's a bit verbose, so please refine wordsmiths 😄