Important Security Update – UPDATED
Earlier today, we received information about a lengthy post from a member of our community regarding security issues in SugarCRM’s products and operations. Let me start by saying that SugarCRM takes product and IT security very seriously and has enjoyed a long and productive history of working with the security community. These engagements have helped improve our products and operational processes immensely. Our security protocols and policies include a prompt response to any report of security vulnerabilities or incidents by researching, analyzing, scoring, correcting and providing public notification of the issue(s), and corresponding remediation and product improvements.
Regarding today’s post, the content and issues cited are currently under review by our security, product and operations teams. As we analyze the issues, I’ll continue to post updates on this blog.
4 PM PT Update
Quick update: Our technical and operations folks are doing a line-by-line analysis of the blog post to determine the accuracy and status of the issues cited. We’ll have a more detailed update as quickly as we can work through all of them, but I’d like to shed some light on the history and structure of our SugarCRM technology and solutions.
As noted in the original post, the security issues found were based on an analysis of Sugar CE (Community Edition) open source. The Sugar CE code base comes from our previous generation of CRM product (Sugar 6.x). Four years ago, Sugar released the next and current generation of our CRM solutions (Sugar 7.x), simultaneously ending the evolution of our open source program. Thus, the current version of Sugar (version 7.9 will be available shortly) is neither the same architecture or code represented in our old CE edition. That said, there is some code that is shared between the two, so the comments raised must be reviewed in the context of the current generation of solutions as well. Regardless of version, technology or time frame, we err on the side of safety and analyze all reports, checking against all supported versions of our CRM product.
6 PM PT Update
Analysis: First results are in
Our research is ongoing, but I want to keep folks updated here.
The vulnerabilities cited in part one of the researcher’s post are described as PHP Object injection vulnerabilities. We have made a series of changes over a period of time to fully address these issues, and we were able to mitigate them through a combination of an update provided in SugarCRM 6.5.24, released in July 2016, and the PHP 5.6.25 upstream release, which occurred in September 2016. Notwithstanding, we recognize that the usage of unserialize has an elevated risk and we already have plans to move away from it in a future release.
12 PM PT Update (4/25/17)
The vulnerabilities disclosed in the second section of the researcher’s post were addressed as part of the Sugar 7.7.2.0 release, which went live October 2016. When potential issues are initially reported, we score them using the CVSS (Common Vulnerability Scoring System). Based on impact and reach, none of the vulnerabilities in in the second section scored higher than ‘medium’. Per our security policy, issues in the medium category are addressed in the next regularly scheduled patch release. SugarCRM’s On-Demand customers have all been upgraded to 7.7.2.0 or successor versions. This release was provided to our on-premise customers as well. It’s important to note that updates based on issues scored as ‘medium’ are no longer provided to our last-generation open source Community Edition (CE), so the bloggers post no longer aligns with our current commercial products and solutions.
I should add that our prior policies reflected our view that security issues ranked ‘medium’ (in CVSS) or lower did not merit inclusion in release notes. We recognize that we can further improve transparency and will be amending this policy going forward.
4 PM Update (4/27/17)
Three separate vulnerabilities were disclosed in part three of the post that bear on our internal support infrastructure. Two of those vulnerabilities were initially identified by the blogger in September 2016, and the third was newly reported in the post.
The first vulnerability, which enabled access to FTP account information, was fixed within 24 hours of the report. Per our policy, we immediately notified the two affected customers of the disclosure. For each customer, we identified what information was accessed, reviewed our process and actions, and asked the customers to make certain adjustments to mitigate future risks. We also reviewed our logs for irregularities and forced the rotation of all FTP credentials to mitigate the risk of illegitimate access. After thorough and detailed reviews, we believe that no active customer (CRM) data was accessed. In order to help mitigate these types of attacks in the future, we also immediately instituted a new customer support policy to ensure that FTP credentials are no longer accessible to customers in the context of support cases and that usernames and passwords are appropriately isolated.
The second vulnerability referred to by the researcher as “stored XSS Vulnerability” was resolved within 10 days of his September report.
The third vulnerability, which potentially could have enabled the blogger to access cases without authentication, was newly disclosed by the researcher in his recent blog post and we promptly fixed the issue within 24 hours (on April 25, 2017).