I disagree that these problems are inherent to PHP. If the themes were written in almost any other language, people would still download themes or plug-ins and put it on their webspace. Many of the WordPress users are not experienced in coding for the web and some are not aware of the potential dangers that come with scripts from a shady source. They only get interested in security when their sites get owned. In the first place they just want to blog.

There are similar problems with widgets that people like to install in a sidebar or footer, like counters, clocks, ... There have been several cases where the widgets used a JavaScript hosted on a different domain, and later the JavaScript was changed to something that redirected visitors to infected sites. Here no PHP or any other server side language is involved. This problem is older than WordPress.

Sorry, but who's talking about PHP here?

When the discussion started there were some remarks like this:

>Some of these problems are inherent to PHP

Also the availability of eval() and base64 encoding and decoding functions in PHP were blamed for the problems. You can find these statements if you read through the whole thread.

Every comparable language has an eval statement or equivalent. And the base64 functions are quite practical have around if you should ever have to ... eh ... decode or encode in base64. The problem here is not with PHP, but with naïve users installing software from a dubious source.

Yes, this is similar to what I wrote above. And the problem is even older than PHP. For as long as I can think back there have always been people clicking every colorful link saying "Click here! It's FREE!" and "Download for Free!". Back then the nasty payload came from cracked software and games, stuff like boot sector viruses. I wouldn't put the blame for this on assembly language.

I think he meant to reply to lkbruner[1] but "missed":

> Some of these problems are inherent to PHP

[1]: http://news.ycombinator.com/item?id=2131095

Yes, actually I wanted to reply, but my answer ended up as a stand-alone comment. I'm sorry for this, if it caused some confusion.

The whole WP ecosystem is very insecure. For example, it's trivial to add a back door to a plugin that gives you full access to their server. Wordpress desperately needs to add a screening process. You can't assume everyone will do a code review before installing stuff even if they should.

The key here isn't a screening process for themes and plugins available through a WordPress website. The themes which have the back doors are typically pirated versions of paid-for themes which are never going to get into a WordPress app store. People are always going to pirate themes, people are always going to install themes from dodgy sources when they are free.

The admin backend should simply search any newly-installed theme or plugin file for hard-coded URLs, and then display them to the user prior to activation. And throw a huge red flag if it encounters any base64 obfuscation.

It wasn't 24 hours ago that there was a pretty hard-core obfuscation example of what you can do with a bit of javascript, I can't imagine that method would be easy to detect when extended to 'hard coded urls'.

You'd have to actually run the scripts embedded with real-life parameters in order to observe any malicious behavior.

in case you missed it: http://news.ycombinator.com/item?id=2129745

So what if malicious plugin writers then decide to encode urls like described in this story: http://news.ycombinator.com/item?id=2129745

How will you detect that with a scan?

The main goal of the high-ranking templates seems to be to add links to specific sites (to boost their PageRank). Those links are unobfuscated for the search bots, with the encoded JS serving to replace them for humans. So mortenjorck's suggestion would still apply.

However, including any JavaScript is arbitrary exploitation, but perhaps there's less of an incentive once the Google-bombing aspect is removed.

It's less javascript than PHP you've got to worry about; that javascript obfuscation article was a nice example of how much you can mangle a language to hide things.

For example, in your Wordpress template, put the following snippet in:

  <?php echo urldecode('%68%74%74%70%3A%2F%2F%67%6F%6F%67%6C%65%2E%63%6F%6D'); 

This will display "http://google.com on your page.

Okay. So how about looking for urldecode (a perfectly useful function, with uses not restricted to hacking)?

  <?php $f=chr('117').chr('114').chr('108').chr('100').chr('101').chr('99').chr('111').chr('100').chr('101');
  echo $f('%68%74%74%70%3A%2F%2F%67%6F%6F%67%6C%65%2E%63%6F%6D');

