Welcome back to the Patchstack Weekly Security update! This update is for December 2nd, 2021 and in this update, I will focus on dependency confusion.
This week is a good week, there are no high-risk vulnerabilities to report on in the WordPress ecosystem. But, that does not mean there is nothing to talk about as it pertains to security, there is so much to talk about, like dependency confusion.
Something that affects almost everyone, but WordPress plugin developers have some steps they can take to mitigate the risks caused by dependency confusion.
If you have not heard of dependency confusion before today, then stick around and check out the Weekly knowledge section.
Vulnerability news
There are no high-risk vulnerabilities to report this week. A reason to celebrate, but not a reason to let our guard down. The Patchstack vulnerability database grew by over 100 vulnerabilities in the WordPress ecosystem in the month of November.
If you would like to find out more about the vulnerabilities reported last month, go check out the Patchstack database.
Site owners with the Patchstack plugin installed and users of the Patchstack App can check their dashboards to ensure their sites are not running any vulnerable components.
Dependency confusion
This week there was a post made by the WordPress.org plugins team member Ipstenu, warning people to stop attempting to submit plugins to test a vulnerability called dependency confusion.
This post brought to light the risk of dependency confusion in the WordPress ecosystem, and how the WordPress.org teams have begun mitigating those issues.
So, those people out there attempting to leverage this vulnerability really, are just taking up everyone’s time.
Weekly knowledge
What causes dependency confusion?
Dependency confusion is a risk that is caused when a piece of software’s auto-updating functionality can be tricked into updating packages from the wrong source.
This risk is normally associated with software libraries, like pip, ruby gems, but it is something that is critically important for custom-built plugins written for WordPress but not hosted on the WordPress plugin repository.
This scenario may help you understand the risk better:
Let’s say you are a WordPress developer and you built a custom plugin for a client. This custom plugin was installed manually on the client’s website and it’s named “awesome-custom-plugin”.
You have your own GitHub repo that manages updates on the site, and so far the software is up to version 1.2. To be absolutely clear, this plugin was never uploaded to the WordPress.org plugin repository.
Now, let’s think about what happens if someone, sometime later, uploaded a plugin to the WordPress plugin repository with the same slug name? And they set their release version to 2.0? And then … what happens when that client’s website looks for updates in plugins?
Well, your client’s website will see it is running “awesome-custom-plugin” version 1.2 and an update is available to 2.0. If auto-updates are enabled, then your client’s website may have already started updating the plugin, and we can be almost certain that update is going to break the website (or worse.)
OK, that’s the gist of it, but how does this get addressed?
What is the fix?
Package management or software distribution chains can address dependency confusion attacks by ensuring the updating mechanism in the end-user software is aware of the source of a package, and only applies updates from that same source.
This makes sense, as it is best to assume that software should be getting updates from the same source, and not (if you forgive me for using the term) “willy-nilly”.
The update mechanism just needs to know where the package originated from, in order to apply updates from the same source.
In the world of WordPress, they addressed this with the “Update URI” header which plugin authors can set as described here. As of WordPress 5.8 the plugin update mechanism in WordPress will honor the Update URI field in the following way:
If there is no value, it will look for updates on the WordPress.org plugin repository. Otherwise, it will attempt to look for the update based on a special action using the hostname specified in the plugin’s “Update URI” field.
Developers should set their plugin’s “Update URI” header to the source which is authoritative for updates of the plugin.
If you write a custom plugin that is not hosted on the wp.org repository, then you are strongly encouraged to put something into the “Update URI” field!
You can put your own hostname, and add an action named update_plugins{$your_hostname} to help with managing the update. Or simply set your plugin’s Update URI to “false”, this will effectively tell the WordPress plugin updater to ignore this plugin and move on.
If you host your plugin on the wordpress.org plugin repository, then you have a few options:
1) Do nothing, because if the Update URI field is not set, then the updater will go ahead with attempting an update through the wordpress.org plugin repository.
2) You can set Update URI to w.org/plugin/your-plugin-slug or https://wordpress.org/plugins/your-plugin-slug to make it clear “this plugin is updated via the wordpress.org plugin repository.”
Thanks and appreciation
This week’s thanks go out to the Patchstack Alliance (formerly Red team) for their efforts in November, to all of the plugin authors who released security patches for vulnerabilities found in their software in November, and for all of the bespoke plugin developers who will soon add the “Update URI” field to help secure their plugins.
Special recognition is also sent out to the developers who helped implement the “Update URI” field for plugin updates in WordPress core back in WordPress 5.8, Ipstenu for the honest write up about dependency confusion as well as the rest of the WordPress.org plugin team who are battling errant attempts to uploading conflicting plugin slug names to the WordPress plugin repository. I know the work is tireless, but keep it up!
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly security update!
