Matt Mullenweg Responds to Security Rant: Digital Signatures for WordPress Updates Are Important but Not a Priority

Scott Arciszewski, Chief Development Officer for Paragon Initiative Enterprises, who is most widely known for his cryptography engineering work, published a post on Medium criticizing Matt Mullenweg, co-creator of the WordPress open-source software project, for not caring enough about security. Arciszewski has since retracted the post but you can read it via the Wayback Machine.

Arciszewski is working on a project known as libsodium, a core extension to PHP 7.2 which allows for encryption, decryption, signatures, password hashing and more. Its goal is to enable developers to build higher-level cryptographic tools.

WordPress’ automatic update system is handled through api.wordpress.org. Since updates do not have a digital signature, if api.wordpress.org were compromised, attackers could send malicious updates to thousands or millions of sites. This scenario was at the forefront of people’s minds late last year after Wordfence published details of a complex security vulnerability that could have compromised the update servers.

Arciszewski suggests offline code signing and elliptic curve cryptography as solutions, “The key that can produce a valid signature for a file isn’t stored on the server (only the file itself and a valid signature are), so even if the server gets hacked, attackers can’t just add trojan horse malware to the file,” he said.

OpenSSL is an extension of PHP and is commonly used as public-key cryptography but it only supports RSA which Arciszewski deems inadequate. Since WordPress is written in PHP and supports versions 5.2-7+, Arciszewski needed to create a solution that was as compatible. This inspired him to create sodium_compat that adds Ed25519 signature verification to WordPress’ automatic updater.

Arciszewski submitted a number of patches to WordPress but was told by Dion Hulse, WordPress core developer, that the sodium_compat library could not be merged into core until it passed a security audit by a third-party. Audits can cost a lot of money so Arciszewski’s plan was to see if Automattic could take on some of the cost or crowd-source the funds. However, his project was put on hold after Mullenweg informed Hulse to stop working on the feature as it’s not related to the three core focus areas of the Editor, Customizer, and the REST API.

Arciszewski described the decision as irresponsible and that every user has a reason to be alarmed, “The WordPress team has shown that they are not responsible enough to govern their impressive ownership of the Internet (with the exception of some folks powerless to correct the organization’s course),” he said. “This act of negligence will put the rest of the web in harm’s way.”

Update Signing is Important but Not a Priority

Mullenweg responded to the post on Medium.com with one of his own and reiterated the WordPress development team’s commitment to security.

“Everyone involved takes their responsibility very seriously, and the growth of WordPress has meant many thoughtful, hard-working people have gotten involved and think of the security of WP sites holistically, from every angle,” he said.

Mullenweg also clarified what attacks would be stopped by implementing digital signatures to WordPress updates.

“It could stop a man in the middle attack, where someone modifies the update files on the network in between your blog and WordPress.org, or it could stop a situation where the part of .org that serves the update is compromised but the signing part isn’t, and someone decided to send out updates even though they know they’ll be rejected,” he said.

The team is unaware of any WordPress sites that have been attacked this way. While the possibility exists, the extent of the damage would likely be limited. The update servers are monitored around the clock and since many large webhosting companies automatically scan their customer’s sites for malware, the malicious update would likely be discovered quickly.

Mullenweg describes what would happen if an update server was compromised.

“We would turn it off really quickly, notify the world there was an issue, fix the problem, turn it back on, and notify the specific sites or hosts as able,” he said. Although WordPress powers 27.5% of the top 10 million sites tracked by Alexa, it’s highly unlikely that number of sites would be compromised.

He goes on to say that there are easier ways to compromise a WordPress site and listed the biggest issues to WordPress security based on impact.

  1. Sites not updating core.
  2. Sites not updating plugins.
  3. Sites not updating themes.
  4. Weak passwords, without brute-force protection or two-factor authentication.
  5. Hosts (professional or ad-hoc) not scanning and fixing sites.
  6. Hypothetical issues not seen in practice, which distract from the above existing priorities.

Mullenweg confirms that he offered to donate to the audit of sodium_compat a day before Arciszewski published his post. Even if the library passed an audit, the code couldn’t immediately be added to core, “You would also need to do some significant work on the server-side to isolate the signing from the update server, so it’s worthwhile in the first place,” he said.

And if the code were added to core, only the sites that updated to the version that has the cryptographic library and the update checking would be able to take advantage of it. WordPress.org would still need to send updates to older versions that don’t have update checking. These sites would still be vulnerable to receiving a malicious update.

Mullenweg says that digital signatures and update signing will end up in WordPress eventually but it’s not a priority as there are other security issues in front of it, “We are prioritizing those issues above a nice-to-have, defense in-depth effort,” he said.

“A good approach would be to build the server-side first, because doing that properly, say with an HSM, is the difficult and important part; then get the packages signed; then test out verification in a plugin because we don’t want to break auto-updates; and then finally merge into core and set the client to reject non-signed updates. On the client side we need to pick a cryptography library, and get it audited.”