... And so on, ad infinitum. Looking for particular sequences (%68%74%74%70%3A%2F%2F --> http://)? Add numbers together at run-time. Looking for a block of these together? Spread them out, or construct them from innocuous-looking things.

It's a game you're not going to win.

By the time you've rendered the page, it's already too late. In rendering the page you're running the untrusted code.

Wordpress themes are a double-edged sword--Wordpress became what it is today because of the flexibility that themes provide, but it comes at a cost. Other theming engines traded flexibility for security, and as a result aren't nearly as popular.

That's completely untrue :P

You're assuming that there is some supreme Rendering Engine which maps code to a single canonical output. In reality, every browser renders things slightly differently and a malicious script would take advantage of that (while rendering things "normally" for the scanner). See also: cloaking (http://en.wikipedia.org/w/index.php?title=Cloaking&oldid...)

You're right of course, but again, the scanner would not go after sophisticated or complex attacks, but naive attacks implemented by posers.

It's just a matter of time before everything we currently consider "secure" is cracked; I reckon that eventually they'll have computers that can bruteforce 2048-bit encryption keys (and I've seen all of the theoretical calculations about the computing power needed to do that, so we don't need to repeat that here) in a day or less. That doesn't mean we shouldn't make the best of what we have at our disposal, whether that's encryption or detection techniques to catch at least some bad guys.

You mean like the exploit scanner as linked to from the source article? Make that part of core WordPress and scan for other obfuscation techniques too and you're well on the way to improving things.

No, that means you'll be well on the way of improving the obfuscation techniques.

Scanning a piece of code to try and decide if it is "malicious" or not is essentially the halting problem, which is impossible to solve. As long as you have a system where you install third-party code you are screwed, no matter what the base language is.

For Wordpress themes as they are currently implemented, this is true, but the concept of being able to decide whether a given piece of code will do specific things is known as sandboxing and has many real-world implementations. You can be relatively certain that code running in specific sandboxes will not perform specific actions. You can be relatively certain, for example that an unsigned Java applet won't transmit data over a network to a third party.

It wouldn't be hard to design an HTML templating system that would never render the string "<script", to provide an overly simple example. Making such a system popular enough that malicious themes are an issue worth worrying about is left as an exercise for the reader.

That doesn't mean it's totally pointless to look for blatant exploits. A lot of script kiddies are going to use naive and obvious methods that can be caught with simple automated scans. While this method may not catch 100% of occurrences, it can certainly help.

Well, that depends on your point of view. My personal opinion is that such a system would give people a false sense of security (since we know it's impossible for such a system to detect all malicious content) and would cause "script kiddies" a few minutes of annoyance as they make the tiny tweaks necessary to evade the filter. It would also drain development effort away from the main Wordpress system.

As long as the system doesn't make extravagant claims there shouldn't be a problem. A message on each page of the scanner like "This is only a precautionary measure that checks for known exploits; there can still be malicious code in any third-party code. Only use themes or plugins from sources you know to be safe." should not give a false sense of security, but can still help things.

Anti-virus and anti-spam applications can never be 100% effective either, but we use those because they're useful on occasions where they do work. Should we give those up altogether because, since the virus writers merely have to look up circumvention techniques, it's a waste of programmer time?

The WordPress team has thought a lot about this issue, and the most effective solution so far has been to have robust official sources of themes and plugins and educating people to get everything from WordPress.org. (It's the only source built-in to WP software.) It's our equivalent of airplane security's "tougher cabin doors and passenger's willingness to fight back."

An automated scanner in core might temporarily relieve some of the current techniques of spammers but it would be trivial to vary obfuscation to evade any automated check, and I worry more about the false sense of security they would provide. A built-in automated checker would not make it safe for you to Google around random sites and install their software to execute on your server.

On the plus side, we now have over 1,300 themes in our official repository and every single one of them has been verified by hand.

Wordpress themes aren't the only ones guilty of this. Shady plugins also contain hidden code.

http://www.themelab.com/2009/12/08/stop-downloading-wordpres...

TAC (Theme Authenticity Checker) isn't a bad place to start searching for malicious code: http://builtbackwards.com/projects/tac/

However, the only real solution to this problem is to run a limited set of extremely trustworthy plugins and build your own themes.

> However, the only real solution to this problem is to run a limited set of extremely trustworthy plugins and build your own themes.

What on earth? It's pretty simple to check for malicious Javascript or PHP code in a theme.

It is fairly simple to check for obviously malicious JS or PHP code in a theme, but it's not so easy to find themes which are badly written and thus insecure. Can you always spot a XSS or SQL injection vulnerability?

What is your exhaustive definition of "malicious" in this case?

Let's see:

1) Anything linked outside of the domain. 2) Anything not HTML/CSS/image/Wordpress tag/Javascript libraries 3) Anything encrypted.

Let me know if I missed anything.

Do you whitelist the Javascript libraries? Who certifies them? Is having a base64 decode function available from the library a problem?

Do you scan the CSS for url() references outside of the domain?

1. Most Wordpress theme developers use popular Javascript libraries, so it wouldn't be too difficult to replace them with the original if you suspected something was amiss. The function wouldn't be a problem, if there wasn't any base64 code. 2. url() references should all be relative, in the same domain, so if it linked on the outside, I'd change it.

Most of the time I use a Wordpress theme as a starting point, rewriting some parts and looking over all of the code.

Also, mentioned above, securing the theme against injections and XSS is important.

Do you scan images provided with the theme to check if any subset or combination of subsets of their contents can be malicious when base64 decoded?

I wonder how many people who run WordPress think it's pretty simple to check for malicious Javascript or PHP code in a theme?

Reminder: if you're typing "sudo gem install ..." or the equivalent in your language of choice, you could be installing Wordpress.

OSS doesn't mean somebody else audited it for you.

Huh? Wordpress is just fine (well, fine enough..), it's the themes from shady 3rd party websites that are the issue being talked about here.

You say "Wordpress is not fine", but yet this is a perfectly valid link: http://www.kalzumeus.com/wp-admin

I understand the point you're making here, Patrick, but it does feel slightly hypocritical for you to deride something as "not fine" when it seems to suit your needs just "fine."

It would be interesting to analyze whether the code was actually malicious (or could be used for malicious things) or spammy but benign.

I think the fact that the authors were using base64 encoding to hide it answers your question.

No, it doesn't.

Is it shady? Yes. Would I want it running on my server? Absolutely not. Is the code running a backdoor that lets the attackers execute shell commands? We don't know.

