Fully embraces the GitHub "Private vulnerability reporting" tools to allow the team to provide our own CVE numbers early and often. Better document our existing "Coordinated Vulnerability Disclosure" policy (the new name for "Responsible Disclosure").

Jody Garnett (GeoCat BV)

This is a policy change, not associated with a release.

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

We have experimented with adding GitHub "Private vulnerability reporting" to our SECURITY.md policy. This experiment has provided the team with tools to manage our own CVE numbers.

However there are reports we do not control: https://github.com/advisories?query=geoserver

We have recently come into conflict with security researchers and national cyber security departments with policies designed to hold unresponsive vendors to account.

This proposal is a response:

• To provide security researchers with a CVE number, so they do not call out to national cyber security departments
• To provide national cyber security departments with a CVE number, to avoid duplicate CVE numbers which we cannot manage

1. Create "private security vulnerabilities" for our outstanding list of known issues:

   • "GHSA-cqpc-x2c6-2gmf" created for geoserver-security#9

2. Update SECURITY.md policy to use the magic words "Coordinated Vulnerability Disclosure" model (the new name for "Responsible Disclosure").

3. In keeping with "Coordinated Vulnerability Disclosure" model we intended to manage when vulnerabilities are published, waiting until "stable" and "maintenance" branches are patched and released, and providing an adequate opportunity to community participants to update to a patch release.

4. Interested community members (such as organization providing commercial support) are already encouraged to participate on geoserver-security list to assist with the assessment of reported vulnerabilities. This communication channel is also used to explore if there is any interest in backporting and making fixes available on older versions of GeoServer.

When contacted by an external party on geoserver-security email list:

1. Engage with reporter as normal to determine if the issue is reproducible, access vulnerability.

2. For known issues we can provide the reporter with the existing CVE, and indicate the assessment for their review.

3. For new issues we can work with reporter, and create a CVE (as below), and assess the vulnerability with the reporters input.

4. The policy of the reporter working with the geoserver-security volunteers remains steadfast.

   Especially with respect to mitigation and scheduling a fix we need to gather interested parties, including the reporter, with time/resources to address the issue.

   Reporters expecting a vendor relationship are invited to contact our service providers (who are very nice).

1. When creating a draft "private vulnerability reporting" the reporter is invited to participate, and given credit for the report.

2. Request a CVE from GitHub. This requires an external review as they check that the details are complete.

   The report "GHSA-cqpc-x2c6-2gmf" has been assigned CVE-2023-41339 and is shown as "not yet published".

   

3. Assign a placeholder Jira with vulnerability category. Mentioning the CVE is fine, even if it is not yet public it shows up in the database as reserved.

   The jira issue GEOS-11121 ticket is created for CVE-2023-41339.

   

4. When making a release announcement including a fix, even a documentation mitigation.

   Release announcements automatically get a "Security vulnerability" section for placeholder Jira tickets, this would list CVE numbers indicating a fix is included but not provide any details.

   

   Any concerned parties can volunteer on the geoserver-security email list, or arrange a vendor relationship with a service provider.

5. When a mitigation is available in the docs, or a patch is available, for BOTH the stable / maintenance versions.

   The vulnerability can be published, filling in the public CVE with details.

6. The prior release announcements, and placeholder jira, can be updated with a description to go along with the CVE number.

   

7. Optional: if a statement is warranted, an appropriate blog post can be published.

   An example is our statement on. Jiffle and GeoTools RCE vulnerabilities.

When a national agency or similar has already reported a vulnerability publicly:

1. Locate the issue on https://github.com/advisories?query=geoserver

   CVE-2023-35042 example: https://github.com/advisories/GHSA-59x6-g4jr-4hxc

2. Create a pull request to revise the issue with useful details such as:

   • maven
   • org.geoserver
   • version

   CVE-2023-35042 example: https://github.com/github/advisory-database/pull/2721

