ghsa-p9p4-97g9-wcrh
Vulnerability from github
Published
2022-06-03 22:19
Modified
2022-06-03 22:19
Summary
Dev error stack trace leaking into prod in Play Framework
Details

Impact

Play Framework, when run in dev mode, shows verbose errors for easy debugging, including an exception stack trace. Play does this by configuring its DefaultHttpErrorHandler to do so based on the application mode. In its Scala API Play also provides a static object DefaultHttpErrorHandler that is configured to always show verbose errors. This is used as a default value in some Play APIs, so it is possible to inadvertently use this version in production. It is also possible to improperly configure the DefaultHttpErrorHandler object instance as the injected error handler. Both of these situations could result in verbose errors displaying to users in a production application, which could expose sensitive information from the application.

In particular the constructor for CORSFilter and apply method for CORSActionBuilder use the static object DefaultHttpErrorHandler as a default value.

Patches

This is patched in Play Framework 2.8.16. The DefaultHttpErrorHandler object has been changed to use the prod-mode behavior, and DevHttpErrorHandler has been introduced for the dev-mode behavior.

Workarounds

When constructing a CORSFilter or CORSActionBuilder, ensure that a properly-configured error handler is passed. Generally this should be done by using the HttpErrorHandler instance provided through dependency injection or through Play's BuiltInComponents. Ensure that your application is not using the DefaultHttpErrorHandler static object in any code that may be run in production.

References

https://www.playframework.com/documentation/2.8.x/ScalaErrorHandling#Supplying-a-custom-error-handler https://www.playframework.com/documentation/2.8.x/JavaErrorHandling#Supplying-a-custom-error-handler

For more information

If you have any questions or comments about this advisory: * Open an issue in playframework/playframework * Email us at example email address

Show details on source website


{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.typesafe.play:play_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.typesafe.play:play_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31023"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-03T22:19:23Z",
    "nvd_published_at": "2022-06-02T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nPlay Framework, when run in dev mode, shows verbose errors for easy debugging, including an exception stack trace. Play does this by configuring its `DefaultHttpErrorHandler` to do so based on the application mode. In its Scala API Play also provides a static object `DefaultHttpErrorHandler` that is configured to always show verbose errors. This is used as a default value in some Play APIs, so it is possible to inadvertently use this version in production. It is also possible to improperly configure the `DefaultHttpErrorHandler` object instance as the injected error handler.  Both of these situations could result in verbose errors displaying to users in a production application, which could expose sensitive information from the application.\n\nIn particular the constructor for `CORSFilter` and `apply` method for `CORSActionBuilder` use the static object `DefaultHttpErrorHandler` as a default value.\n\n### Patches\n\nThis is patched in Play Framework 2.8.16. The `DefaultHttpErrorHandler` object has been changed to use the prod-mode behavior, and `DevHttpErrorHandler` has been introduced for the dev-mode behavior.\n\n### Workarounds\n\nWhen constructing a `CORSFilter` or `CORSActionBuilder`, ensure that a properly-configured error handler is passed. Generally this should be done by using the `HttpErrorHandler` instance provided through dependency injection or through Play\u0027s `BuiltInComponents`. Ensure that your application is not using the `DefaultHttpErrorHandler` static object in any code that may be run in production.\n\n### References\nhttps://www.playframework.com/documentation/2.8.x/ScalaErrorHandling#Supplying-a-custom-error-handler\nhttps://www.playframework.com/documentation/2.8.x/JavaErrorHandling#Supplying-a-custom-error-handler\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [playframework/playframework](https://github.com/playframework/playframework/)\n* Email us at [example email address](mailto:example@example.com)\n",
  "id": "GHSA-p9p4-97g9-wcrh",
  "modified": "2022-06-03T22:19:23Z",
  "published": "2022-06-03T22:19:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/playframework/playframework/security/advisories/GHSA-p9p4-97g9-wcrh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31023"
    },
    {
      "type": "WEB",
      "url": "https://github.com/playframework/playframework/pull/11305"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/playframework/playframework"
    },
    {
      "type": "WEB",
      "url": "https://github.com/playframework/playframework/releases/tag/2.8.16"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Dev error stack trace leaking into prod in Play Framework"
}


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 seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…