Obfuscation like this could be used for any number of things. Themes sometimes have credits at the bottom (i.e., "This theme created by John Smith"): the obfuscation could be an attempt to keep people from finding/removing the credit. It can also be used to include shady backlinks to other sites. And as I mentioned before, it could be used to allow arbitrary code execution. It's all a matter of degrees, and it DOES matter which it is: one is dangerous and the others are just shady.

If a user is already intent on removing a credit url, hiding it behind obfuscation isn't going to change their mind. As an author giving out an effectively open source theme, the only asset you can depend upon is your users' goodwill.

I think WP would be better off if it just automatically pruned these calls at the time of import, and if it breaks the theme, maybe the author should consider being more honest.

I'm not saying that there's isn't a difference between code that's merely obnoxious and code that's actively damaging, but rather that both should be discouraged whenever possible.

"If a user is already intent on removing a credit url, hiding it behind obfuscation isn't going to change their mind. As an author giving out an effectively open source theme, the only asset you can depend upon is your users' goodwill."

I was simply suggesting a more benign reason why this code might exist: I'm not defending it. ;)

What calls do you suggest Wordpress disallow though? Eval isn't the only way to execute a string as PHP code ;)

Interesting point, actually.

I'd like to see that same analysis now that you've brought it up just for the sake of pure curiosity. WP powers a good chunk of the blogosphere (including The New York Times website) out there now, and this kind of data could get some very good discussion going.

> Though it can be argued that it's possible in some cases it's both; in the case of Gawker, perhaps there was a theme add-on that possible opened or exacerbated a hole resulting in the password leak.

Gawker run a custom platform, not Wordpress.

Ah, thank you for the correction

No worries. Gawker was compromised through ordinary social engineering, basically. In some ways these faux themes are in the same class of attack.

Being spammy can be malicious. The black hat SEO folks know full well that these sorts of spammy links can lead to innocent folks' WordPress blogs getting eventually penalized or blacklisted from search engine indexing.

Despite what my degree says, I'm a horrible computer scientist. But would this be a bit like solving the halting problem? squint

I didn't mean a fully automated analysis (although it's possible to somewhat automate the de-obfuscation: see http://php-security.org/2010/05/13/article-decoding-a-user-s...). But given a bit of time, it should be possible to "unwrap" the obfuscated code in more detail and see what it's actually doing (which wasn't done in all cases).

I stopped hosting my personal rant blog and went with wordpress.com free hosting. I have given up trying to patch, update, comb through every plugin, theme, whatever. Having said that, I don't care if the hosted wordpress blog gets hacked. Losing some written word is something I can live with as long as the server isn't mine.

I have entered a period in my life where I only trust static code. I write all content in a meta markup language, I run a static page compiler on the directory structure and upload the created html and resources to the server.

Consider this the iOS versus Android equivalent on the web. You can either take the app store approach to themes and plugins and police every bit of code uploaded to codex or it can be the Andoriod model where there is no proactive policing.

Somehow, I don't think the Wordpress app store is going to make much progress at Automattic. It will require them to put in considerable resources to policing the code than improving the core.

The other way is to have a the Wordpress core bootstrap allow only a whitelist of functions to be called, which would have the effect to severly curtailing the flexibility that is required by plugin/theme developers.

Mind you, these problems are there not just with PHP/Wordpress. You can have the same issues with Chrome/Firefox extensions, bookmarkelets and most of the add-on models where you are running code that has not been subject of a decent audit.

The trouble for Wordpress/PHP is the footprint they have on the web now, which makes them pre-Vista/7 days for Microsoft on the web. You could probably do similar nasty things with a fancy jQuery plugin, but it is much better bang for the for the buck for the evil guy to have a go at something that is so widely installed and used by a large number of people who would not know it even if you were to show them code that does nasty things.

On other hand, a certified/curated theme/plugin/app store for all ecosystems that follow the reactive model to policing add-ons is a great idea for a start-up. I have been amused that nobody's done it so far. I know there are directories, but they don't test/audit the apps. Someone should give it a shot.

Creating advertising supported themes is a legitimate business model, and trying to stop someone removing the advertising by obfuscating code isn't really any worse than, say, distributing binaries to software which have been compiled to make it harder to change the source code.

I personally don't like to use software projects which aren't Free / Open Source (meaning that the full, unobfuscated source code is available and you are free to do what you like with it) - but I think it would be a stretch to say that distributing binaries or obfuscated code is automatically shady. You have to trust the person that makes the site, but asking someone to trust you is not synonymous with shady unless you then violate that trust.

Of course, if the sites are plagiarising other people's work without a license, including malicious code, or misleading people about what the code does or doesn't do, then there is a legitimate concern.

This is just one of the reasons I recommend Jekyll - a static HTML blog generator. It's an excellent piece of software written by Tom Preston-Werner you can read about here: http://github.com/mojombo/jekyll/wiki

Better performance + security and you can use Textile!

Thanks to your comment I've lost four hours of my life to fiddling with Jekyll. Thanks for making my Sunday night more interesting.

Can't base64 be used to encode small images, like icons? I'm sure that I've seen this in desktop apps. Why didn't the author decode them all, instead of just the last ones?

Also, did the tone of the article bother anyone else? It made me cringe after every few phrases.

> Can't base64 be used to encode small images, like icons?

