Polyscripting takes a stand against would-be attackers looking to exploit the most dangerous kind of vulnerability?—?remote code execution.
Four months ago, Blue Gaston introduced the world to Polyscripting?—?the idea of making every WordPress instance speak a different programming language, thus making an attacker’s commands, written in PHP, ineffective.
WordPress is susceptible to a particularly severe kind of vulnerability called a Remote Code Execution, which is exactly what it sounds like: it enables an attacker to run commands and programs remotely on your WordPress. This is possible fundamentally, because every WordPress, everywhere in the world, speaks the exact same programming language?—?PHP.
With the previous update we posted, Polyscripting left a few questions unanswered?—?how would updates, upgrades and plugins work? How would modifying code or debugging work? Would this be easy to use? Would it scale for a hosting provider?
I’ll let you be the judge of that in our online in-browser demo of Polyscripted WordPress on our learning portal.
Before we get to Polyscripting, let’s run WordPress just like
we’re used to already. I’m going to assume you have a directory
where you have your WordPress saved (or would like it saved.) We’ll
$WORDPRESS for brevity and abstraction.
We can launch WordPress using the Polyscripting-enabled container, and mounting this directory:
docker run --rm -d --name wordpress -v $WORDPRESS:/wordpress --link mysql-host:mysql -p 80:80 polyverse/polyscripted-wordpress:b1805560d812c84e441b0ca0326c66bf5522c5ad
Note the link to the mysql instance. For this example, I launched it in Docker, but you can run MySQL any way you wish.
docker run --name mysql-host -e MYSQL_ROOT_PASSWORD=qwerty -d mysql:5.7
To use any different MySQL instance, modify the
$WORDPRESS where the
settings are used from.
You can upgrade WordPress, add or update plugins, and all
changes will be reflected in $WORDPRESS. In short, if you already
run WordPress and have
/var/www/html or some
equivalent of that, simply mount it in, and you’re well on your
On port 80, you should have WordPress?—?just the way you love it!
How exactly do we get Polyscripted? We add one environment
-e “MODE=polyscripted”, so the command
docker run --rm -d -e "MODE=polyscripted" --name wordpress -v $WORDPRESS:/wordpress --link mysql-host:mysql -p 80:80 polyverse/polyscripted-wordpress:b1805560d812c84e441b0ca0326c66bf5522c5ad
It may take a couple of minutes to start up (it is generating a brand new language on the fly, converting all of WordPress including plugins into it, and launching it.)
Polyscripting is so simple and easy there’s no excuse to not be protected.
As with all security, Polyscripting brings a minor inconvenience… and we really did make it a minor one. When Polyscripted, upgrades of WordPress code, the addition of plugins, and upgrades of plugins, don’t work. I’ll explain why this is the case with diagrams in a bit.
If you want to make changes, remove the environment variable
-e “MODE=polyscripted” and relaunch the container. Now
you’re back in PHP-based WordPress mode.
Two diagrams will make it all clear. This is what non-Polyscripted WordPress looks like inside that container:
Fairly obvious and straightforward. Also why updates, changes,
plugins, etc. just work. It’s your
directory directly serving the user.
However, when Polyscripted, here’s what happens:
Let’s see what’s happening in this mode:
$WORDPRESScontents are copied over into
/var/www/html(thus making Polyscripting safe and reversible).
/var/www/htmlare transformed from PHP into the new language using the recently generated transformer.
If you’re a WordPress user, you should be asking your hosting providers to enable this. We couldn’t have made it easier. Polyscripting for PHP is source-available and free for non-commercial use. If you’re a cybersecurity company that specializes in detecting attacks, look out for the best syntax error you’ve ever had, in your logs. If you tweet at @PolyverseCorp, we’ll send you this t-shirt: