There’s been a nagging thought in the back of my head ever since I started writing WordPress plugins; the apparent lack of oversight in the WordPress plugin distribution system. I’m not trying to create hype around anything, I really do like WordPress, but I’m worried about the implications of zero oversight.

It would be trivially simple to add an algorithm to a plugin to do all sorts of nefarious things. Off the top of my head I can imagine the following:

1. Send over a blogs comment data (email addresses) to an external server.
2. Add an admin account or change existing password
3. Hell, even deleting the entire database and files

Not a happy thought is it?

Attempting such a thing from a new plugin, with zero initial interest, would be nearly impossible because of the noise from all the other plugins. I say nearly impossible because there was recently a case of a plugin, called Pushit, which sent an email containing passwords to a gmail account upon execution. I first heard about this from a post on Mental Fruition asking the question “Are your WordPress plugins safe?”.

In doing some research on connecting WordPress to SMS gateways for some mobile action, I found what is either a careless remnant of testing or a malicious attempt to steal data from people using a WordPress plugin. Actually, make that carelessly malicious.

Interested in how the Pushit plugin for WordPress was working behind the scenes, I stumbled upon quite a shocker:
...

Yet towards the end of this send function, there’s a call to PHP’s mail function. It sends the following to smart.maxx@gmail.com:

• receiving number
• message sent
• username of SMS service account
• password of SMS service account
• the short number used
• the sender name/number to be displayed on the receiving mobile
• whether the SMS was sent OK

Apparently the authors of this plugin deem that this information is something that someone with the e-mail address smart.maxx@gmail.com should have about every SMS you, or your visitors, attempt to send using their plugin. Are you cool with that?

No, I’m not cool with that and I don’t know anyone who would be cool with that.

Thankfully, the Pushit plugin was only downloaded around 200 times before the issue was discovered. It should be noted that the developer of the plugin swears that it was an honest mistake; the mail() call was leftover code from testing apparently. This doesn’t invalidate the fear though.

No, the fear is from an existing, popular, plugin being compromised and distributed. This is the nightmare scenario.

Take wp-click-track (my most popular plugin) for example. To date, it’s been downloaded a couple thousand times and it’s been written up on a few sites. Were I evil, and my girlfriend says the juries still out on that 😊, I could easily compromise quite a few sites with a simple update. Quite the scary thought isn’t it?

I know it would be nearly impossible to protect WordPress from malicious code because plugins are written in php and, because of that, have access to all the resources WordPress does.  PHP can’t be sandboxed so manual screening would be pretty much required.

The fact that there isn’t any manual screening to date is surprising though. WordPress is owned by Automattic, which has received at least 29.9 million dollars in funding so they have money. Just look at it: $29,900,000. That’s a lot of money so it’s pretty tough to understand the argument, if it was used, that there just isn’t money available for a person to provide manual oversight.

That is inexcusable.

I’m not saying it would be easy by any means, but if a company has 29, fucking, million dollars based on the back of a shoddy system there’s no reason why they couldn’t spend some money adding oversight to the plugin system.

As mentioned above, since WordPress plugins are written in raw php they have full access to all the functionality WordPress does so solving this issue programmatically would be nearly impossible. No, without using some sort of meta language, similar to Smarty, manual oversight is probably the only solution.

At the very least take 2-4 programmers, or, hell, one really talented programmer, and have them write a couple scripts to parse the plugin svn repository looking for suspicious function calls (rm(), mail(), exec(), etc) and algorithms (DROP table) and have the programmer intervene manually if anything suspicious is detected.

Heal thyself WordPress. Now.