Yes, but if the "base64_decode" function is being used in the PHP code for the theme, chances are that it's being used to hide something.

I noticed that a few months after I put up a list of themes for bbPress (WordPress's little sister for forums) someone started a website that copied them all for download (which is fine because they are GPL) but then inserted all sorts of malicious spam links and other code into them.

Despite my warnings to users and trying to get Google to put that site into their security blocklist (never happened) I can now search for and find hundreds of sites that have these spam links from using those bad copies.

Anyone know if contributed code for other website platforms (Drupal, Joomla, DNN) etc. has similar issues? Is there any sort of "vetting" that goes on?

I actually worry more about the cheap but commercial modules, vs. the free/open source ones. With open source modules, chances are someone has perused the code looking for any signs of mischief. With the commercial code, often authored in another country, who knows?

> Anyone know if contributed code for other website platforms (Drupal, Joomla, DNN) etc. has similar issues?

Absolutely. It's common to all these programs because they all use the LAMP architecture, which includes PHP (eval() and base64_encode()) and an inability to securely partition the data (can't have multiple users in the DB).

> which includes PHP (eval() and base64_encode())

At least Python, Ruby and Perl have those functions too. The problem is not related to PHP being able to eval(), it's:

1. Inadequate usage of PHP as template engine, where templates are coming from untrusted sources. Think of this as very extended case of non-sanitizing user input.

2. "Dancing bunnies"-type problem. A lot of users don't understand what they are doing. They are promised they would get a nice theme, so they install it.

> can't have multiple users in the DB

Wrong, it's perfectly possible. Unless you are stuck with some god-forsaken cheap crappy LAMP hosting.

Disclaimer: I don't like PHP at all, and I try to avoid it. Experts say, and I totally agree that there are a lot of various problems in LAMP ecosystem, but they lie in very different direction.

> Wrong, it's perfectly possible.

I thought so too, but in practice it doesn't work (I proposed it to them a while back).

Wordpress stores database credentials as globals. Even if you gave each plugin its own permissions, they could always go straight to the superuser account for that database.

> can't have multiple users in the DB

What?

PHP doesn't have a DB, and MySQL sure as hell allows multiple users.

See my other comment in the thread: the design of Wordpress relies on a global variable to hold database credentials.

STEP 1:

Make every theme/plugin author create a private key to sign their releases. Their public key will be available on their profile page and via API. Wordpress will notify you if the public key for an author has changed or if a release signature doesn't match the public key.

Why is this not done?

(Also in other software that uses plugins and is updated easily over the internet.)

That's largely not going to make a difference. You can already mostly trust themes and plugins listed on the WordPress.org website. The themes with the bad code are the ones available elsewhere, and quite often are pirated versions of commercially available themes.

I shiver when I think how many pieces of code are fetched over the internet on my machines.

If you are a motivated attacker you can compromise a plugin author's PC or server and silently push a backdoor to a whole lot of people.

Signed releases are commonplace. It would make sense to require them in most plugin systems, especially those with central plugin repositories and lots of users.

Isn't this primarily Google's fault? Their algorithms should be capable of weeding out the bad sites.

Not only the free themes but I see many pirated commercial packages on torrent websites. It's very tempting to download all these 50 woothemes, even just to try them out ... but the fear of hidden code just too strong.

While your fear of hidden code is probably well-founded, I don't think it's piracy to redistribute the WooThemes. They have been released under the GPL. (http://www.woothemes.com/2009/06/woothemes-gpled/ and http://www.woothemes.com/terms-conditions/) For what it's worth, I've happily paid for the WooThemes I use.

Not to mention that even if they haven't been explicitly released under the GPL, they are derivative code upon a GPL-licensed piece of software and thus GPLed themselves.

One might argue. Plenty of others, including lawyers, have argued that isn't so. There are even court decisions to support that WP themes and plugins may not be derivative works. Nobody can say definitively until there are some actual cases resolved in court to provide guidance.

I found some of the offending code when I downloaded a free theme the other night.

It took me around 5 minutes to:

1) open footer.php 2) echo base64_decode('code') 3) take out all of the links and paste the rest of the code in the footer.

Problem solved.

Ironically, most of the base64 "encrypted" code is easier to read than the Wordpress core...

interesting to note that these are also some generally ugly themes.

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.

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.

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.

Some of these problems are inherent to PHP, but the WordPress team has decided to work with PHP, therefore the problems of PHP are also legitimate issues to raise with the WordPress team. That is to say, in accepting PHP as their language, the WordPress team must take responsibility for that choice, and that includes confronting the security risks that arise from the choice of language.

Sam Ruby made this same point, and he said it much better than I can hope to (he is responding to Matt Mullenweg in the comments):

"Those that contribute to PHP apparently feel the most pain concerning support of multiple versions. Yes, you can argue that they brought this upon themselves; but it is worth noting that at this point you are along for the ride. When I’m in similar circumstances, I tend to consider the karma implications of cursing the driver. In any case, some people who are along for the ride with WordPress happened to cross my path yesterday. Perhaps you are in a position where you can help them. To my eyes, I see a bug that was reported on WordPress 2.1, and the milestone on that defect is currently set to 2.3. Hopefully the users affected won’t have a tendency to kick, or scream, or rant too much."

