Common Weakness Enumeration

CWE-95

Allowed

Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

Abstraction: Variant · Status: Incomplete

The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").

262 vulnerabilities reference this CWE, most recent first.

GHSA-XQ52-RV6W-397C

Vulnerability from github – Published: 2020-01-23 02:28 – Updated: 2023-05-16 16:09
VLAI
Summary
Directive injection when using dynamic overrides with user input
Details

Impact

If user-supplied input was passed into append/override_content_security_policy_directives, a semicolon could be injected leading to directive injection.

This could be used to e.g. override a script-src directive. Duplicate directives are ignored and the first one wins. The directives in secure_headers are sorted alphabetically so they pretty much all come before script-src. A previously undefined directive would receive a value even if SecureHeaders::OPT_OUT was supplied.

The fixed versions will silently convert the semicolons to spaces and emit a deprecation warning when this happens. This will result in innocuous browser console messages if being exploited/accidentally used. In future releases, we will raise application errors resulting in 500s.

Duplicate script-src directives detected. All but the first instance will be ignored.

See https://www.w3.org/TR/CSP3/#parse-serialized-policy

Note: In this case, the user agent SHOULD notify developers that a duplicate directive was ignored. A console warning might be appropriate, for example.

Patches

Depending on what major version you are using, the fixed versions are 6.2.0, 5.1.0, 3.8.0.

Workarounds

If you are passing user input into the above methods, you could filter out the input:

override_content_security_policy_directives(:frame_src, [user_input.gsub(";", " ")])

References

Reported in https://github.com/twitter/secure_headers/issues/418 https://www.w3.org/TR/CSP3/#parse-serialized-policy

For more information

If you have any questions or comments about this advisory: * Open an issue in this repo * DM @ndm on twitter

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "secure_headers"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "secure_headers"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "secure_headers"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-5217"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-95"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-01-23T02:12:03Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nIf user-supplied input was passed into `append/override_content_security_policy_directives`, a semicolon could be injected leading to directive injection.\n\nThis could be used to e.g. override a `script-src` directive. Duplicate directives are ignored and the first one wins. The directives in `secure_headers` are sorted alphabetically so they pretty much all come before `script-src`. A previously undefined directive would receive a value even if `SecureHeaders::OPT_OUT` was supplied.\n\nThe fixed versions will silently convert the semicolons to spaces and emit a deprecation warning when this happens. This will result in innocuous browser console messages if being exploited/accidentally used. In future releases, we will raise application errors resulting in 500s.\n\n\u003e Duplicate script-src directives detected.  All but the first instance will be ignored.\n\nSee https://www.w3.org/TR/CSP3/#parse-serialized-policy\n\n\u003e Note: In this case, the user agent SHOULD notify developers that a duplicate directive was ignored. A console warning might be appropriate, for example.\n\n### Patches\n\nDepending on what major version you are using, the fixed versions are 6.2.0, 5.1.0, 3.8.0.\n\n### Workarounds\n\nIf you are passing user input into the above methods, you could filter out the input:\n\n```ruby\noverride_content_security_policy_directives(:frame_src, [user_input.gsub(\";\", \" \")])\n```\n\n### References\n\nReported in https://github.com/twitter/secure_headers/issues/418\nhttps://www.w3.org/TR/CSP3/#parse-serialized-policy\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [this repo](https://github.com/twitter/secure_headers/issues/new)\n* DM @ndm on twitter ",
  "id": "GHSA-xq52-rv6w-397c",
  "modified": "2023-05-16T16:09:56Z",
  "published": "2020-01-23T02:28:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/twitter/secure_headers/security/advisories/GHSA-xq52-rv6w-397c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5217"
    },
    {
      "type": "WEB",
      "url": "https://github.com/twitter/secure_headers/issues/418"
    },
    {
      "type": "WEB",
      "url": "https://github.com/twitter/secure_headers/pull/421"
    },
    {
      "type": "WEB",
      "url": "https://github.com/twitter/secure_headers/commit/936a160e3e9659737a9f9eafce13eea36b5c9fa3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/secure_headers/CVE-2020-5217.yml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/twitter/secure_headers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Directive injection when using dynamic overrides with user input"
}

GHSA-XR6M-2P4M-JVQF

