MyBB Community Forums

So the latest 1.8.21 update fixes some very high risk exploits.  Everyone appreciates the release so we can patch our sites but I found this today:

https://blog.ripstech.com/2019/mybb-stored-xss-to-rce/

Turns out the MyBB team knew about these high-risk vulns about 6 weeks before the update. That's 6 weeks someone out there could have used those exploits to pwn every MyBB install. 

MyBB has a policy of keeping reported vulns private until they release an update.  This is a problem imho.  It assumes many things.

1. That the person reporting the exploit is the one who found it.
2. That the person reporting isn't malicious.
3. That the person reporting won't tell others.
4. That no one else will find the exploit.

This is flawed thinking based on trust and assumptions.  It's the wrong policy and I am asking that MyBB consider an immediate change. 

Things I'd like to see.
1. A public notice of a security vulnerability within 48 hours of confirmed exploit.
2. A patch of that exploit within 7 days.

Some of us rely on our MyBB forums as part of our business.  If the team is aware of an exploit their duty is to release it public, not to hide it for 6 weeks while we risk our livelihoods and reputation.

Please, consider an immediate change to the policy. I hope I get support from the community on this.  MyBB often moves too slow and this is important.

And please don't argue that if you make a vulnerability public before a patch is made you risk the site being exploited. This week at least 3 sites that I know of were taken offline because of the 1.8.21 release. If you're a lazy admin that doesn't pay attention that's on you.

(2019-06-16, 01:01 AM)labrocca Wrote: [ -> ]This is flawed thinking based on trust and assumptions.  It's the wrong policy and I am asking that MyBB consider an immediate change. 

Things I'd like to see.
1. A public notice of a security vulnerability within 48 hours of confirmed exploit.
2. A patch of that exploit within 7 days.

I agree with everything except for #2.

That is 5 days too long!

Most exploits can be fixed within that initial 48 hour period. Why wait 7 days?

That gives the "baddies" way too much time to find ways around any possible patches that will come through.

Fix it within that 48 hour period.

My former admin was one of the best in finding and fixing exploits and many of the patches he made were done in less than 24 hours.

Concur with Labrocca; there needs to be better disclosure of security issues. Not everyone reads Github.

Quote:Not everyone reads Github.

They hide them on Github too. I've reported vulns with patch fixes and done Github pull requests which were then removed and I was scolded for trying to make the vuln and patch public. Their current policy is that reported vulns remain private inside the MyBB circle.

(2019-06-16, 01:40 AM)labrocca Wrote: [ -> ]

Quote:Not everyone reads Github.

They hide them on Github too.  I've reported vulns with patch fixes and done Github pull requests which were then removed and I was scolded for trying to make the vuln and patch public.  Their current policy is that reported vulns remain private inside the MyBB circle.

The commit history is public though, isn’t it? So you’d be able to ascertain a fix if you knew what you were doing.

It’s far from an elegant solution, regardless, is my point, and we shouldn’t have to do it.

(2019-06-16, 03:32 AM)Ben Cousins Wrote: [ -> ]

(2019-06-16, 01:40 AM)labrocca Wrote: [ -> ]

Quote:Not everyone reads Github.

They hide them on Github too.  I've reported vulns with patch fixes and done Github pull requests which were then removed and I was scolded for trying to make the vuln and patch public.  Their current policy is that reported vulns remain private inside the MyBB circle.

The commit history is public though, isn’t it? So you’d be able to ascertain a fix if you knew what you were doing.

It’s far from an elegant solution, regardless, is my point, and we shouldn’t have to do it.

The current policy is that security patches are rolled into a single commit on GitHub only when releasing the final package. All patches are worked upon internally via means of .patch files (which are included in _build.zip packages - see here).

We've talked about changing our process a couple of times. Releasing small patches quicker would be nice, but there are a couple of downsides too as I see them:

• People are complaining about us even announcing security issues at all since they think this makes their boards a target. We've had several people complaining about this after the 1.8.21 release in Discord and via PM. Yes, we can blame this on lazy administrators but that won't stop the noise that we are bombarded with (often via direct PM or being tagged on Discord/IRC/Twitter/whatever).
  
• In the case of a security issue needing a database change or setting change (basically anything that needs an entry in an upgrade file under the install/ directory), the only solution is to release a new version number and require the upgrade script to be ran. This would be fine, but how do we manage this - there might be some PRs that have already been merged since the previous release, so do we rewrite the Git history to move these PRs into (current version + 2) (note that this can be quite challenging as Git doesn't exactly persuade you to go around rewriting history) or do we include them in the security fix package even though they haven't had as much testing as we'd like?
  
• When a security issue is reported to us, we share our proposed patches with the user reporting the problem. We then await a response form the original reporter to double check our work. Under a strict 2-7 day deadline, we'd need to include this response time - something that may not be possible if the reporter is busy.
  

If we look at other well known security programs like Google's Project Zero, they tend to have fixed deadlines between a researcher reporting a problem and taking it public (in Google's case, 90 days from report to publication).

It's also worth linking to our current page explaining how we currently handle security reports: https://docs.mybb.com/1.8/development/se...-workflow/

And our general page for security researchers: https://mybb.com/get-involved/security/

I don't see where the report-to-publication time for Google is 90 days and does that include Chrome? And is that a 90 day maximum? Also taking it public may not be the same as fixing it in an update which Chrome does very frequently.

Quote:People are complaining about us even announcing security issues at all since they think this makes their boards a target.

Every admin has that little blog announcement box in their MyBB ACP. That should be enough to notify admins.

Quote:In the case of a security issue needing a database change or setting change (basically anything that needs an entry in an upgrade file under the install/ directory), the only solution is to release a new version number and require the upgrade script to be ran.