Mullenweg ended his post explaining why he published his response on Medium instead of his personal site. “Seems to be the most popular place for rants like this. I also wanted to try out the famous Medium editor,” he said.

What’s Next For sodium_compat

While the prospects don’t look good for his library being added to WordPress in 2017, Arciszewski says there are plenty of other PHP projects that could benefit from it, “For their sake, I’m still strongly inclined to pursue an independent third-party cryptography audit, and attempt to crowd-fund the cost,” he said.

26 Comments


  1. How is a security issue “important” but not a high priority for development? Erm…what?

    Report


    1. Because, as Matts response states, there are a lot of more important security issues that could be tackled first. Update signing would be a big change to implement yet, right now, it offers only a minor benefit in terms of security.

      Report


      1. and working on one obviously prevents from working on others?

        wordpress.org was since inception of the update mechanism a weak security point. It is actually amassing that as far as we know it wasn’t abused in any major way, but the weakness was known forever. All other software distribution shop verify that whatever is being installed was properly signed, and this was done by the likes of microsoft from before wordpress.org distribution had started, so it is by no means a new idea that the wordpress world suddenly gets to be aware of.

        But you are right that there are more important low hanging fruit that might be worth handling first, like stopping user enumeration, preventing brute force attacks, disable external “posts” via comments, pingbacks, xml-rpc, rest api, and hardening the default htaccess. But wait actually no one works on any of those things, so what exactly is higher priority?

        No one that has been around wordpress for long enough time has any illusion about what is the highest priority of core – market share. Anything else is handled just in the minimal amount of effort that is required for the market share campaign to proceed.

        Core in general do not care about security, or software quality (two things that go together many times), and this is the reality everybody that works and uses wordpress accepts, which is why security related plugins are among the most downloaded ones. If core was secure no one would have needed them.

        Report


  2. Security should always a be a core focus area! This isn’t a minor thing.

    Linux distributions have been doing this for ages, and I can remember when a distro or two got caught sending infected updates.

    Report


    1. The most recent one would have been Linux Mint. And they were properly smacked over the ear for still using md5 instead of at least sha256 crcs.

      cu, w0lf.

      Report


  3. Matt is the main reason why the company I work for is moving away from WordPress.

    Multiple bad decisions and a lot of #wpdrama doesn’t give us the confidence we need on this project.

    We are now adopting Drupal on new projects and in the summer we will build our own CMS based on Laravel.

    Report


  4. The problem with Matt M’s list of higher priorities is that they are all about user stupidity or host company stupidity. Fine. Granted. But a little bit of misdirection if the question is what can .org do to make itself more secure.

    Report


  5. I don’t agree with Mullenweg on this. He clearly doesn’t understand the concept of “defense in depth,” that he alludes to in his response. By focusing only on the low-hanging security fruits, you make the biggest one the most appealing target.

    To add to that, I find it laughable that Mullenweg suggests the risk is mitigated by web hosts that scan your website for malware. This may be true for a percentage of people who can afford managed WP hosting, but even then, what makes him think that someone sophisticated enough to compromise the WP update servers is going to be sloppy and sling out easily detected malware?

    Report


  6. I kind of get where Matt is coming from but the most worrying part of his statement is “…best estimate based on hypotheticals is in the tens of thousands.”

    So the mitigation strategy is: the first 50,000 sites or so to get hit are basically collateral damage and we’ll stop the bleeding there. How is that acceptable? There should be zero sites at risk. I get that tens of thousands is a trivial number when dealing with hundreds of millions but these are real people and businesses, not just numbers.

    How is this suppose to be comforting to anyone?

    Report


  7. Personally I think the issue is potential and hasn’t happened yet. While preventing is great, Matt’s respond seems reasonable.

    Report


  8. With the public key you can use code-signing to verify that your code hasn’t been tampered with. That’s the whole point. It’s not about man-in-the-middle, it’s about ongoing integrity. If someone gets into a server, if you have signed code, you can easily tell if that code has been changed without going back to the server. Because you have the public key.

    So you could download code on Monday and the source server could be hacked on Tuesday. If you check against the source server you’re vulnerable. If you check the signature only, you’re not.

    I think Matt has wilfully dodged that whole point of it, though it’s fair that the original argument didn’t specifically prime people on the whole purpose of code signing either.

    Report


  9. It’s easy to say that something should be done when someone else is the one that has to do the work.

    Report


    1. The author of the original post that Matt responded to did most of the work.

      Report


  10. I disagree with Mullenweg for many reasons, first of all, he only focused on low type of security steps, secondly, he said the main risk to the hosting companies that scan your website to check for any malware issues.

    Report


  11. Users and hosts can be stupid, and nothing .org does can change that.

    That takes care of 5 of the 6 priorities listed by Mullenweg.

    The 6th is “people can always come up with hypotheticals and waste your time.” True. They can also save your nuggets from the fire. Which is it this time?

    Report


  12. The human factor is always a key issue in security. Always has been and always will be. Mullenweg is completely delusional if he thinks that users not updating their sites routinely and not using expensive hosting is a justifiable excuse to deprioritize security within WP core. That’s just downright irresponsible. I would much rather have a secure product than one with a fancy customizer and an API I’ll likely never use. I am getting so tired of constantly worrying about WP security.

    Report


  13. The update servers are monitored around the clock and since many large webhosting companies automatically scan their customer’s sites for malware, the malicious update would likely be discovered quickly.

    As we all know, Yahoo and countless other companies were also “monitoring their servers around the clock”. If you face smart hackers, it may take years to notice the hack and then to fix the damage.

    It is also real possibility that WP staff could be infiltrated, so you would not deal with man in the middle, but with the man inside. As someone said – the fruit is big, so the stakes are high.

    Report


  14. Discrediting the detailed post packed with valid points as “rant” in the title is crappy journalism. Obviously biased towards Mullenweg who owns this site. The fact that he deleted that post does not make it a rant. Yes the #mullware heading sounds like it, the posts text did not! And its correctly called a “post” just right below the heading.

    I have seen a former wp core contributer call out Nacin or WP core for security flaws before and his points where stunning and showed how far core got away from understanding/caring about the basic every day user.

    I think its always very annoying when people with massive power consider security low priority. And calling this “Important but not a priority” is exactly that.

    So you can imagine my shock yesterday when Dion Hulse informed me that Matt Mullenweg, CEO of Automattic and lead WordPress developer, ordered him to not do any work on package signing, because it wasn’t one of Matt’s goals for 2017 (which consists entirely of: Customizer, Editor, and REST API).

    Mullenweg stubbornly stays by this goals as if they are written in stone. Probably because he has some kind of philosophy that this is the way to go. He is not willing to change the goals for security. Thats just the wrong decision. And it may very well be that not updating or even using certain themes/plugins are way riskier but he cant do anything about it so listing all the stuff that is riskier does not make a great point for not doing code signing.

    I get that this would not immediately benefit anyone but as someone who run my own VPS I would for sure make sure to do any steps needed on server side that seem to be needed if I get this correctly.

    What about a 3rd party solution, what if the wp releases would be signed with PGP (I am just guessing that they don’t) and one would just use some script that runs every few hour, check for a new version, if any, download, check, install or delete+alarm.

    I don’t know why he deleted that post, he should just change the title, and funny enough thats also true for this very article ;)

    Note to self: Probably do some PGP signing yourself first, then criticize. Well I don’ effect 27% of the Internet so there is a excuse ^^

    Report


  15. Lets stop this fantasy that WordPress is secure. Even the updates need updates. Recently we were denied the knowledge of a flaw until weeks after it was patched. Try putting a new WordPress install into the wild, without any third party prophylactics, and see how venerable it really is. It’s not a case of when you are going to get hacked ,it how many times. What a about a quality tested mark for plugins or info on what security tests are done on the plugins in the directory. Relying on last update date isn’t enough. This and the Google HTTPS tax have made us abandon WordPress and go back to html. What about a slimmed down core secure version of the install. #wpbloat

    Report


  16. I wrote a blog past a few years back comparing WordPress to Windows XP. It’s a widely used piece of software, important to millions of people. Windows XP gets hacked as soon as you put it online. So does WordPress, especially out of the box.

    But I have to say prioritizing code signing when there are so many other obvious places to improve security doesn’t make sense.

    The low hanging fruit are there and have been mentioned in this thread to harden default WordPress installs. The chances of the current hacks we already know about happening are MUCH higher than the chances of a person in the middle or person inside WordPress infecting core distributions.

    Also how many of you actually sign your emails with PGP on a fairly regular basis? I dare any of you to live with signing PGP and signing attachments with your email client more than a few times a day. Once you see how badly PGP is implemented from a user perspective, you’ll realize that just having a signing library for code is not enough– there’s a lot of work to be done to make the experience seamless.

    I think that’s what Matt cares about (and many others) — making the update experience as seamless as possible while keeping security top notch.

    I also think that it this is a responsability of many more than the core WordPress dev group. Hosting providers, end users and many others also should bear the burden of managing their WordPress installations. I know many developers who don’t even think of the default security stance WordPress takes and just ‘set it and forget it’.

    We probably need a WordPress Pearl Harbor to happen before anyone takes real notice. Until then, harden and secure your sites and choose hosts that take security seriously (ie choose Managed WordPress hosts).

    Report


    1. Who died and made WordPress God? How long before WordPress wakes up and smells the coffee. The security and HTTPS blocks will make people think of alternatives, even social media hosting. Yes the supply chain has other holes, but blaming them is a smoke screen. Time for a subscription fee for a secure PRO version or a cut down core version with less risks.Time to take better care of golden goose.

      Report

Comments are closed.