Summary A GeoServer that uses ENTITYRESOLUTIONALLOWLIST may allow attacker to perform unauthenticated Server-Side Request Forgery (SSRF).

Details This vulnerability requires that GeoServer is set up to use a proxy base URL and the ENTITYRESOLUTIONALLOWLIST (default since 2.25.0):

Impact This vulnerability allows an attacker to cause GeoServer to make requests to an unintended location.

Workaround GeoServer installations are only affected by this vulnerability if they use a proxy base URL that does not contain a URL path or end with a slash (e.g., https://somesite.org instead of https://somesite.org/ or https://somesite.org/geoserver). If the proxy base URL does not contain a path, adding a slash to the end of the URL will mitigate this vulnerability.

Resources https://osgeo-org.atlassian.net/browse/GEOS-11867 https://github.com/geoserver/geoserver/pull/8622

Credits: - Le Mau Anh Phong at Verichains Cyber Force

Summary A vulnerability exists that allows an authenticated administrator with access to GeoServer's security system to pass arbitrary file names to the Master Password Dump web page and create files containing the master password in plaintext. The provided file name must be an absolute path to the target file, the target file can not already exist and all parent directories must already exist.

Details When dumping the master password, GeoServer will use the provided file name with minimal validation as long as it is a java.io.File path. The only limitation is that the fix for a previous, unrelated vulnerability prevents relative path traversal here but absolute paths can be used to access arbitrary files. GeoServer does not enforce a maximum password length by default which allows an administrator to place malicious code into their password which could then be dumped into a JSP file.

Impact Remote Code Execution (High severity) This vulnerability can lead to executing arbitrary code if GeoServer is deployed in an environment where an attacker can dynamically deploy and execute a JSP file. This is possible if the geoserver.war file is simply placed into the webapps directory of a default Tomcat installation.

NTLM Hash Disclosure (Moderate severity) If GeoServer is deployed in a Windows operating system and the GeoServer administrator does not already have access to the Windows account running the GeoServer process, it may be possible for the administrator to make GeoServer trigger an outbound NTLM request to a remote, attacker-controlled server and gain access to the NTLM hash or user password for use in future attacks.

Denial of Service (Low severity) This vulnerability allows writing a file to any location where the GeoServer process has write permissions which could still potentially cause some kind of denial of service.

Mitigation GeoServer installations where the web interface is either disabled or completely removed are not affected since the vulnerability exists in one of the web pages.

Resources https://osgeo-org.atlassian.net/browse/GEOS-11852 https://github.com/geoserver/geoserver/pull/8584

Summary

Administrator can perform JNDI attack through specially crafted DB2 jdbc url leading to Remote Code Execution (RCE).

Impact

If GeoServer has DB2 extension installed, this vulnerability can lead to executing arbitrary code.

Details

Authenticated users can access Vector Data Sources page to creating a new data store through db2 jdbc connection, performing JNDI attack due to unrestricted connection parameters, and then achieve RCE with deserialization of untrusted data.

Remediation

This issue has been fixed in this release: https://github.com/geoserver/geoserver/releases/tag/2.27.0.

References

https://osgeo-org.atlassian.net/browse/GEOT-7725 https://nvd.nist.gov/vuln/detail/cve-2023-27867

Description

An XML External Entity (XXE) vulnerability was identified. The application accepts XML input through a specific endpoint /geoserver/wms operation GetMap. However, this input is not sufficiently sanitized or restricted, allowing an attacker to define external entities within the XML request.

An XML External Entity attack is a type of attack that occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, port scanning from the perspective of the machine where the parser is located, and other system impacts.

By exploiting this vulnerability, an attacker can: - Read arbitrary files from the server's file system. - Conduct Server-Side Request Forgery (SSRF) to interact with internal systems. - Execute Denial of Service (DoS) attacks by exhausting resources.

Resolution

Update to GeoServer 2.25.6, GeoServer 2.26.3, or GeoServer 2.27.0.

Impact

The XXE vulnerability can be used to retrieve arbitrary files from the server's file system.

Reference

https://osgeo-org.atlassian.net/browse/GEOS-11682 XBOW-024-081

Disclaimer

This vulnerability was detected using XBOW, a system that autonomously finds and exploits potential security vulnerabilities. The finding has been thoroughly reviewed and validated by a security researcher before submission. While XBOW is intended to work autonomously, during its development human experts ensure the accuracy and relevance of its reports.

Summary Multiple OGC request parameters allow Remote Code Execution (RCE) by unauthenticated users through specially crafted input against a default GeoServer installation due to unsafely evaluating property names as XPath expressions.

Details The GeoTools library API that GeoServer calls evaluates property/attribute names for feature types in a way that unsafely passes them to the commons-jxpath library which can execute arbitrary code when evaluating XPath expressions. This XPath evaluation is intended to be used only by complex feature types (i.e., Application Schema data stores) but is incorrectly being applied to simple feature types as well which makes this vulnerability apply to ALL GeoServer instances.

PoC No public PoC is provided but this vulnerability has been confirmed to be exploitable through WFS GetFeature, WFS GetPropertyValue, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic and WPS Execute requests.

Impact This vulnerability can lead to executing arbitrary code.

Workaround

A workaround exists by removing the gt-complex-x.y.jar file from the GeoServer where x.y is the GeoTools version (e.g., gt-complex-31.1.jar if running GeoServer 2.25.1). This will remove the vulnerable code from GeoServer but may break some GeoServer functionality or prevent GeoServer from deploying if the gt-complex module is needed by an extension you are using:

Mitigation for geoserver.war deploy:

1. Stop the application server 2. Unzip geoserver.war into a directory 3. Locate the file WEB-INF/lib/gt-complex-x.y.jar and remove 4. Zip the directory into a new geoserver.war 5. Restart the application server

Mitigation for GeoServer binary:

1. Stop Jetty 2. Locate the file webapps/geoserver/WEB-INF/lib/gt-complex-x.y.jar and remove 3. Restart Jetty

The following extensions and community modules are known to have a direct dependency on gt-complex jar and are not expected function properly without it. This is not comprehensive list and additional GeoServer functionality may be dependent on the availability of gt-complex jar: Extensions: Application Schema, Catalog Services for the Web, MongoDB Data Store Community Modules: Features-Templating, OGC API Modules, Smart Data Loader, SOLR Data Store

Mitigation available for prior releases patching three jars in your existing install:

1. Patched gt-app-schema, gt-complex and gt-xsd-core jars may be downloaded for GeoServer: 2.25.1, 2.24.3, 2.24.2, 2.23.2, 2.22.2, 2.21.5, 2.21.4,2.20.7, 2.20.4, 2.19.2, 2.18.0. As example the 2.25.1 page links to geoserver-2.25.1-patches.zip download on source forge.

2. Unzip the geoserver-x.y.z-patches.zip which contains three jars that have been patched to configure commons-jxpath with an empty function list prior to use. These files are drop-in replacements with identical file names to those they are replacing.

3. Follow the instructions above to locate WEB-INF/lib folder and replace the existing gt-app-schema, gt-complex and gt-xsd-core jars with those supplied by the patch.

References https://github.com/geotools/geotools/security/advisories/GHSA-w3pj-wh35-fq8w https://osgeo-org.atlassian.net/browse/GEOT-7587 https://github.com/geotools/geotools/pull/4797 https://github.com/Warxim/CVE-2022-41852?tab=readme-ov-file#workaround-for-cve-2022-41852

GeoServer is an open source server that allows users to share and edit geospatial data. Starting in version 2.10.0 and prior to versions 2.24.4 and 2.25.1, GeoServer's Server Status page and REST API lists all environment variables and Java properties to any GeoServer user with administrative rights as part of those modules' status message. These variables/properties can also contain sensitive information, such as database passwords or API keys/tokens. Additionally, many community-developed GeoServer container images export other credentials from their start-up scripts as environment variables to the GeoServer (java) process. The precise scope of the issue depends on which container image is used and how it is configured.

The about status API endpoint which powers the Server Status page is only available to administrators.Depending on the operating environment, administrators might have legitimate access to credentials in other ways, but this issue defeats more sophisticated controls (like break-glass access to secrets or role accounts).By default, GeoServer only allows same-origin authenticated API access. This limits the scope for a third-party attacker to use an administrator’s credentials to gain access to credentials. The researchers who found the vulnerability were unable to determine any other conditions under which the GeoServer REST API may be available more broadly.

Users should update container images to use GeoServer 2.24.4 or 2.25.1 to get the bug fix. As a workaround, leave environment variables and Java system properties hidden by default. Those who provide the option to re-enable it should communicate the impact and risks so that users can make an informed choice.

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in the GeoServer catalog that will execute in the context of another user's browser when viewed in the GWC Demos Page. Access to the GWC Demos Page is available to all users although data security may limit users' ability to trigger the XSS.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://github.com/GeoWebCache/geowebcache/issues/1171 https://github.com/GeoWebCache/geowebcache/pull/1173

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in the GeoServer catalog that will execute in the context of another user's browser when viewed in the MapML HTML Page. The MapML extension must be installed and access to the MapML HTML Page is available to all users although data security may limit users' ability to trigger the XSS.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://osgeo-org.atlassian.net/browse/GEOS-11154 https://github.com/geoserver/geoserver/pull/7175

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in the GeoServer catalog that will execute in the context of another user's browser when viewed in the WMS GetMap OpenLayers Output Format. Access to the WMS OpenLayers Format is available to all users by default although data and service security may limit users' ability to trigger the XSS.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://osgeo-org.atlassian.net/browse/GEOS-11153 https://github.com/geoserver/geoserver/pull/7174

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in the GeoServer catalog that will execute in the context of another administrator’s browser when viewed in the GWC Seed Form. Access to the GWC Seed Form is limited to full administrators by default and granting non-administrators access to this endpoint is not recommended.

Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

PoC Complete instructions, including specific configuration details, to reproduce the vulnerability.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://github.com/GeoWebCache/geowebcache/issues/1172 https://github.com/GeoWebCache/geowebcache/pull/1174

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in the GeoServer catalog that will execute in the context of another user's browser when viewed in the WMS GetMap SVG Output Format when the Simple SVG renderer is enabled. Access to the WMS SVG Format is available to all users by default although data and service security may limit users' ability to trigger the XSS.

Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

PoC Complete instructions, including specific configuration details, to reproduce the vulnerability.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://osgeo-org.atlassian.net/browse/GEOS-11152 https://github.com/geoserver/geoserver/pull/7173

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in uploaded style/legend resources or in a specially crafted datastore file that will execute in the context of another user's browser when viewed in the Style Publisher. Access to the Style Publisher is available to all users although data security may limit users' ability to trigger the XSS.

Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

PoC Complete instructions, including specific configuration details, to reproduce the vulnerability.

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://osgeo-org.atlassian.net/browse/GEOS-11149 https://github.com/geoserver/geoserver/pull/7162 https://osgeo-org.atlassian.net/browse/GEOS-11155 https://github.com/geoserver/geoserver/pull/7181

Summary An arbitrary file renaming vulnerability exists that enables an authenticated administrator with permissions to modify stores through the REST Coverage Store or Data Store API to rename arbitrary files and directories with a name that does not end in ".zip".

Details Store file uploads rename zip files to have a ".zip" extension if it doesn't already have one before unzipping the file. This is fine for file and url upload methods where the files will be in a specific subdirectory of the data directory but, when using the external upload method, this allows arbitrary files and directories to be renamed.

PoC Coverage Store Example (workspace and store name are irrelevant and any valid coverage format can be used): curl -XPUT -H"Content-Type:application/zip" -u"admin:geoserver" -d"/file/to/move" "http://localhost:8080/geoserver/rest/workspaces/a/coveragestores/b/external.geotiff" Data Store Example (workspace and store name and data store format are irrelevant): curl -XPUT -H"Content-Type:application/zip" -u"admin:geoserver" -d"/file/to/move" "http://localhost:8080/geoserver/rest/workspaces/a/datastores/b/external.c"

Impact Renaming GeoServer files will most likely result in a denial of service, either completely preventing GeoServer from running or effectively deleting specific resources (such as a workspace, layer or style). In some cases, renaming GeoServer files could revert to the default settings for that file which could be relatively harmless like removing contact information or have more serious consequences like allowing users to make OGC requests that the customized settings would have prevented them from making. The impact of renaming non-GeoServer files depends on the specific environment although some sort of denial of service is a likely outcome.

References https://osgeo-org.atlassian.net/browse/GEOS-11213 https://github.com/geoserver/geoserver/pull/7289

Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in uploaded style/legend resources that will execute in the context of another administrator's browser when viewed in the REST Resources API. Access to the REST Resources API is limited to full administrators by default and granting non-administrators access to this endpoint should be carefully considered as it may allow access to files containing sensitive information.

Details Upload a new Legend via the New Style page if user has permissions for this. This file is then not checked and is uploaded to the backend system. This file can then be viewed directly by requesting it via the API which will then view the file in its raw format without sanitisation. !image

!image

PoC

1 .User makes the following request to upload file. POST /geoserver/web/wicket/bookmarkable/org.geoserver.wms.web.data.StyleNewPage?11-1.IBehaviorListener.0-dialog-dialog-content-form-submit&wicket-ajax=true&wicket-ajax-baseurl=wicket%2Fbookmarkable%2Forg.geoserver.wms.web.data.StyleNewPage%3F11 HTTP/1.1 Host: geoserver:8080 User-Agent: Mozilla/5.0 (X11; Linux x8664; rv:91.0) Gecko/20100101 Firefox/91.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: multipart/form-data; boundary=---------------------------37957706701641834739220342753 Content-Length: 619 Connection: close Upgrade-Insecure-Requests: 1

-----------------------------37957706701641834739220342753 Content-Disposition: form-data; name="id89hf0" -----------------------------37957706701641834739220342753 Content-Disposition: form-data; name="userPanel:image" -----------------------------37957706701641834739220342753 Content-Disposition: form-data; name="userPanel:upload"; filename="test.html" Content-Type: text/html <script>alert(document.cookie)</script> -----------------------------37957706701641834739220342753 Content-Disposition: form-data; name="p::submit" 1 -----------------------------37957706701641834739220342753-- 2. File is uploaded to the backend system and is viewable via the API at - /geoserver/rest/resourse/styles as per the screenshot above.

3. If admin user views this file the Javascript is executed and this could be used to craft a payload to steal the user's cookies(as these do not currently use HTTPOnly) !image

Alternatively -

If the user has permissions to use the API to make PUT requests then they can directly upload malicious files as per a request below. This would be viewable in the same way as above.

PUT /geoserver/rest/resource/styles/test2.html HTTP/1.1 Host: geoserver:8080 User-Agent: Mozilla/5.0 (X11; Linux x8664; rv:91.0) Gecko/20100101 Firefox/91.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Authorization: Basic YWRtaW46Z2Vvc2VydmVy (admin:geoserver default credentials) Connection: close Upgrade-Insecure-Requests: 1 Content-Type: text/html Content-Length: 29

<script>alert(1)</script>

Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:

1 .Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

References https://osgeo-org.atlassian.net/browse/GEOS-11148 https://github.com/geoserver/geoserver/pull/7161

Summary An arbitrary file upload vulnerability exists that enables an authenticated administrator with permissions to modify coverage stores through the REST Coverage Store API to upload arbitrary file contents to arbitrary file locations which can lead to remote code execution.

Details Coverage stores that are configured using relative paths use a GeoServer Resource implementation that has validation to prevent path traversal but coverage stores that are configured using absolute paths use a different Resource implementation that does not prevent path traversal.

PoC Step 1 (create sample coverage store): curl -vXPUT -H"Content-type:application/zip" -u"admin:geoserver" --data-binary @polyphemus.zip "http://localhost:8080/geoserver/rest/workspaces/sf/coveragestores/filewrite/file.imagemosaic" Step 2 (switch store to absolute URL): curl -vXPUT -H"Content-Type:application/xml" -u"admin:geoserver" -d"<coverageStore><url>file:///{absolute path to data directory}/data/sf/filewrite</url></coverageStore>" "http://localhost:8080/geoserver/rest/workspaces/sf/coveragestores/filewrite" Step 3 (upload arbitrary files): curl -vH"Content-Type:" -u"admin:geoserver" --data-binary @file/to/upload "http://localhost:8080/geoserver/rest/workspaces/sf/coveragestores/filewrite/file.a?filename=../../../../../../../../../../file/to/write" Steps 1 & 2 can be combined into a single POST REST call if local write access to anywhere on the the file system that GeoServer can read is possible (e.g., the /tmp directory).

Impact This vulnerability can lead to executing arbitrary code. An administrator with limited privileges could also potentially exploit this to overwrite GeoServer security files and obtain full administrator privileges.

References https://osgeo-org.atlassian.net/browse/GEOS-11176 https://github.com/geoserver/geoserver/pull/7222

Impact

This vulnerability requires GeoServer Administrator with access to the admin console to misconfigured the Global Settings for log file location to an arbitrary location.

This can be used to read files via the admin console GeoServer Logs page. It is also possible to leverage RCE or cause denial of service by overwriting key GeoServer files.

Patches

As this issue requires GeoServer administrators access, often representing a trusted party, the vulnerability has not yet attracted a volunteer or resources.

Interested parties are welcome to contact geoserver-security@lists.osgeo.org for recommendations on developing a fix.

Workarounds

A system administrator responsible for running GeoServer can define the GEOSERVERLOGFILE parameter, preventing the global setting provided from being used.

The GEOSERVERLOGLOCATION parameter can be set as system property, environment variable, or servlet context parameter.

Environmental variable: bash export GEOSERVERLOGLOCATION=/var/opt/geoserver/logs

System property: bash -DGEOSERVERLOGLOCATION=/var/opt/geoserver/logs

Web application WEB-INF/web.xml: xml <context-param> <param-name> GEOSERVERLOGLOCATION </param-name> <param-value>/var/opt/geoserver/logs</param-value> </context-param>

Tomcat conf/Catalina/localhost/geoserver.xml: xml <Context> <Parameter name="GEOSERVERLOGLOCATION" value="/var/opt/geoserver/logs" override="false"/> </Context>

References

Log location (User Manual)

Withdrawn This advisory has been withdrawn as there the effects of the bug would only give the caller an incomplete view of data which they would be authorized to see.

Original Advisory PartialBufferOutputStream2 in GeoServer before 1.6.1 and 1.7.0-beta1 attempts to flush buffer contents even when it is handling an "in memory buffer," which prevents the reporting of a service exception, with unknown impact and attack vectors.