Introducing Polyscripting — the beginning of the end of code injection

Imagine you’re walking into your first job in tech — ever. Crossing that border between a master’s program in computer science and real-world experience. Not really knowing what to expect, you’re shy, flustered, but dressed to the nines. At lunch with the team, everyone is friendly and pokes fun at your nervousness. You sit down at your empty desk. Before you even have a computer set up, the CEO and CTO tell you that your first task will be “to fix the internet.” Or something like that. Such is life at Polyverse.

Welcome to the beginning of the end of code injection.

Since 2010 and onwards the Open Web Application Security Project (OWASP) Top 10 List identified code injection as the number-one most critical web application security risk. In eight years, despite an acute awareness of this, little has been done to mitigate that risk, much less end this exploitation. It persists: a common, easily detectable security vulnerability with severe and costly impacts.

Why have we allowed the most severe known security risk in web applications to reign for so long? Think of the growth and progress made since 2010: we’ve seen the birth of cloud computing, the development of smart home devices, and a massive emphasis on artificial intelligence and machine learning. We collect and store more and more data, and create more and more connected devices. Yet the most critical technology at the heart of it all is left to battle a critical, known and glaring vulnerability. The time has come to stop building on top of something that is broken. Instead, let’s take a step back and secure the foundation — before we continue to build on it.

Polyscripting aims to dethrone code injection as the top security risk — not by following a list of “safe” techniques or writing meticulous workaround code and whitelisting, but by making the central component of code injection impossible.

That’s right: impossible.

Fundamentally, code injection is possible because, once a malicious actor finds an injection flaw, they can freely start feeding instructions into your program. This can disclose data, install malware on a server, and result in data loss or corruption. However, there is a rudimentary underlying factor that enables hackers to successfully exploit the injection flaw: that they know the programming language in which to feed the instructions. After all, I can’t very well talk to a program if I don’t know what language to use.

Polyscripting applies a Moving Target Defense strategy to the most basic aspect of programming: the language.

By taking a vulnerable server-side language (for this proof of concept, php) and scrambling the interpreter’s source code as well as your program files, Polyscripting generates a unique instance of that language. A language that behaves and acts just like php — but understands and looks like something completely different.

With a unique interpreter and a way to transform php code into the matching Polyscripted code; your program effectively has its very own completely distinct language.

What makes Polyscripting distinct is that it is irreversible. Once php is scrambled and the files transformed, there is no key or magic value to find that will reverse the process. Yet a Polyscripted language follows the same rules and observes the same patterns as the original language — it just does so using words and patterns that are randomized and unique to that specific Polyscripted-php instance.

You are able to write and test your code in standard php, but then run it with a scrambled interpreter and transformed files. So when a malicious actor tries to sneak in an “echo exec (‘whoami’);”, the language won’t recognize “echo” or “exec” as a valid call, and it will spit out an error. This is a beautiful example of the strength and significance of employing Moving Target Defense strategies to cybersecurity.

To demonstrate, here is a Polyscripted-php example with a small “hello world” program:

root:/pwd# cat hello.php
<?php
echo “Hello, “;
echo “Small World.n”;
?>
root:/pwd# php hello.php
Parse error: syntax error, unexpected ‘“Hello “‘ (T_CONSTANT_ENCAPSED_STRING) in /pwd/ hello.php on line 2
root:/pwd# cat scrambled.php
<?php
arFktyO “Hello, “;
arFktyO “Small World.n”;
?>
root:/pwd/php-src# php scrambled.php
Hello, Small World.
root:/pwd/#

The interpreter no longer understands the command “echo” but accepts “arFktyO” — a randomly generated string — and executes the same functionality as the previously defined function “echo.” While this example php’s keywords are being scrambled and changed, we can take it a step further and scramble the AST as well. We can thereby change the grammar of the resulting language, all while maintaining equivalent functionality. To further add to the beauty of Polyscripting , it will effectively act as free detection, because any execution-syntax errors will be an indication of unsanctioned code execution and a flag of a malicious actor.

To run through some test cases and see a simple prototype using php:

Clone the Polyscripting-php repository:
https://github.com/polyverse/polyscripted-php

From within the git directory run:

docker build -t polyscripting .
docker run — rm -it polyscripting bash

Within the Docker container, you first need to build up standard php then scramble it. Building php takes about ten minutes.

./build-php.sh
./build-scrambled.sh –t

Note: The –t option will first copy standard php outputs of all .php files within the tests directory into their own files, called expected_[filename].php

After php is scrambled try running any of the test programs.

/polyscripting-php/bin/php tests/smallWorld.php

Notice how these programs will not execute because they have not been transformed into the Polyscripted version. You must do this before you can run them:

./transformer –f tests/smallWorld.php

Doing so will result in a php file with the prefix “ps-” appended to the original file name. To execute the transformed file run:

/polyscripting-php/bin/php tests/ps-smallWorld.php

Read the ps-PlaygroundReadMe in the git repository if you’re interested in playing around a little more. 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.

Polyscripting has the potential to be the most powerful tool to defend against code-injection attacks. We are creating a new standard in what we expect from our programming languages —Polyscripting capabilities. Applying Polyscripting to other languages commonly exploited in injection attacks (think SQL, Javascript, Python) could very well end the injection vulnerability that has been widespread for well more than a decade.

We use it everywhere, every day. So it’s about time we fixed the internet. 😉

The registered trademark Linux® is used pursuant to a sublicense from the Linux Foundation, the exclusive licensee of Linus Torvalds, owner of the mark on a world­wide basis.