http://intertwingly.net/blog/2007/07/17/Popular-Sovereignty

There is another way to look at this. Microsoft has faced 30 years of criticism of its decision to promote features rather than security, a problem that began with DOS and lasted at least until Vista showed up.

That same type of criticism can and should be made against the WordPress team. They promote features to make the user experience pleasant, but their attitude towards security has been horrible.

What can they do? They can automate the test that Siobhan Ambrose does in the above article linked to by this thread. At the very least, WordPress can search a theme for Base64, so that when you try to activate the theme, you get a warning:

"These templates contain Base64, which may be masking malicious code. Do you wish to proceed?"

Again, it was the choice of the WordPress team to use PHP, so they must take responsibility for the choice of language. As Sam Ruby said, "It is worth noting that at this point you are along for the ride. When I’m in similar circumstances, I tend to consider the karma implications of cursing the driver"

More so, WordPress became popular because it was easy for designers to work with, and the WordPress team has certainly participated, and encouraged, the creation of a culture in which the promiscuous sharing of templates seems normal.

It is irresponsible of the WordPress team to ignore the security issues that this raises.

I am about as big (read: little) of a fan of PHP as the next guy but how in the hell are these problems inherent to PHP? If I were to run COBOL code from untrusted sources on my server you can forget about security.

Why does WordPress allow people to run untrusted code?

You write:

"If I were to run COBOL code from untrusted sources on my server you can forget about security."

That is why there should be a warning about untrusted code. Are you trying to let WordPress off the hook? Their attitude toward security has been horrible and they should be called out on it. I quote myself:

What can they do? They can automate the test that Siobhan Ambrose does in the above article linked to by this thread. At the very least, WordPress can search a theme for Base64, so that when you try to activate the theme, you get a warning:

"These templates contain Base64, which may be masking malicious code. Do you wish to proceed?"

It doesn't matter if WordPress is written in PHP or COBOL, the team developing the software should make some attempt to address its many security flaws.

Please consider the odd use of the word "disrespectful" in this paragraph:

"It seems fundamentally disrespectful to users who are simply caught in the crossfire of a political power move their neither know or care about. PHP core has never shown any particular regard for its biggest apps, as evidenced by the above bug and others, so I’m not sure why we should go out of our way to promote their upgrade. PHP 6 sounds much more compelling."

http://ma.tt/2007/07/on-php/#comment-422760

That is Matt Mullenweg. Please note that his statement can be turned on its head. I could write:

"It seems fundamentally disrespectful to users to create software for them that has lots of fun features but no security."

The downvoting on Hacker News sometimes seems wholly random. I am curious who would down vote this above comment of mine. I'm looking at each sentence and trying to think what people are disagreeing with.

For instance:

"That is why there should be a warning about untrusted code."

What is the counter-argument, that WordPress should do nothing about the fact that the templates allow the execution of arbitrary code?

"It doesn't matter if WordPress is written in PHP or COBOL, the team developing the software should make some attempt to address its many security flaws."

What is the counter-argument, that WordPress has no responsibility for the security flaws in WordPress?

Very curious.

The downvoting is probably due to your tone, I read your comments and agreed with you but god why do you write like that - why do you keep quoting people with "You write" style opening lines? it sets the tones of your comments off in the most horrible light.

There are two different walls of text here and I'm not going to respond to both but your argument has gone from "PHP sucks" to "Wordpress sucks."

Basically my point is this: every bit of software you run on your web server is a security risk. You shouldn't run themes, or any code, really that come from sources you don't trust unless you audit it completely. I don't think the blame really lies with PHP or Wordpress in this case.

At no point did I say that PHP sucks. At no point did I say that WordPress sucks. I have suggested that the WordPress team is responsible for security risks in WordPress, regardless of what layer the risk may originate from. Again, I would quote the advice that Sam Ruby gave to Matt Mullenweg:

"Yes, you can argue that they brought this upon themselves; but it is worth noting that at this point you are along for the ride. When I’m in similar circumstances, I tend to consider the karma implications of cursing the driver."

That is good, and necessary, advice for any software project.

Different programming environments enforce security to different degrees, with different defaults. I'll here post some of the many criticisms that have been aimed at PHP over the years:

Andrew van der Stock writes:

--------------

For some time, I’ve been worried about the direction of PHP. As many of you know, I helped write XMB Forum and now help write UltimaBB. XMB in particular is an old code base, and UltimaBB, a descendant from XMB. I’ve done a lot to protect that code base from attack, and luckily, we’ve been missed despite some doozy and silly security issues. After writing PHP forum software for three years now, I’ve come to the conclusion that it is basically impossible for normal programmers to write secure PHP code. It takes far too much effort.

PHP needs a proper security architecture, and support for newbie programmers. PHP’s raison d’etre is that it is simple to pick up and make it do something useful. There needs to be a major push by the PHP Development team to take this advantage, and make it safe for the likely level of programmers – newbies. Newbies have zero chance of writing secure software unless their language is safe.

Think about Logo for a minute. Logo can do some interesting things, but it is not a commercially useful language because it cannot do much. But it is an excellent teaching language. PHP is like Logo – it’s a simple and easy way to get into serious web development. It is possible to write large applications in PHP, so it is useful at that level. But it is inherently unsafe as it can do far, far more than Logo.

