Update on CVEs for EOL Release Lines – MITRE Removal & Next Steps

[RafaelGSS]

The Node.js Security Team has been informed that the three CVEs we emitted for EOL release lines were removed by the MITRE team. Their justification is as follows:

This decision by the Board is in accordance with existing program rules. However, it is worth noting that the Board stated this vote does "not determine the CVE Program’s long-term position" regarding EOL. In fact, the Board plans to continue to discuss potential solutions for EOL support. You are encouraged to continue participating in CVE Working Groups to ensure your perspective is represented.

To address this, we participated in the OpenSSF Vulnerability Disclosure Working Group (WG) to discuss the implications of this decision. We believe we have clearly expressed our perspective on the importance of including EOL release lines in CVEs to ensure proper security disclosure.

Given MITRE's current stance, the only viable option we have is to update all CVEs to explicitly include EOL release lines. To implement this, we propose the following workflow:

• Open this issue to track the update process.
• Publish a blog post informing users about the situation and our planned actions. doc: add Updates on CVE to EOL blog post nodejs.org#7537
• Update the CVEs to include EOL release lines.
• Update the blog post once the changes have been applied.

This issue will serve as the central discussion point for tracking progress. Feedback and suggestions are welcome.

cc: @nodejs/security @nodejs/tsc

[marco-ippolito]

I can volunteer for this task

[RafaelGSS]

I have a blog post almost ready and I can port it to nodejs.org. Once we have an agreement on this, if you can take task number 3, it would be great @marco-ippolito. I suggest opening an issue to also document the list of CVEs that were updated (and include which version range has been added).

[mhdawson]

@RafaelGSS let us know when we can take a look at the blog post.

To start I think it might be enough to include to add the ranges for the EOL versions into one high severity CVE versus all CVEs. That would be less work. We could then include the ranges for all EOL versions in all new CVEs going forward.

[ljharb]

I don't think that will be accepted by MITRE either - it seems the only proper way to use CVEs is for each specific vulnerability to include the affected ranges. As for "less work", isn't it @marco-ippolito who's volunteering to do the work, and i think that perhaps that research is already completed?

[mhdawson]

From my understanding (I think Spring was mentioned) other projects include all EOL versions when they issue a new CVE.

[ljharb]

Right - but each vulnerability remains its own CVE, even if they're overly ambitious in labelling affected versions.

I think that when someone is willing to do the research to correctly mark which EOL versions are affected and not, it's incumbent on us to ensure each CVE's metadata is accurate.

[mhdawson]

Right - but each vulnerability remains its own CVE, even if they're overly ambitious in labelling affected versions.

I think that is consistent with that I said. The only thing I was trying to say is we don't have to mark all existing CVEs to indicate that they are vulnerable for EOL lines, choosing one high severity one and doing it for that one would be enough.

I am happy that we update a CVE once we are comfortable that we have the right answer for a specific CVE .

At the same time I'm not sure we want to have the expectation set that the project commits to do that for EOL lines. Hence if we don't know EOL lines are included in new CVEs (and can be updated if we later have a better answer) .

I'd propose we document the policy as something like this:

The project's policy is to mark EOL lines as vulnerable to all new CVEs. If volunteers investigate and confirm that a vulnerability does not apply to an EOL line the CVE can be updated with that information, however, the project does not depend, plan for, or guarrantee that this will happen. If said information is available when the CVE is first published, it will be updated to exclude EOL lines for which it has been demonstrated that the CVE does not apply.

After CVEs are published volunteers can share investigation and discussion of wether CVEs apply to EOL versions (and possibly fixes) in the nodejs/eol-cve-investigation repository. Contributors who already have access to node-private can also share this information with the project in advance as part of the security release process.

[ljharb]

Oh 100%, looks like we agree :-) there certainly isn't a need to exhaustively check every existing CVE, and I don't think there's even a need to check EOL versions every time a new CVE is found - it's just that when the research is done, for any CVE, it seems like it's a no-brainer to update that CVE with the newly discovered more-accurate information.

[RafaelGSS]

Please, review nodejs/nodejs.org#7537

[RafaelGSS]

The blog has been published. @marco-ippolito could you start the CVE updates next week? If you need help, feel free to ping me.

[marco-ippolito]

Yeah sure, we might need to figure out the procedure, idk if its possible from h1 UI