I'm not sure that happens that often. If by chance in the upgrade script let's say there is a DB change. You can code it so that if the change is already in-place that it ignores making the change again. I think MyBB already does that for some things.

Quote:When a security issue is reported to us, we share our proposed patches with the user reporting the problem. We then await a response form the original reporter to double check our work. Under a strict 2-7 day deadline, we'd need to include this response time - something that may not be possible if the reporter is busy.

I think if you're on the team you aren't looking at it from our perspective. I wonder how many of the team who do run their own forums do patching to their installs once they are aware of the exploit and the fix. Or are you saying the team keeps their own forums open to the exploit until the official release? Just asking the team to consider how we feel about known exploits floating around for weeks or even months while we're vulnerable.

Quote:I don't see where the report-to-publication time for Google is 90 days and does that include Chrome? And is that a 90 day maximum? Also taking it public may not be the same as fixing it in an update which Chrome does very frequently.

Google Project Zero isn't about reporting Google issues to Google - it's Google's internal team that research security issues in other products and report them to other companies. I'm not sure what Google's policy is for their own products actually.

Quote:Every admin has that little blog announcement box in their MyBB ACP. That should be enough to notify admins.

True, but do you log in to the ACP every day? We also provide email subscriptions to the MyBB Blog, but people still complain that they're not aware of what's going on. We've had people complain in the past about doing too many releases too soon toe each other too...

Quote:I'm not sure that happens that often. If by chance in the upgrade script let's say there is a DB change. You can code it so that if the change is already in-place that it ignores making the change again. I think MyBB already does that for some things.

It is extremely rare, but a possibility. I can't remember it happening recently.

Quote:I think if you're on the team you aren't looking at it from our perspective. I wonder how many of the team who do run their own forums do patching to their installs once they are aware of the exploit and the fix. Or are you saying the team keeps their own forums open to the exploit until the official release? Just asking the team to consider how we feel about known exploits floating around for weeks or even months while we're vulnerable.

True. I only run a very small forum that isn't currently active, so obviously I don't have the insight that a big board owner has. I can't speak to what other team members do.

The primary objective of Responsible Vulnerability Disclosure within MyBB's Security Research program is to mitigate or reduce risk for all active boards, which means leaving the experience threshold unaffected: if someone can administrate a discussion board, they should be able to apply security patches.

This involves:

• minimizing disclosure until universal solution is available,
  
• maximizing immediate discoverability of solutions to administrators, and
  
• increasing disclosure once the solution is available.
  

In the case of MyBB and other PHP applications, there are additional factors of using interpreted languages (that make it infeasible to release solutions without pointing to vulnerable code) and intermediary deployers (i.e. board administrators have to apply solutions to protect end users). Upsides to announcing existence of acknowledged vulnerabilities (and, potentially, the risk assessment) are less clear for same reasons.
The mentioned web browser is compiled (and ultimately closed-source), can release automatically-installed updates to end users, and has a a dedicated, full-time security team and quality control.
Up to the moment of release all security issues are considered under embargo to reduce risk of exploitation "in the wild", which may result some information being hidden or removed (Security Workflow: Confidentiality Assurance). Disclosing such details to anyone outside of the MyBB Team is considered beyond acceptable risk, and Team members shouldn't apply security fixes to own boards, excluding internal Release Candidate packages, to prevent accidental discovery (which may need further formalization).

MyBB at this time maintains 3 official, separate announcement channels which administrators can (and should) subscribe to. Any out-of band notification, announcement, patch, or leak would unnecessarily endanger end users, administrators, and servers.

Limited/Partial Disclosure starts with the release, when patch details - other than source code (necessary for remediation) - are published in Release Notes and the Release Blog Post (and propagated) and include risk assessment, brief technical description, and attribution (if applicable) - in the future the Low/Medium/High level will be replaced with the standard CVSSv3 scale, and the list may be extended to providing CVE numbers, Security Advisories, and disclosing individual reports.
The scope of technical details that may provide advantage to malicious actors (on top of source code changes) available in the initial period (which would likely be somewhere between 1 to 7 days) is up for discussion.

14 days post-release would mark our recommended waiting period before detailed technical analysis is published. These publications would preferably require additional knowledge or experience to be used for exploitation, since making all details generally available may put active boards that haven't been upgraded yet at risk (end-of-life branches may be good candidates for real world exercises, instead).


The main problem we can notice in 1.8 is that security-related releases are bundled with error-prone maintenance ones, which may introduce delays for various reasons. MyBB 1.9 - by default - should have the hotfix approach baked into its workflow, where we take the preceding version, apply critical fixes, and release it; these changes would be merged back to corresponding master/* and develop/* branches in Git, according to gitflow branch organization that should be less problematic in 1.9 (which involves fewer places with hardcoded versions for resources like templates).

@Devilshakerz, your reply is statements about how the system works but does not address potential changes (improvements imho) nor does it even provide your personal viewpoint on the matter.

@Devilshakerz, Do you believe that 6 weeks after a high-risk exploit is reported to MyBB is a reasonable time to notify the admins? A simple yes or no would suffice.

I'm not overly concerned with low-risk or in some cases the medium-risk exploits. But the high-risk with SQL injection on the front end or RCE, as in this case, are situations which can destroy a forum. Even with off-server backups you could still face a potential nightmare among your base explaining to them why their private data is dumped and leaked all over the web. Rebuilding even a medium sized site can also take up many hours of work.

It's my view that anything that puts the admins into this situation should be high priority for the team. And if it's not then I think everyone should be aware of this and not report vulns to MyBB anymore and just make them public to force action. MyBB needs to at the very least review and discuss openly this policy.