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").

261 vulnerabilities reference this CWE, most recent first.

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.