Security: ClipperCMS Public Disclosures By Curesec Nov 2015

As I am sure you know, we have been on top of security issues since Clipper started, and will be for some time despite it being effectively finished now.

Possibly the most serious issue was the one where absolutely anyone could log in as a manager. Reported to Clipper and MODx, with dialogue between Clipper and MODx, and rapidly fixed in both systems. I have sent security reports into MODx both during the lifetime of Clipper and before, and have appreciated it when MODx has done likewise to Clipper.

Implementing fixes (and perhaps more significant, investigating issues) has often took significant time, often at times when I have been busy anyway. The midnight and post-midnight oil has been well and truly burned.

...but when you and other ClipperCMS representatives post that "These sort of 'security disclosures' are quite irritating", calling them nothing but FUD...

Perhaps I have got frustrated with invalid reports occupying time, but I am not the only one who has suffered this. For example "FUD is all I can see from this user's report WRT Revo..." was once said to me by one of your colleagues in the MODx team. This happens, because some reports are genuine, but many are not - and it occupies time, something which is always in short supply.

-- Tim.


[ed. note: TimGS last edited this post 7 years, 4 months ago.]

Quote from: markh at Nov 29, 2016, 01:24 PM

That's when people take it upon themselves to share information, because the official channels haven't

That would be fine, if it was the whole story.

This issue here was posted firstly on the MODx forums, secondly on the Clipper forums, with no private message sent at all to the Clipper developers. At least give people the chance to address security issues, release any fixes if needed, or respond with reasons before going public. That is the courtesy that - as you well know - I have given MODx with security issues.

As an example which you are aware of, instead of publicly posting https://www.curesec.com/blog/article/blog/ModX-Revolution-235-pl-Reflected-Cross-Site-Scripting-Vulnerability-43.html here, I PM'd MODx.

(I'm told this issue is long fixed, otherwise I would not post it.)

Then if you really feel we have ignored security, then as I said in my first post in this thread "At the very least tell those of us involved of threads such as these so we get an effective right to reply." All concerned have the right to opinions - that includes the OP, and it also includes myself - but is it not unreasonable to ask for fair treatment?

-- Tim.

Just FYI: I don't work for the company MODX, I'm just involved in the project, so whoever said that is not my colleagues.

I've not followed Evolution or ClipperCMS much unfortunately, so I am not aware of what has or hasn't happened there. All I've said is based on my impression from reading some discussions over the past few days, including the chat here. It's good to hear you've collaborated with the folks maintaining Evo on security despite the fork.

This issue here was posted firstly on the MODx forums, secondly on the Clipper forums, with no private message sent at all to the Clipper developers. At least give people the chance to address security issues, release any fixes if needed, or respond with reasons before going public. That is the courtesy that - as you well know - I have given MODx with security issues.

According to the full disclosure, details of the found vulnerabilities were sent six weeks earlier. It doesn't say to whom it was sent, but by the time the disclosures are live it's already been a month and a half since someone has been notified privately. If that didn't arrive at the right place, perhaps adding a security email or contact form to the site can help prevent such things should it happen again? mrhaw and others who may have shared the full disclosures are not the people that published the information in the first place.

Maintaining a project is stressful, especially when things don't go as they should or how you'd like them to go. Good luck.

In this case there were no CVE assigned (https://cve.mitre.org/about/) but the vulnerabilities were broadcast out in all the
channels and you have Curesec posting it on their website.

So I went to ClipperCMS to see if you were aware, but there was nothing to be found. I felt I had
to bring this to your attention and the community. PEOPLE ARE TALKING ABOUT YOU! I did not see any point to whisper about it - as the rest of the (hacker) world would see it in their inbox like me. It's public disclosure.


I can understand you being mad, annoyed or irritated with Curesec, but instead you attacked me as a messenger. This swayed me to believe Curesec did the right thing and was just ignored.

Quote from: markh at Nov 29, 2016, 04:48 PM

Just FYI: I don't work for the company MODX, I'm just involved in the project, so whoever said that is not my colleagues.

Sorry, I meant 'colleagues' in a very loose sense. I've not followed the MODx company enough to know anymore who exactly is in it.

Regardless of whether a report has been published elsewhere, I'd always ask for security issues to be communicated privately. That's what I have done in the past as regards MODx (including as per my example above) regardless of whether an issue was already published on the web (as the example above was). The less public notices the better. Even if you think or know that a project has been told, it may best asking them for their take on the issue before posting publicly.

Maintaining a project is stressful...

Quite. Initially I was under the woefully misguided impression that sharing your code was a win-win situation. You give away something that it costs you nothing to give away. In return people report issues and as such help maintain your code. Win-win. Doesn't quite work out like that in reality though.

@mrhaw - I didn't mean to attack you as a messenger, it was just the mode of communication that was an issue. You were certainly not ignored, and this set of issues has now been checked at least twice. I've been looking back through them - one did turn up to be genuine and with eform, now fixed, but the majority did not seem valid in context. The referrer checking 'exploit' was particularly frustrating (and I am directing this entirely at Curesec) as it and the comments demonstrated a thorough lack of understanding or knowledge of Evo/Clipper (e.g. note their comments on bookmarking). I will send you a PM separately with more info.

-- Tim.

In a perfect world Curesec would have contacted ClipperCMS (through a form "Report an issue") and ClipperCMS would have worked with Curesec (maybe even thanked them). The problems would have been dealt with or a timeline would have been set.

Now if Curesec and ClipperCMS did only disagree on one point, they might have chosen to release that. ClipperCMS at the same time would have created a post on the forums with their take why they wouldn't address the issue but leave it for the members to be aware and decide.

This would build trust to the maintainers. The ClipperCMS users would most likely chime in and help. Open Source for the win.


[ed. note: mrhaw last edited this post 7 years, 4 months ago.]

Excellent article from InfoWorld:

10 key security terms devops ninjas need to know
http://www.infoworld.com/article/3144362/devops/10-key-security-terms-devops-ninjas-need-to-know.html

Whenever you’re using open source components, it is recommended that you scan the code for known vulnerabilities (CVEs), then remediate by updating the affected components to newer versions that are patched. In some cases, it’s possible to neutralize the risk posed by a vulnerability by changing configuration settings.