3. Optional: Work with original agency to try and revise their record:

   A request to mark CVE-2023-35042 as duplicate that had been fixed in all supported versions came out as:

   [DISPUTED] GeoServer 2, in some configurations, allows remote attackers to execute arbitrary code via java.lang.Runtime.getRuntime().exec in wps:LiteralData within a wps:Execute request, as exploited in the wild in June 2023. NOTE: the vendor states that they are unable to reproduce this in any version.

   ⚠️ This is the opposite of controlling the message, it now appears as if the issue being disputed - rather than accepted as already solved please update etc...

4. Claim the ticket with a Jira issue, linking to the revised GitHub record, or national record as appropriate.

   CVE-2023-35042 was reported to our issue tracker as GEOS-11027.

   

This reflects our existing "responsible disclosure" security policy, especially with respect to the expectation for community participation.

Example of problematic interactions on geoserver-security email list:

---

Researcher:

Could be interesting to add a note in the documentation about this? Maybe in the Tomcat hardening section? That way users would know about this and apply the proper configuration.

Volunteer:

Yes that is exactly the kind of participation we are looking for. Patching the docs is a welcome fix.

---

National CVE Numbering Authority:

We are writing to you about a vulnerability reported by an external researcher in one of your products. As established in our disclosure policy, we are going to make this vulnerability public by the 7th of November.

Volunteer:

By demanding service as a "product" you are assuming a vendor relationship - which your external security research and their customers have not paid for.

---

National CVE Numbering Authority:

Our main duty as CVE Numbering Authority (CNA) is to coordinate the publication of vulnerabilities affecting non CNA vendors, as in your case.

Volunteer:

This is the crux of the matter... the notion that there is a "vendor". GeoServer is not a sold product, it's a "common good". Nobody owns it.

To give you some references:

• The license is GPL, which waives any sort of responsibility from developers contributing to it

• The code "ownership" is assigned to OSGeo, which is a " not-for-profit organization whose mission is to foster global adoption of open geospatial technology by being an inclusive software foundation devoted to an open philosophy and participatory community driven development". OSGeo does not employ any developer, it's just a place to share common goals of openness in GIS.

• The GeoServer "Project Steering Committee" has some voting power on issues, but as the name indicates, it can only "steer" contributions that someone else decides to provide, by making them more suitable for open development, and eventually just say no, if a contribution is too specific to one particular use case or does not come with a minimum of quality control.

• The companies providing commercial support do provide code changes on behalf of their customers, but do not commonly initiate a change of their own. You can confirm this by looking at the "State of GeoServer" slides, each new feature comes with the name of the organization that wanted a feature/fix/improvement enough to pay for it, while the gray box in the middle is the implementor that eventually got paid to execute.

While reporting an issue is useful, the only way to get anything done, with an assured deadline, is to follow this guide.

---

National CVE Numbering Authority:

As a recommendation or feedback from our side, having a clearer CVD could avoid this kind of situation with the researchers, so that they go directly to you for the coordination and assignment of possible CVEs.

Wikipedia:

In computer security, coordinated vulnerability disclosure (CVD, formerly known as responsible disclosure)is a vulnerability disclosure model in which a vulnerability or an issue is disclosed to the public only after the responsible parties have been allowed sufficient time to patch or remedy the vulnerability or issue.

geoserver.org:

Responsible Disclosure of Security Issues

If you encounter a security vulnerability in GeoServer please take care to report in a responsible fashion.

Volunteer:

I guess I can use those words exactly in our SECURITY.md file.

---

Project Steering Committee:

• Alessio Fabiani:
• Andrea Aime: +1
• Ian Turton: +1
• Jody Garnett: +1 initial motion
• Jukka Rahkonen: +1
• Kevin Smith: +1
• Simone Giannecchini:
• Torben Barsballe: +1
• Nuno Oliveira:

Community support:

• Mark Prins: +1 "While not eligible to vote I'd like to give my thumbs-up for this proposal."

• https://github.com/geoserver/geoserver/blob/main/SECURITY.md
• https://github.com/github/advisory-database/pull/2721