Welcome back to the Patchstack Weekly security update! It is the beginning of February and this update is for the fifth week of 2022.
This week I will share some of the core principles of open-source software development and how security researchers participate in them, as well explaining why open source projects should always have a vulnerability disclosure policy and what makes a good vulnerability disclosure policy.
This week in WordPress component patches news, there are three critical vulnerabilities I will highlight in three plugins: So let’s get into it.
Vulnerability News
The Essential Addons for Elementor plugin patched a critical vulnerability this week. This patch prevents a Local File Inclusion (LFI) attack from being successful on sites running an older version.
While there are some specific conditions needing to be present to perform the attack, it may be possible that this attack requires no authentication if they are met. So, It is recommended site owners update to the most recent release as soon as possible.
Patchstack’s CTO Dave Jong wrote an excellent write-up about the Essential Addons for Elementor LFI vulnerability on the Patchstack blog.
The Page Views Count plugin available on WordPress.org patched in unauthenticated SQL injection vulnerability this week.
The developer added a step to sanitize all user-controlled values before they’re added to an SQL query. Users should update this plugin if they have it installed as soon as possible.
Finally, the Masterstudy LMS or learning management system patched a vulnerability that could have led to anyone creating admin user accounts.
This is a severe risk and site administrators running Masterstudy LMS should patch ASAP and check their WordPress admin dashboard’s user page for any unknown admin users which may have been added.
Weekly knowledge
Open source has revolutionized the online world, but open source is not just free software it is an ideology that software should be open, affordable, transparent, and perpetual.
These are a few of the individual core tenants all open source projects should follow, because together they create an emergent property that open source software is projects of collaboration, worked on by anyone willing to put in their time, and improved upon in the process.
Open source means so much more than just free., and is not meant to be kept hidden away from others in a tower of ivory.
In last week’s Patchstack Weekly Update, I commented on the many people who play a role in open source security. This week, I will dive a little more into the relationship between two of those roles: the open-source security researcher and the open-source developer.
The developers who embrace open source get a great benefit from the researchers who also embrace open source, as the projects get their most critical bugs (security bugs) reported and addressed freely.
What is a vulnerability disclosure policy?
Open source projects can benefit greatly when they make sure they have a formal guideline for reporting vulnerabilities. Which, most large projects have. These are called “Vulnerability Disclosure Policies”, and take no more effort than writing them out. Then keep them up to date, either published on the project’s website or including them in a file distributed with the source code.
Vulnerability disclosure policies have gained a lot of popularity recently, thanks to bug bounty programs. But, not all vulnerability disclosure policies have to be related to bug bounty programs, and you do not need to pay for bugs to have a policy!
The policy would be exactly where you would clarify this because they are for setting expectations and providing guidance to people reporting security bugs.
Some expectations you can set forth in these policies could be:
- Who to report security bugs to?
- This could be an email address, or contact form, or something else hopefully easily accessible. This will help ensure that security issues are disclosed privately and to the right person.
- What timeline is reasonable for your project to address to the report?
- Every project is different, some can have patches ready in days others months, it is best to be honest here.
- What is in scope or out of scope for the reports?
- This is where you can clarify boundaries, such as only your project’s source code should be included as “in scope”.
- If you are participating in any bug bounty programs?
- You should link to the program and detail what bugs you are interested in knowing about and if there will be any bounties for reporting them. Again, paying a bounty is optional for smaller projects, but are recommended for larger projects that have revenue sources.
Communicating expectations and boundaries are important in life, work, and most interpersonal relationships. The above rules will help you get started with communicating to security researchers how they can best contribute to your open source project with reports.
Thanks and appreciation
This week’s thanks go out to everyone who contributes to open source projects. This includes foremost the developers who contribute code to open source projects, but also the many people who play a supportive role like: documentation, project leadership, community builders, and of course security researchers who practice responsible disclosure.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly security update!
