Tales of SugarCRM Security Horrors (opens in new tab)

I won't consider SuiteCRM to be part of this. Understand that even though SuiteCRM was a fork of SugarCRM CE, the community has made so many changes that I will consider it at this point a completely different product. All the vulnerabilities listed above do not apply to SuiteCRM in its current release and if you look at the blog of SuiteCRM, it is heavily advertised that SugarCRM CE is full of security issues and everyone should migrate out of it[1]. Here is the quote: “SugarCRM Community Edition users need to migrate to an alternative platform as soon as possible. The number of current vulnerabilities in Community Edition is worrying. There will be no more support for Community Edition after April 2017 and the vulnerabilities will increase as the software ages. Simply put, if you're running SugarCRM Community Edition, you're becoming a soft target.”

https://suitecrm.com/index.php?option=com_easyblog&view=entr...

Maybe you should have a look at OroCRM and OroPlatform (https://www.orocrm.com, https://www.orocrm.com/oro-platform). It is built on Symfony and seems rather new, maybe not feature complete.

Odoo (formely OpenERM) is rather omnipresent in this field.

For non-profits/associations, check out CiviCRM.org.

This one:

https://support.sugarcrm.com/Documentation/Sugar_Versions/7....

SugarCRM is an example of projects that give PHP a bad rep.

Maybe programming languages should have a minimum engineering and architectural design competence test such that required knowledge is assured before releasing craptacular poo upon the world.

(If you're write a SugarCRM sploit, obviously patch the Remove XSS to skip yourself.)

I remember working with another CRM product that had a setting in its configuration file called "secure" that was set to false by default!

Basically this controlled whether authentication was always applied or not - by default it was kind of optional.

I'm a numpty. Can you explain why this is bad?

He mentions that they think it might have a negative effect on performance. But more probably they just don't want to refactor their spaghetti code to properly handle serialized data, so instead they go for quick fixes.

Sharp knives are the least dangerous if you're cutting something.

A sharp knife will just cut the thing.

A dull/less sharp knife will not cut, causing you to add more pressure, causing the knife to slip, which is when you're more likely to cause yourself harm.

There are cases in which one might use it, but no cases in which one should.

json_encode didn't exist when sugarcrm was initially developed. whether they should have changed it later or not is a different question, but there was nothing else to go with at the start.

I've seen other projects like Doctrine2 ORM serialize arrays using the built-in serialize function too. I guess/hope they sanitize input beforehand.

Looks very good in Reader mode on Firefox for Android but the bare layout is indeed not mobile friendly.

It was fine for me on an iPhone SE, after switching to landscape orientation.

you'll hit hi res native and no mobile version sites from time to time as others have said go landscape and pinch out to zoom to text block.

Yes. For example, SugarCRM is adding prepared statement support which mitigates any potential SQL injection problems. I mention this since it was posted just this last week. These changes are very large and far reaching so it does take time.

https://developer.sugarcrm.com/2017/04/17/use-of-prepared-st...

I said "like this 10 years old vulnerability", which means there could be other 0-day vulnerabilities affecting even the latest PHP versions and that could be exploited without relying on objects declarations within the serialized string.

Using the unserialize() PHP function itself is not security issue, unless you use it with user-supplied input, and that's the reason why this is a SugarCRM problem and not a PHP problem.

This isn't a great argument against chosing open core solutions, it's a great argument against chosing SugarCRM.

Many open core solutions (I'm thinking of gitlab, but there are probably many other) fixes bugs in both versions.

The performance part doesn't make sense to me either. What are they serializing in a CRM that is so time-critical? I found a benchmark [0] that shows differences of like .2 milliseconds for a 904 byte array.

[0] http://techblog.procurios.nl/k/n618/news/view/34972/14863/ca...

Their latest update (4/25/17):

Based on impact and reach, none of the vulnerabilities in in the second section scored higher than 'medium'... 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.

So, I just replied to their blog post with this comment (awaiting moderation, so will probably never be published):

Hi Rich, I'd like to know more about your latest update, the one with regards to the second section of my post: you're saying you rated all of the vulnerabilities I reported with a "medium" CVSS score (which version btw? v3.0?). However, I reported two SQL injection vulnerabilities and according to your security advisories (https://www.sugarcrm.com/security/sugarcrm-sa-2016-003 and https://www.sugarcrm.com/security/sugarcrm-sa-2017-001), in the past you rated SQL injection vulnerabilities in SugarCRM with 'High' or 'Important' risk level... May I know why now they're considered of 'Medium' risk level? They same applies to the remaining vulnerabilities, which might allow a malicious user to execute arbitrary PHP code, and so far in your security advisories this kind of issues has been rated with 'Critical' risk level (like this: https://www.sugarcrm.com/security/sugarcrm-sa-2016-001)... The numbers don't add up!