There are so many ways to break PHP that it is impossible for even experienced security professionals like me to code in it securely all the time. There are nearly 4000 function calls, and many of them have unintended consequences or have been inappropriately extended by something else.

http://www.greebo.net/2006/01/04/php-insecurity-failure-of-l...

---------------

Tim Bray put together a collection of links regarding criticism of PHP:

http://www.tbray.org/ongoing/When/200x/2006/02/17/PHP

On that page, there is this from Dominic Mitchell:

"I’m in 100% agreement with you about the whole PHP thing. Every time I’ve looked at PHP, I’ve been unable to find out how they use placeholders in code that talks to the database. Yes, every database adaptor provides a quote function, but nobody uses it (consistently). And people wonder why PHP code is always full of security holes. It’s a real shame, as I can see that there’s a lot to like in PHP. But it really needs to clean its act up to appeal to people coming from other programming languages, instead of just people coming from dreamweaver. I actually heard David Heinemeier Hansson (sp?) talking about rails the other day. One of the key points he made is that it should be easy to do the right thing. That’s why Rails hits a sweet spot for me. But when you look at PHP, yes, it’s easy to code, but it’s not easy to do the right thing. That’s where it falls down."

The point that Hansson makes about Ruby is worth thinking about in the context of PHP security. Does PHP make it easy to write secure code? Does it help programmers do the right thing? The defaults in PHP, and the underlying assumptions of PHP, all tend in what direction?

Of those links, Jonas Maurus's post is also well worth reading:

http://maurus.net/resources/programming-languages/php/

Aristotle Pagaltzis sums up the underlying problem:

"All of these flaws are interconnected; the morass is simply the result of the language being a templating system that grew too big for its breeches. I don’t believe the problems can be corrected in any sensible fashion; PHP will always be a templating system, however much it may be straining against its clothes. And let me tell you, it’s still a great templating system! If all you need is to write a web app that consists of two pages, running four queries over a five-table database, there is nothing that will get you up and running faster."

http://plasmasturm.org/log/393/

And none of these posts you're referencing are at all relevant to the issue at hand (unless you're taking the position that PHP is Pure Evil as a language, which is an entirely separate issue)! ;-)

The question at hand isn't whether it's easy or hard for someone to write secure code in PHP (my opinion: it's not easy, but it's certainly possible). The issue brought up in the article is that a lot of the top search results for "Free Wordpress Templates" lead you to templates containing obfuscated code, some of it malicious. That isn't a language issue: as many people have pointed out to you, it's a consequence of running untrusted code.

Now, you can certainly debate whether or not this is a Wordpress issue. On the one hand, the Wordpress team could choose to write their own custom templating language that doesn't include the ability to do things like eval base64 strings. But if they did go down that path, they would also be severely restricting what theme developers are capable of doing (and that wouldn't solve any issues with JavaScript or any number of other subtle issues that malicious authors could introduce).

My personal take is that this is a case befitting the quote "with great power comes great responsibility." That is, the people running Wordpress blogs need to be aware of the risks when they install plugins or themes. The Wordpress team has built tools into Wordpress that encourage people to download and update plugins and themes from Wordpress.org, which is seemingly more legitimate than these random sites (I'm not sure if there's a formal evaluation process for plugins/themes submitted there). Beyond that though, I don't think it's the fault of the Wordpress developers if people choose, whether out of ignorance or carelessness, to download and install random themes from the Internet. I mean, I don't blame Microsoft if I go searching for "free [software name]" and end up downloading a virus. ;-)

"with great power comes great responsibility" is an idea that applies to the WordPress development team too. "Great power" is not how I would describe some random blogger who wants to start a blog about their dog. "Great Power" might be more applicable to Automattic. Certainly, if they want to leverage WordPress commercially, they have large responsibilities.

And they do so, in the form of Wordpress.com. If what you want is a blog about your dog, you can have it for free with Wordpress software that you never have to manage the code for or pay for. I have a number of friends who use it and they couldn't be happier. In fact, there are plenty of other SaaS vendors out there who are equally happy to provide you with a place to write about your dog.

On the other hand, if you're running your own web application, you're responsible for it, just the same way you're responsible for your computer. As I said, I don't blame Microsoft if I download random software and that software does malicious things. Similarly, I don't blame Wordpress or Automattic if I download a random theme and it contains malicious code.

I can not follow what logic keeps you from blaming Microsoft for the security lapses in the Microsoft operating system. Of course they have cleaned up their act in recent years, but they had a solid 25 year run (both DOS and Windows) where they were absolutely notorious for poor security. They faced sharp criticism for the many flaws in their OS, and for the low priority that they gave to implementing something better. Do you want me to google some of the many articles on this theme? Here is one from a few thousand results that I could pick from:

http://sec-soapbox.blogspot.com/2007/03/why-is-windows-insec...

My criticism of the WordPress team follows the same logic as the criticism of Microsoft. Since Microsoft came up with an OS that had a lot of security flaws, it was reasonable for people to criticize Microsoft for those flaws. And since the WordPress team is producing software that also has flaws, it is reasonable to criticize the WordPress team for the flaws in the software they produce.

