Security-wg: Machine-readable Minimum Secure Version

[bnb]

So this is something that I've been interested in for a while, and has come up a few times recently for me.

Node.js occasionally has semver minor or patch releases on release lines to patch known vulnerabilities. There are efforts to socialize the fact that there's an important or critical security update at the runtime level, but once the release window has passed it's relatively easy to forget and extremely difficult to actually find the current minimum version that should be in production.

The only way I'm able to consistently and quickly discover which version is the minimum secure version is via looking at the archive of the blog posts that _I personally write_ for NodeSource.

It would be really awesome if the Security WG could assist the broader community in some guidance around this.

[mhdawson]

Just thinking about where this might be documented. A few places include the Release repo, the security-wg repo or the nodejs.org website.

Once we figure that out we'd need to make sure update that is part of the security announcement process here: https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md

[lirantal]

@bnb not sure I'm following but wouldn't it be possible to just consult the Node.js core changelog? I'd imagine that if we follow semantic commit conventions such as security: applied smtng smtng then you could parse the release changelog and figure this out.

[cjihrig]

Node core doesn't generally have commits labeled security:.

[lirantal]

I understand the security concern for that but the alternative is manual work around this.

[cjihrig]

It's not so much about the security concern. The convention is to prefix commits with the subsystem they modify. For example test:, src:, http:, etc.

I think this could be automated by parsing the files in https://github.com/nodejs/security-wg/tree/master/vuln/core and looking at the patched fields.

[lirantal]

I'm aware of that convention but this is just a technical thing and we can extend it for security:
(classic angular changelog uses type(scope): short message).

The reference to /vuln/core is indeed the go-to but I wonder if all minor or patch releases are up to date there, and then whether that happens on a timely manner.
@bnb would you say the issue is tracking or the timeliness of these smaller security updates?

[mhdawson]

We generally update the banner on the website when we announce a security update. We may just be able to update the "minimum" secure level as part of that. That would make it easier to find the minimum secure levels but might not address the "mahine readable" part.

[bnb]

@lirantal so this is more of a long-term thing. Sure, I can find out there was a security patch for Node.js when it's happening but two months later I will definitely not recall which version is the _minimum_ secure version.

I really believe that a machine-readable log of this would be invaluable to the tooling community, especially for some evergreen projects.

@mhdawson what do you think about something like index.json in both the core directory that contains all of the numbered vulnerabilities with the contents of n.json as each object's value?

For example:

{
    "1": {
      "cve": [
        "CVE-2017-1000381"
      ],
      "ref": "https://nodejs.org/en/blog/vulnerability/july-2017-security-releases/",
      "vulnerable": "8.x || 7.x || 4.x || 6.x || 5.x",
      "patched": "^8.1.4 || ^7.10.1 || ^4.8.4 || ^6.11.1",
      "description": "memory overread when parsing invalid NAPTR responses",
      "overview": "The c-ares function ares_parse_naptr_reply(), which is used for parsing NAPTR\nresponses, could be triggered to read memory outside of the given input buffer\nif the passed in DNS response packet was crafted in a particular way.\n\n"
    },
    "2": {
        {
          "cve": [],
          "CVE": "XXX assigned, @mhdawson, what is it?",
          "vulnerable": "4.x || 5.x || 6.x || 7.x || 8.x",
          "patched": "^4.8.4 || ^6.11.1 || ^7.10.1 || ^8.1.4",
          "description": "DoS possible in V8 object lookup",
          "overview": "Disable V8 snapshots - The hashseed embedded in the snapshot is\ncurrently the same for all runs of the binary. This opens node up to\ncollision attacks which could result in a Denial of Service. We have\ntemporarily disabled snapshots until a more robust solution is found\nFixed: Ali Ijaz Sheikh\nReported: Fedor Indutny\nref: https://nodejs.org/en/blog/vulnerability/july-2017-security-releases/\n\n"
        }
    }
    [... and so on]
}

[bnb]

Sorry, realized there was a small disconnect in my explanation above and the original goal of this... which is to get a minimum secure version. Machines could search for the highest semver range for each patched version, which would theoretically be the minimum secure version.

[mhdawson]

@bnb, I want to avoid any extra work, if the data is already in the n.json files do we need to ask somebody to updated another file?

[bnb]

@mhdawson I suppose not, but those files aren't discoverable nor guaranteed right now - they live in this repo. Would it be possible to publish them on the website in something like a security directory?

Creating a page for this - similar to https://coverage.nodejs.org/ - and surfacing the files on the site would, I suppose, alleviate my original request... though I'd guess that is even more additional work 😕

[lirantal]

@bnb with regards to the website, I believe @ChALkeR did some personal poc for something like this. Maybe he can share with you.

What I can think of is - maybe we can make use of github pages to host it and automatically update it in PRs that we merge through a CI in place etc.

[mhdawson]

@bnb if we had a module which parsed the files in this repo and them published to nodejs.org at least that would not be more effort for each release. Some work up front though.

[ChALkeR]

@lirantal @bnb That's shared at https://chalker.github.io/security-wg/

[bnb]

For what it's worth, this can now be achieved with the node-release-lines module, which currently uses a static set of data but is shortly adding direct data scraping ❤️