Vulnerability from github – Published: 2022-09-16 17:22 – Updated: 2022-09-16 17:22
VLAI
Summary
XWiki Platform Wiki UI Main Wiki Eval Injection vulnerability
Details

Impact

It's possible to inject arbitrary wiki syntax including Groovy, Python and Velocity script macros via the request (URL parameter) using the XWikiServerClassSheet if the user has view access to this sheet and another page that has been saved with programming rights, a standard condition on a public read-only XWiki installation or a private XWiki installation where the user has an account. This allows arbitrary Groovy/Python/Velocity code execution which allows bypassing all rights checks and thus both modification and disclosure of all content stored in the XWiki installation. Also, this could be used to impact the availability of the wiki.

On current versions (e.g., 14.3), this can be triggered by opening the URL /xwiki/bin/view/Main/?sheet=XWiki.XWikiServerClassSheet&form_token=<form_token>&action=delete&domain=foo%22%2F%7D%7D%7B%7Basync%20async%3D%22true%22%20cached%3D%22false%22%20context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22hello%20from%20groovy!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D, on version 5.3 Milestone 2 (oldest impacted version), the issue can be reproduced using <server>/xwiki/bin/view/Main/?sheet=WikiManager.XWikiServerClassSheet&form_token=<form_token>&action=delete&domain=foo%22%2F%7D%7D%7B%7B%2Ferror%7D%7D%7B%7B%2Fhtml%7D%7D%7B%7Bfootnote%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22hello+from+groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Ffootnote%7D%7D. In both cases <server> is the URL of the XWiki installation and <form_token> is the token used for CSRF protection for the current user which is available in every HTML response (search for form-token or form_token in the HTML source). If the string hello from groovy without println(" before it is displayed, the attack has been successful.

Patches

This has been patched in the supported versions 13.10.6 and 14.4.

Workarounds

It is possible to edit the affected document XWiki.XWikiServerClassSheet or WikiManager.XWikiServerClassSheet and manually perform the changes from the patch fixing the issue, i.e., replacing

     {{error}}{{translation key="platform.wiki.sheet.erroraliasalreadynotexists" parameters="$request.domain"/}}{{/error}}

by

     {{error}}{{translation key="platform.wiki.sheet.erroraliasalreadynotexists" parameters="~"${services.rendering.escape($escapetool.java($request.domain), 'xwiki/2.1')}~""/}}{{/error}}

and replacing

     {{error}}{{translation key="platform.wiki.sheet.erroraliasdoesnotexists" parameters="$request.domain"/}}{{/error}}

by

     {{error}}{{translation key="platform.wiki.sheet.erroraliasdoesnotexists" parameters="~"${services.rendering.escape($escapetool.java($request.domain), 'xwiki/2.1')}~""/}}{{/error}}

Note that below version 7.1 milestone 1, the used escaping function isn't available and thus a different fix would need to be developed.

On XWiki versions 12.0 and later, it is also possible to import the document XWiki.XWikiServerClassSheet from the xwiki-platform-wiki-ui-mainwiki package version 14.4 using the import feature of the administration application as there have been no other changes to this document since XWiki 12.0.

References

  • https://github.com/xwiki/xwiki-platform/commit/fc77f9f53bc65a4a9bfae3d5686615309c0c76cc
  • https://jira.xwiki.org/browse/XWIKI-19746

For more information

If you have any questions or comments about this advisory:

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-wiki-ui-mainwiki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.3-milestone-2"
            },
            {
              "fixed": "13.10.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-wiki-ui-mainwiki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "14.0"
            },
            {
              "fixed": "14.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-36099"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-94",
      "CWE-95"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-16T17:22:28Z",
    "nvd_published_at": "2022-09-08T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nIt\u0027s possible to inject arbitrary wiki syntax including Groovy, Python and Velocity script macros via the request (URL parameter) using the `XWikiServerClassSheet` if the user has view access to this sheet and another page that has been saved with programming rights, a standard condition on a public read-only XWiki installation or a private XWiki installation where the user has an account. This allows arbitrary Groovy/Python/Velocity code execution which allows bypassing all rights checks and thus both modification and disclosure of all content stored in the XWiki installation. Also, this could be used to impact the availability of the wiki.\n\nOn current versions (e.g., 14.3), this can be triggered by opening the URL `/xwiki/bin/view/Main/?sheet=XWiki.XWikiServerClassSheet\u0026form_token=\u003cform_token\u003e\u0026action=delete\u0026domain=foo%22%2F%7D%7D%7B%7Basync%20async%3D%22true%22%20cached%3D%22false%22%20context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22hello%20from%20groovy!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D`, on version 5.3 Milestone 2 (oldest impacted version), the issue can be reproduced using `\u003cserver\u003e/xwiki/bin/view/Main/?sheet=WikiManager.XWikiServerClassSheet\u0026form_token=\u003cform_token\u003e\u0026action=delete\u0026domain=foo%22%2F%7D%7D%7B%7B%2Ferror%7D%7D%7B%7B%2Fhtml%7D%7D%7B%7Bfootnote%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22hello+from+groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Ffootnote%7D%7D`. In both cases `\u003cserver\u003e` is the URL of the XWiki installation and `\u003cform_token\u003e` is the token used for CSRF protection for the current user which is available in every HTML response (search for `form-token` or `form_token` in the HTML source). If the string `hello from groovy` without `println(\"` before it is displayed, the attack has been successful.\n\n### Patches\nThis has been patched in the supported versions 13.10.6 and 14.4.\n\n### Workarounds\nIt is possible to edit the affected document `XWiki.XWikiServerClassSheet` or `WikiManager.XWikiServerClassSheet` and manually perform the changes from [the patch fixing the issue](https://github.com/xwiki/xwiki-platform/commit/fc77f9f53bc65a4a9bfae3d5686615309c0c76cc), i.e., replacing\n\n```\n     {{error}}{{translation key=\"platform.wiki.sheet.erroraliasalreadynotexists\" parameters=\"$request.domain\"/}}{{/error}}\n```\nby\n```\n     {{error}}{{translation key=\"platform.wiki.sheet.erroraliasalreadynotexists\" parameters=\"~\"${services.rendering.escape($escapetool.java($request.domain), \u0027xwiki/2.1\u0027)}~\"\"/}}{{/error}}\n```\n\nand replacing\n\n```\n     {{error}}{{translation key=\"platform.wiki.sheet.erroraliasdoesnotexists\" parameters=\"$request.domain\"/}}{{/error}}\n```\nby\n```\n     {{error}}{{translation key=\"platform.wiki.sheet.erroraliasdoesnotexists\" parameters=\"~\"${services.rendering.escape($escapetool.java($request.domain), \u0027xwiki/2.1\u0027)}~\"\"/}}{{/error}}\n```\n\nNote that below version 7.1 milestone 1, the used escaping function isn\u0027t available and thus a different fix would need to be developed.\n\nOn XWiki versions 12.0 and later, it is also possible to import the document `XWiki.XWikiServerClassSheet` from the [xwiki-platform-wiki-ui-mainwiki package version 14.4](https://nexus.xwiki.org/nexus/content/groups/public/org/xwiki/platform/xwiki-platform-wiki-ui-mainwiki/14.4/xwiki-platform-wiki-ui-mainwiki-14.4.xar) using the [import feature of the administration application](https://extensions.xwiki.org/xwiki/bin/view/Extension/Administration%20Application#HImport) as there have been no other changes to this document since XWiki 12.0.\n\n### References\n* https://github.com/xwiki/xwiki-platform/commit/fc77f9f53bc65a4a9bfae3d5686615309c0c76cc\n* https://jira.xwiki.org/browse/XWIKI-19746\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n- Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n- Email us at [Security Mailing List](mailto:security@xwiki.org)\n",
  "id": "GHSA-xr6m-2p4m-jvqf",
  "modified": "2022-09-16T17:22:28Z",
  "published": "2022-09-16T17:22:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-xr6m-2p4m-jvqf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36099"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/fc77f9f53bc65a4a9bfae3d5686615309c0c76cc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-19746"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "XWiki Platform Wiki UI Main Wiki Eval Injection vulnerability"
}

Mitigation
Architecture and Design Implementation

Strategy: Refactoring

If possible, refactor your code so that it does not need to use eval() at all.

Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation
Implementation
  • Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.
  • Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
Mitigation
Implementation

For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

CAPEC-35: Leverage Executable Code in Non-Executable Files

An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.