Ah, come on.

The only concrete charge you bring forth here is to the practise of using string concatenation for sql parameters. Since v. 5.1 (Which is something like 5 years old .. in Internetyears, that's one century), PDO has been the default db-access layer, and it supports bound parameters.

Oh, and I've seen plenty of unescaped string concatenation in Rails apps too. It's a developer issue - not a language issue.

Those problems are not inherent to PHP (directly), but to WP not using any sort of (intentionally capability-limited) templating system. A design flaw - because probably WP devs never considered templates would be provided by untrusted sources.

The (painful) solution is to throw away current templating approach, and use some template engine instead. A bit less painful solution would be a compiler from some restricted language to current PHP-based templates, and declaring current approach deprecated, warning users of problems and highly discouraging them from using any untrusted PHP code.

I don't think you can blame the templating system when the plugin system is vulnerable to precisely the same issues, namely arbitrary code execution—except, of course, that the attack profile is so much broader for plugins since people will only have one template running (or two if they're using a child theme), but typically, many plugins.

These problems are not inherent to PHP. As other people have pointed out, this is what happens when you run arbitrary code on your server. Even if you took away the base64 encoding and eval calls, people could still embed spammy links into the page.

That is exactly why WordPress needs to get serious about security. It's current attitude has been extremely slack. Their focus has been on releasing features that allow for a more pleasant user experience, rather than releasing features that enhance security. Above I compare the attitude of Microsoft to the attitude of Automattic. Justifiable criticism was aimed at Microsoft for promoting fun new user abilities, rather than security, in both DOS and Windows, for a long time. The same kind of criticism can be aimed at Automattic.

What can they do? At the very least, they can automate the test that Siobhan Ambrose does in the above article linked to by this thread.

Automate what test? Searching for calls to base64_encode? Five minutes after they do that, people will write their own base64-encoding functions. Security by blacklist is not security at all.

My friend, your comment is remarkably besides the point. If we can agree that the WordPress team needs to focus on security, then we are basically in agreement. The details of how to do this can hopefully worked out by the WordPress team. They have certainly been given good advice over the years, much of which they have tended to ignore. Perhaps they will begin to listen. Given the scale of WordPress's success, we must hope they reform their ways.

Ideally, at some point soon they will recognize some of the dangers that arise from using such an easy-to-set-up language as PHP, and they will recognize that they appeal to a largely non-technical audience, and they will start taking some responsibility for their choices, and their success.

> My friend, your comment is remarkably besides the point.

In what way? You don't seem to understand how useless black-list codescanning is, a competent malicious programmer will find ways around those in minutes.

> Ideally, at some point soon they will recognize some of the dangers that arise from using such an easy-to-set-up language as PHP

Dangers such as?

You write:

"Dangers such as?"

I find it hard to believe that you do not know the dangers. Please google "php sucks" or "php security" and you will discover thousands of articles that address what I referenced above when I wrote "the dangers that arise from using such an easy-to-set-up language as PHP".

I also just posted a long comment up above in this thread, where I post quotes from several articles that have described the insecurity and disorganization that PHP makes so easy to achieve. You can view it here:

http://news.ycombinator.com/item?id=2131602

Or, here is another:

------------

But PHP has more than a few security bugs: in many ways PHP is fundamentally flawed. The program, whose initials originally stood for Personal Home Page, was designed without much thought given to security. Many of the PHP features that make it really easy to write a Web application also make it really difficult to write one that's secure.

All of this matters just now because Stefan Esser, the founder of the Hardened-PHP Project and the PHP Security Response Team (which he recently quit), has threatened to make March the "month of PHP bugs." By that, Esser means that he is going to be releasing a series of security bugs in March that show the world just how unsecure PHP actually is.

What's driving Esser is both a desire to make PHP more secure and a good touch of anger and resentment at the current PHP developers who have taken many of his security patches and incorporated them into the program without giving Esser any credit. You can read more about his motivations in his blog entry and in the interview that he did with Security Focus.

How will this affect users of the Web? Well, a recent "Month of Bugs" project aimed at Apple identified a number of security problems that the company was apparently unaware of, but it didn't result in any serious worms or threats to Apple users. This month of PHP bugs might be a similar bust. On the other hand, Apple was able to push out a fix to these problems using the Mac OS Software Update feature. PHP has no such feature, and many ISPs run kind of elderly (and buggy) versions of the program.

http://www.technologyreview.com/blog/garfinkel/17538/

I'm a big fan of Stefan Esser, but this has no relevance to the discussion at hand. You're just regurgitating a lot of anti-PHP rhetoric.

The issue - obfuscated code in third-party templates - is hardly inherent in PHP. The same technique can be used in any other popular web language.

For example: http://api.rubyonrails.org/classes/ActiveSupport/Base64.html

Rails looks for files in specific locations to execute code, not arbitrary encoded strings.

Yes, it's possible to do, but much harder than eval'ing a string in the resource file.

> Rails looks for files in specific locations to execute code, not arbitrary encoded strings.

The examples from this article are all essentially malicious third-party code. No language will save you from that.

