Hacker News Reader

Comment by jacques_chester | Hacker News Reader

Wordpress isn't responsible; the faults are due to the design of PHP. The availability of the eval() and base64_encode() make these sorts of attacks basically unpreventable in untrusted sources.

View on HN

And not including eval and base64_encode would be ridiculous. No programming language is at all difficult to do nasty things with if you decide it's a good idea to include random untrusted code snippets.

Sandboxing would be helpful. Java-like or Lua-like.

Java-style sandboxing prevents all run code from having access to anything important on the filesystem (&c) which a) wouldn't really work for a server-run application and b) wouldn't at all prevent the type of nasty that shows up in those WP themes.

I'm not terribly familiar with Lua sandboxing, but a cursory overview suggests that absolutely nothing would prevent it from including similar nastiness if used in display code.

In any case, something like a website theme in any language, can always display HTML that is at least that hidden. So sure, kill base64_decode in php, but as long as you have a Turing-complete language which is at least moderately inevitable if you allow any logic in your templating system at all and you can implement the equivalent trivially.

If you completely neuter your templating system, then do something like include inline base 64 in CSS as image data, decode & exec using JS. Google's spiders will run JS now, unless I'm mistaken, so that's just as good from an SEO standpoint.

You're right, I retract the point.

OK, I would like you to introduce me to a programming language where installing source code downloaded from an untrusted website on the internet does not come with security caveats. Care to do so?

Sure. The JVM was engineered to include sandboxing for unsafe functions (disk access, for example). Lua allows quite granular sandboxing (look at what WoW takes away).

And that sort of sandboxing would prevent a theme from hiding some spammy HTML in its code? I can think of many ways to do that, some of which don't even involve templating-level functions and just rely on the HTML level alone.

You're comparing apples and oranges here. You can run PHP in "safe mode", as many shared hosts do, to prevent shell access and disk access by PHP code.

The only problem here is one of misplaced trust (and perhaps WordPress allowing PHP in templates instead of using a dedicated templating language). People installing WordPress templates generally a) don't care where they come from and b) don't even read the source code, so this theme could probably include such links without any obfuscation and still successfully spread.

> And that sort of sandboxing would prevent a theme from hiding some spammy HTML in its code?

No, but the problem is that the spammy code is being obfuscated using eval() and base64 encoding.

> You can run PHP in "safe mode", as many shared hosts do, to prevent shell access and disk access by PHP code.

Sure, so why have other unsafe methods?

I agree that social attacks cannot be completely prevented through technical means, but there's no reason to make it easy.

there are equivalents to eval and base64_decode in most languages (javascript, perl, python, ruby, etc). its not particularly the language's fault, either.

There are, but in retrospect these features might be worth removing from a web-specific language, along with shell-out capability.

edit: why the downvotes? Are these functions truly indispensable for this particular domain?

None of those languages are "web specific". Plenty of people write standalone programs with them. And the ability to execute shell commands isn't something you never need in a web application either. I can't count the number of PHP sites that do so, it's very common.

> None of those languages are "web specific".

PHP is meant to be. OK, I'm cheating and saying how it ought to have been with the benefit of hindsight. But the next web language will hopefully take these experiences into account.

yeah but you could still say that about any code. what's the difference between using an infected wp theme and downloading some freeware widget that also secretly logs your passwords?

Those themes just print out links to other sites. If you disallowed them to run any code, printing information out would be just as easy to hide:

    <script>......</script>

Nothing to do with the theme execution and still allows hiding code both via any encoding and via eval.

I don't follow. Could you rephrase your argument?

If you disallow running encoded script in php as an argument to the `eval()` function, the code could just as well be run in javascript on the client side (although it's not as useful for search engine spamming anymore then).

Basically for printing out some text on the website, it doesn't matter whether you're running

    <? echo eval($encrypted_code) ?>

on some php code or

    <script>eval(encrypted_code)</script>

in JS. The only thing it protects you from is local exploits, not adding content.

Ah. Yes. I see now.

This has nothing to do with PHP. Ton's of other languages have eval. Base64 is not the only way to obfuscate code. Even sandboxing addresses a -completely- different problem then this; this issue is that you're running arbitrary code from an untrusted source in the guise of your app.

Hmm, I think you've put the point well. Nevertheless, I think the concept of shrinking the allowed functions (sandboxing) is part of the mix.

Reply on news.ycombinator.com