This year, at WordCamp Miami, I shared an Airbnb with a few other WordPress developers. The door to the place we were staying had a keypad door lock. I guess I’m too dependent on my password manager because I promptly forgot the code. As a result, at the afterparty, when I was about ready to leave I found one of the people I was staying with—Chris Christoff a developer for Awesome Motive and Easy Digital Downloads, and a member of the WordPress core security team—to ask him for the code.
As it turned out, I interrupted a discussion he was having with other developers about security issues. For that reason, I wasn’t surprised when, instead of just telling me the code, Chris started listing off strategies I could use to brute force the passcode on the door.
Mark Jaquith, one of the lead developers of WordPress, interrupted him to point out that entering random combinations of numbers until one worked was inefficient. Instead, he suggested that I analyze the wear patterns on the combination pad, which should tell me which numbers were most likely to be contained in the code.
They weren’t thinking about how a keypad system is supposed to work. They were thinking about how it could be misused and abused.
At the time, I was really tired and just wanted to get the code so I could return to my Airbnb and to go to bed. In retrospect, I’m happy to have been briefly part of this conversation. It made me happy to realize that there are people who think this way about the security of WordPress—the tool I use to make my living. But I’m also happy to not have to be a part of the actual conversation they were having. I trust that whatever issue they were discussing, and I have no idea what it was, was a real issue, and it will be taken care of.
It’s About How It’s Not Supposed To Work
Most WordPress users think of WordPress as something you use by typing in boxes and clicking on buttons. Conversely, developers tend to think of it in terms of PHP and JavaScript, all of which amounts to a series of requests from a browser to a server. (And the browser is actually optional in that equation.) Those requests can be generated from the terminal, or, in the case of most hacks, from some sort of sophisticated script designed to exploit edge cases.
The difference in perspective on how WordPress works makes it difficult for ordinary users to understand recent security exploits. This is because users view WordPress as a thing they control with their browsers, while black or white hat hackers work from the terminal or write automated exploit scripts written in python or other coding languages.
The highly-technical details about two recent WordPress security vulnerabilities can be read in this post by vulnerability researcher, Netanel Rubin. This vulnerability exploited a very specific flaw in the “Press This” feature. It requires a complex sequence of events that no ordinary user would ever do, but allows any user to create a post. While this may not sound critical, consider this: it could potentially be used to inject malicious JavaScript into a site, which could then be used to redirect the site’s visitors to a spam site, like a shady online pharmacy or worse.
But It Has To work
The “Press This” flaw is the less talked about fix addressed in WordPress 4.2.3. The more publicized issue was the changes to the shortcode API. This change caused issues when shortcodes were used as html attributes—for example, to set the “src” in an image tag or as the url in a link tag. This was never something the shortcode API was supposed to do, but it worked, so lots of people did it.
I recently tried to interview Christoff about the shortcode-related issue. He told me that there was a lot more to the story, but right now he couldn’t tell me more than what was in the release post. He did tell me this, however:
Honestly the biggest problem with working on security stuff is that people want to know all the answers right away, which I understand, but for the whole point of security in the first place we have limits on what we can say and when.
This answer is frustrating. There’s a limited amount of explanation for the changes and no pre-warning they were coming.
I could write my own content management system. I’ve actually been teaching myself how to use Symfony components to improve my PHP development skills and broaden my knowledge. That said, while I prefer to use Symfony’s front-end router over WordPress’s in certain use cases, I wouldn’t actually use my own content management system for anything other than a test server.
Knowing that there’s a team of people working to find, and fix, the weird edge cases that can be used to exploit WordPress helps me sleep at night. That’s why I use WordPress. I simply don’t want that kind of responsibility.
When we choose WordPress as our content management system we are able to outsource a huge part of our security concerns, for free.
Do You Trust Them?
Of course, it’s frustrating when security updates cause things to break on your site, but it’s better than the alternative. The lack of communication around security fixes is in stark contrast to the openness found in the rest of the WordPress development process, but that’s because it has to be.
If you don’t trust the people making these decisions in secret, then you shouldn’t use WordPress. Issues relating to security must be addressed with some level of secrecy; and, with that in mind, we should trust the WordPress security team to do what’s necessary to keep WordPress safe and secure.
If you don’t like the changes to the shortcode API, you can undo them on your sites. I strongly discourage you from doing so, but you can.
It’s easy to be mad at the WordPress security team when you don’t personally know them and are adversely affected by their actions. WordPress 4.2.3 broke some things in a plugin I was working on, not because of the shortcode changes, but for reasons relating to the fix for the “Press This” vulnerability. It was frustrating, but I trust that it was the right thing to do to keep us all safe.
Trust In Secrecy Is Difficult But Necessary Sometimes
WordPress prides itself on openness. Most decisions are made openly either on slack, in the core track, or in community summits. Security issues cannot be handled that way. They just can’t.
It’s frustrating when security fixes are made and have real consequences for end users. That said, there’s no reason to think that these decisions are not being made wisely and that the WordPress security team has anything but the best intentions. We’ve never seen anything to suggest otherwise. For that reason, we not only owe them our trust and the benefit of the doubt, but our thanks for keeping our sites safe.
2 Comments