Liferay Community Security Team

I'm particularly happy to announce that today we are launching a new initiative in the community around Liferay security.  From the new Community Security Team (CST) pages: "The Liferay Community Security Team is an all-volunteer group of community members who manage security issues related to Liferay CE. When security-related issues arise in the open source Liferay project, the CST works to minimize the impact and provide notification and relief to the community. In addition, the CST provides ongoing education to developers and users to keep their Liferay sites secure."

This team provides a much needed and long overdue element in the Liferay open source community, helping to quickly fix security issues and provide patches for existing community users.  As Liferay (and many other open source projects) continues to grow in usage and popularity, so too does the importance and potential impact of security issues, and it's vital that we respond quickly with a well understood and predictable response. In addition to reacting (through advisories, patches, etc), this team is also chartered with being proactive in the community, educating developers, administrators, and end users about security best practices and specific techniques that can be used with Liferay.

The CST pages contain a wealth of information including:

• How you can get involved in the team
• How the team operates
• How to subscribe to receive new security advisories
• How to respond to such advisories
• How to report new issues
• How to install patches
• and much more

As an important part of and corporate sponsor of open source, Liferay is also issuing a corporate security statement, outlining its commitment to security, and policies around reporting to the wider community.

Getting Involved

The initial CST comprises of individuals from the wider Liferay community, as well as employees of Liferay, Inc. All community members are welcome to participate! Because membership gives access to information about potentially sensitive security issues, membership is somewhat limited to those in the Liferay community with a proven track record in the areas related to security or with special skills needed by the team. The best way to get involved is to review security fixes with a security mindset, get down and dirty and find and/or fix a few issues, and interact with the team in its course of duties.

The team is currently busy catching up with a number of security issues that were reported in the Liferay Portal 6.1 CE GA1 release.  Several fixes are currently available through the CST, and a couple more are expected in the next week (be sure to subscribe to the Security Advisory Forum or the feed (click on the RSS/Atom icon on the Known Vulnerabilities page)

What's Next?

As with any new venture, there are still a few unfinished items and there are bound to be hiccups or things we can improve on, so please be patient and constructive with any feedback you wish to give.

The team is still in the process of ironing out its processes, and some work remains for GA1 (as stated above).  We are also expecting a GA2 release of Liferay Portal 6.1 soon, and at that point the team will shift to managing that release's security.  Once the processes have been battle-tested, the team will begin to execute on other areas of its charter (e.g. education and outreach).  The team will also begin to integrate its output within other areas of the community (e.g. pointers to latest patches on the main CE download page, or perhaps notifications during initial install that there are new fixes available).  The team will also provide translations for the CST page content and advisories in the following weeks.

There are a lot of community members that care about security, I am hopeful that together we can ensure continued confidence in the security of Liferay!

[jelmer kuperus]

Making a distinction between critical (sev-1) and non critical (sev-2) issues and choosing only to address only the critical issues is misguided.

Attackers often stack less critical vulnerabilities in order to get an effect that is greater than the sum of it's parts

Say a hacker want's to break into bignasdaqcompany.com

This person might use this vulnerability to find out the email address of one of the users : http://archive.cert.uni-stuttgart.de/bugtraq/2012/05/msg00080.html

He or she could then send an email to this person that somehow triggers the victim to click a link. The site the user would visit would be under the attackers control and would could use http://seclists.org/bugtraq/2012/May/79 to get the cookie of that user
If that user. If he or she chose to save their password. This would guarantee the attacker access.

If the user that took the bait was an administrator, well then this evil hacker would be in. If not the attacker could take advantage of http://archive.cert.uni-stuttgart.de/bugtraq/2012/05/msg00067.html to get elevated privileges.

Maybe he adds himself to the board organisation which might give him access to all sorts of sensitive data.

It can be argued that none of the 3 vulnerabilities i mentioned are *that* dangerous in their own right. But together they make for a pretty compelling scenario, don't you agree ?

[jelmer kuperus]

Also CST-SA: LPS-26935 is woefully misrepresenting the issue. The problem is not that json webservices are enabled by default. It can be argued that they always have been, and still are. via the old /c/portal/json_service interface

The problem was insufficient permission checking in the add user mechanism.

[James Falkner]

Hey Jelmer, these are very good points - I do believe there is value in distinguishing between severity levels (I'm not sure if you're saying that is misguided, or that it is misguided that the CST is only choosing to do the most severe). On the latter - it's not that the CST refuses to do sev-2's, it's just a matter of resources and having to choose what to do first, for the most bang for the buck, so I'll go back and clean up the places where it sounds like we definitely will never do sev-2's. I think we should do them if possible. Agree with your chaining example as well. Cheers!

[jelmer kuperus]

Just an observation but how do you think people will perceive the security of your project if you claim that with a team of 5 people you still don't have enough resources to fix all security vulnerabilities reported

[J. N.]

A new security team? does that mean in the nexts few days we will get a general security plugin that enables a general access-control to provide a kind of "maintenance mode"? or does it already exists and I just could not find it?

[James Falkner]

J.N. No, the security team won't be producing any plugins, though it sounds like an interesting idea.