3 ms·

> A compromised WordPress instance can also update itself, to be whatever the attacker wants it to be By this point, you're already on the other side of the ai

by mst 11y ago

> A compromised WordPress instance can also update itself, to be whatever the attacker wants it to be By this point, you're already on the other side of the airtight hatchway. http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/592350.aspx http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235... is a good example of this point. The goal here is to avoid the compromise in the first place, so the attacker stays on the correct side of the hatchway. There are plenty of logical reasons to hate wordpress, but I don't see that this is one of them.

falcolas 11y ago
> By this point, you're already on the other side of the airtight hatchway Not really. Having the ability for a web process to write its to files which it then executes actually opens up whole new vulnerabilities. For example: one popular PHP exploit is writing a PHP file, then executing it on the remote system. Can't write a file? Can't execute the exploit. Reading and executing PHP out of the DB, and also writing user input to that same database? Same problem. Triggering system-altering actions based on an unsigned token? That's a vulnerability. Letting an application be able to do more on a system than is absolutely necessary to operate is a great way to give control and information over to others.
- girvo 11y ago
  > Not really. Having the ability for a web process to write its to files which it then executes actually opens up whole new vulnerabilities. For example: one popular PHP exploit is writing a PHP file, then executing it on the remote system. Can't write a file? Can't execute the exploit. You're definitely correct, but there can be two different contexts to execute PHP; with differing permissions. If I was to rebuild how WordPress does it's autoupdating, I'd get rid of the god-awful HTTP "cron" crap, and have a proper PHP CLI that can do the updating, that runs on the server and is never exposed outside of it, and then WordPress itself, with the core outside the webroot and the uploads folder with zero executable permissions. Still not perfect, but it'd be a hell of a lot nicer than how it currently runs.
  - plorkyeran 11y ago
    Replacing the self-updating with an external updater does eliminate the problems with self-updating, but it's not a viable option for wordpress's primary deployment target of terrible shared hosting.
myhf 11y ago
The problem is that WordPress is designed as one big airtight hatchway. Any attack that gets through the first hatch has no further obstacles to persistence. Compare that to any application with a fully-reproducible build step. If it gets compromised, you can discard the container and replace it with a freshly-built one.

by mst 11y ago

falcolas 11y ago

> By this point, you're already on the other side of the airtight hatchway Not really. Having the ability for a web process to write its to files which it then executes actually opens up whole new vulnerabilities. For example: one popular PHP exploit is writing a PHP file, then executing it on the remote system. Can't write a file? Can't execute the exploit. Reading and executing PHP out of the DB, and also writing user input to that same database? Same problem. Triggering system-altering actions based on an unsigned token? That's a vulnerability. Letting an application be able to do more on a system than is absolutely necessary to operate is a great way to give control and information over to others.

girvo 11y ago
> Not really. Having the ability for a web process to write its to files which it then executes actually opens up whole new vulnerabilities. For example: one popular PHP exploit is writing a PHP file, then executing it on the remote system. Can't write a file? Can't execute the exploit. You're definitely correct, but there can be two different contexts to execute PHP; with differing permissions. If I was to rebuild how WordPress does it's autoupdating, I'd get rid of the god-awful HTTP "cron" crap, and have a proper PHP CLI that can do the updating, that runs on the server and is never exposed outside of it, and then WordPress itself, with the core outside the webroot and the uploads folder with zero executable permissions. Still not perfect, but it'd be a hell of a lot nicer than how it currently runs.
- plorkyeran 11y ago
  Replacing the self-updating with an external updater does eliminate the problems with self-updating, but it's not a viable option for wordpress's primary deployment target of terrible shared hosting.

myhf 11y ago

The problem is that WordPress is designed as one big airtight hatchway. Any attack that gets through the first hatch has no further obstacles to persistence. Compare that to any application with a fully-reproducible build step. If it gets compromised, you can discard the container and replace it with a freshly-built one.