That is why WordPress should save you from that. The WordPress team has had an awful attitude about security. They encourage a culture of free templates shared widely, without much regard for warning users of the dangers. Most users of WordPress are non-technical, the WordPress team knows this and shows no particular concern about it. WordPress needs to get serious about offering some security checks.

Start checking templates and plugins for `base64_decode` and they'll just start using a new technique to hide these things. The solution is one they've already implemented - a trusted source for templates and plugins on WordPress.org, and the WordPress.com site for folks who really shouldn't be administrating a LAMP environment anyways.

There are several solutions that can be tried, and most of them have been mentioned in this thread already. There is whitelisting, various automated checks, trusted sources, encryption, warnings, attempts at education, etc.

None of these suggestions are worth a damn until the WordPress team acknowledges that WordPress security is a major problem, one that should be a top priority for them.

Security is a major issue and it is a top priority for us.

The examples from this article also obfuscate the malicious third-party code and execute it. Yes, the WordPress team should do more to prevent this sort of nonsense.

Wordpress grew out of b2, which was written in PHP. At the time LAMP was pretty much all there was. For the time their decisions were reasonable.

Woah there, Captain "Death to PHP". I dislike PHP as much as the next guy, but the end of your comment here is a bit out there. Absolutely none of those projects, even the ones written in Perl, were as easy to set up as WordPress was (and still is).

ASP, Zope... Java? Part of why WordPress exists is so people don't have to concern themselves with high level frameworks/setups.

You can blame all of WordPress's issues on the language it's written in, but that's a bit of a red herring. WordPress is the largest blog engine in terms of overall deployment; MoveableType (and others) have had their own share of security vulnerabilities, but WordPress sees it more due to their massive install base. Most other blog frameworks and engines tend to benefit from "security through obscurity".

While PHP is a flawed language, yes, it's certainly not the core issue here. Anything done in this article could be pulled off in another blog engine with relative ease, especially considering this is people who don't really program and are installing/running arbitrary code.

You write:

"Woah there, Captain 'Death to PHP'."

I can not imagine what would cause you to write this. I use PHP in almost all of my work. All of my major websites are written in PHP. However, I do try to take security seriously. The small regard that the WordPress team has shown for security is unacceptable.

To point out that the WordPress team had language options in no way implies that I disagree with the language they chose, it simply shows that their choice was a conscious choice over which they must take responsibility. I was responding to a comment that implied that the WordPress team had no power to make a choice other than what they made.

I am curious, too, that you would criticize what I wrote, yet you offer no criticism of "At the time LAMP was pretty much all there was." The sentence I was responding to was flatly, factually wrong.

You write:

"Absolutely none of those projects, even the ones written in Perl, were as easy to set up as WordPress was (and still is)."

That is one of the problems that arises naturally from the use of PHP - it is easy to set up. As such, you end up with a lot of non-technical people using it. And that is one of the biggest reasons why special attention should be paid to security -- the fact that WordPress is the kind of software that appeals to a crowd that is largely non-technical.

It is curious that someone would downvote this. Up above jacques_chester wrote:

"At the time LAMP was pretty much all there was. For the time their decisions were reasonable."

At no point did I suggest that their choice was unreasonable. However, I have suggested that they made a choice, that is, a conscious decision, and one where they had several options. Like any human being who makes an uncoerced decision, they have a responsibility for the decision they have made. In creating the WordPress software, the WordPress team must take responsibility for for any flaw in WordPress, regardless of what layer that flaw arises from. Again, I would quote the very good advice that Sam Ruby gave to Matt Mullenweg:

"Yes, you can argue that they brought this upon themselves; but it is worth noting that at this point you are along for the ride. When I’m in similar circumstances, I tend to consider the karma implications of cursing the driver."

The statement that ""At the time LAMP was pretty much all there was" is simply wrong -- flatly and factually incorrect. There were options. But the WordPress team built WordPress using PHP. I see nothing wrong with that decision, but having made it, the WordPress team must accept all the consequences of that decision.

The underlying issue is the poor security in WordPress. The team in charge of WordPress has not shown a great concern for security. We must criticize them for giving security such a low priority. They need to change their attitude.

> The statement that ""At the time LAMP was pretty much all there was" is simply wrong -- flatly and factually incorrect.

I could have qualified it better, certainly. "At the time LAMP was the dominant platform and almost every shared host offered LAMP and only LAMP, a condition which has only in the past 3 years begun to change".

> The underlying issue is the poor security in WordPress. The team in charge of WordPress has not shown a great concern for security. We must criticize them for giving security such a low priority. They need to change their attitude.

And I do. Some of the bugs that get closed are astonishing. Wordpress is developed without automatic tests, security fixes are never backported (you always have to upgrade -- getting new features that might have new bugs -- to get the fix), the focus of effort is almost exclusively on new features and not on closing issues in the tracker (though this seems to be improving).

I think the availability of PHP in shared hosting plans was the main factor. Perl was almost as ubiquitous, although a lot of Windows based shared hosting plans didn't support it. Any host that had MySQL had PHP.

You are being downvoted because you are blaming PHP for problems created by Wordpress. This has absolutely nothing to do with PHP and everything to do with running untrusted code, which many other people have pointed out.

> No, you misread me.

If one person "misreads" you, it's their problem. If everyone "misreads" you, it's your problem.