Welcome back to the Patchstack Weekly Security Update! This update is for week 33 of 2022.
In this week’s knowledge share where I will be discussing the practice of handling security bugs.
I will then discuss only one insecure plugin in this week’s vulnerability news. Unfortunately, the plugin did not receive a security patch for a severe security bug, so you may wish to be on the lookout if it is installed on your websites or customer websites.
P.S. you can now listen to Patchstack Weekly on Apple Podcasts and Pocket Casts – so go ahead and subscribe there if you’d rather keep Spotify for music!
The practice of handling security bugs
Mature security is a practice, the practice of handling security bugs. This practice is more than just writing the patch. It starts with how reports are received, how they are handled, triaged, and prioritized, then comes the work of patching and finally communicating to your users.
This practice sounds a lot like a process, but I used the word practice because it helps imply the process is something we are learning from, reflecting on, and improving. Processes are hard set while practices are flexible.
The key to perfection comes through practice. When I see open source projects that accept and quickly patch even low-risk security bugs, I see a project that is prepared to handle even the biggest of issues when or if they come up.
The inverse is true too. When projects dismiss low-risk bugs as won’t-patch issues it leaves me concerned their developers are spending their time discrediting or dismissing reports instead of practicing patching. This could lead them to be ill-prepared, if or when a critical bug is reported against the project.
Here is another fun fact when a project is patching low-risk security bugs, that shows us two things:
- The project patches all security issues, even the low-risk ones.
- The project may have patched all the high-risk bugs, and only low-risk security bugs exist.
The next time you see an open source project with a lot of security patches, especially addressing low-risk issues. You should think “Wow, these developers really do take security seriously”.
Let’s go ahead and hypothesize a process, which we can practice when an open-source project needs to patch a security bug.
The elements of a good bug patching practice
Receiving & handling security reports
Everything starts with receiving a report. This could be through private channels or public. I recommend the private channel though, so you need to make sure you share with researchers how to contact you privately if they wish to communicate security bugs.
If you don’t share with researchers where and how to report security bugs privately, then those bugs might end up being shared publicly! Publicly sharing security bug reports can be dangerous, but I understand the frustration as a security researcher when the project owners provide no way for security researchers to communicate privately.
Patchstack recommends all open source projects have a vulnerability disclosure policy. I have talked about this before on the Patchstack weekly episode about open source vulnerability disclosure policies and we can help open source projects with this process if needed.
Triage (prioritization)
Once you have received the report, you need to review and verify its accuracy both technically and for any claims of severity.
Not all vulnerabilities are the same, during this review process you should be confirming the risk level. There are many factors you could consider such as:
- Is the security bug being actively exploited?
- Can un-authenticated users perform the attack?
- Would a successful attack lead to complete compromise?
- Does the Proof of Concept work as shown, can it be reproduced?
Dependent on the risk level, you may need to prioritize the work. If you answered yes to the first three questions, then you just found out about a security bug being actively exploited, that allowed unauthenticated users to completely compromise the website, and you might want to start working ASAP.
Patching
Now that we have prioritized the work, it is time to do the work and write a patch.
Be careful not to get tunnel vision here. Security bug reports are not the same as security audits. Commonly only one security bug is reported, but similar bugs may exist in the code base, so take a little extra time to look elsewhere in the code base and patch it everywhere.
Once you have written, confirmed, and pushed the patch, now comes the time for communication.
Communication
When it comes to security patches, users need to know. Be sure your changelogs reflect that the release includes a security bug fix.
No matter how low or high risk the patched bug is, having a history of being proactive when it comes to communicating security is how projects show they take security maturely.
Reflection
Finally, we reflect. We remember to review what worked and what did not, revise our steps to remove or improve problem points and prepare to repeat the steps again next time, and with a little effort, it will be better each time we practice proper security bug patching.
Time
Handling security bugs takes time, and I suspect not all open source projects have that time available. One way projects can save a lot of time is to partner with someone experienced in the practice of handling security bug reports. Someone like Patchstack. So, if you know of or own an open source project that could use help with handling security bug reports please reach out to Patchstack, we would be glad to see how we can help.
Vulnerability news
single-sign-on-client – Authentication Bypass
The simple single-sign-on-client plugin, unfortunately, received no patch for a security bug from the plugin’s developer and it appears they may be missing in action. The support forums for the plugin included at least one user asking for an update, and asking for help, and has not received a response in over a month.
I hope the developer returns to help their users, but until then it is recommended users of the single-sign-on-client plugin remove the plugin from their site and find another solution before attackers weaponize this security bug into a working exploit.
Thanks and appreciation
This week’s appreciation goes out to all the developers who have a positive practice of patching security bugs in their code base. All bugs, big and small, security or not, should receive a patch. You know it not only secures your code but improves who you are as a developer and proves you are willing to put in the work to earn the trust of your users.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!
