Vulnerability reporting in PHP libraries

[Chris Cornutt]

So, Anthony and I had a brief discussion about this (mostly via twitter and IRC) about vulnerability disclosure in PHP libraries. While I appreciate the idea behind the SensioLabs checker tool, there's just not enough contribution there to make it and effective tool.

Essentially what our ecosystem needs is a way to either have 3rd parties or the projects themselves report about vulnerabilities in their code in an easy to consume manner. I wanted to open this topic up to the wider floor of this group and see what ideas were out there and if anyone had started a project that might be along these lines.

I think something like this could be a very good thing for the PHP+Composer world that we're living in, potentially even being worked into Composer itself as a "this library has open vulnerabilities" warning on update.

Thoughts?

--
Senior Editor
PHPDeveloper.org
ccor...@phpdeveloper.org

@enygma

[Timo H]

This is an extremely difficult problem to solve. The best solution, in theory, would probably be to have a "centralized organization" to keep a track of the vulnerabilities. Something  like http://www.openwall.com/lists/oss-security/

But in reality, we have too much libraries from so many different parties, that I doubt it is not possible.

Maybe the best bet is to indeed make the developers make sure they inform about security vulnerabilities in their code. I'm not familiar with the SensioLabs checker tool, but anyway, this topic certainly needs more conversation and hopefully we can proceed with, yet unknown, satisfactory solution at some point.

Timo

[Evert Pot]

This is perhaps relevant as well:

https://groups.google.com/forum/?fromgroups#!searchin/php-fig/vulnerabilities/php-fig/lRBco1JcNzg/91DN4c9xtD8J

[Chris Cornutt]

Definitely relevant...I hate that the discussion ended there though, It seems like there was a lot of good ideas floating around out there. I like the reuse of the CVRF format too (http://www.icasi.org/docs/ICASI_CVRF1.1_White_Paper.pdf). I think to have the highest level of adoption, though, there'd need to be something that generates that information off of vulns/advisories that are entered into a tool. This same tool could pull in information from existing sources and re-feed that back out in the given format.

The spec for v1.1 is pretty descriptive but we'd need to find a way to make it as automated as possible to really see adoption. Here's some of the pain points I'd see:

- it's too hard (to generate the CVRF document)

- not many PHP projects, other than larger ones, bother with tracking vulns

- reporting of vulns in software not your own

just a few off the top of my head...

-chris

--
You received this message because you are subscribed to the Google Groups "PHP Security Technical Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sectg+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Pádraic Brady]

The PHP-FIG discussion stopped basically until a format and tools emerge. I prototyped a CVRF emitter on GitHub for a few hours while studying the format - it's a bit convoluted for our immediate needs but quite doable. It really needs a briefer Json or YAML partner for sub-Drupal size projects though. 

Would be great to discuss such a format here and perhaps basic tooling. If someone builds it, people might use it . I'm sure I can swing some PHP FIG support to formalise a JSON schema or whatever YAML uses. (Still not which format should prevail here - JSON means no extra dependency for Composer integration which is not guaranteed by any stretch)

Paddy

Pádraic Brady

http://blog.astrumfutura.com

[Kevin McArthur]

This is a hard question; as someone on the security side of things I can share some experience.

1) for the most part, development companies don't have anyone checking their developer's work for security problems.  That costs money and provides no tangibles. Hard to measure security, but you'll know it when it breaks.
2) companies with whom security vulnerabilities are found are almost always offended you found fault with their software, and will spend more time and effort on managing the PR about a vulnerability than actually fixing the vulnerability. Lawyers and marcom first, developers second. Notices to users? keep dreaming.
3) Our development community has no professional standards. When leaders in this community are still telling people to use Composer despite long-standing and well known remote-code-installation vulnerabilities, there's no professional body they can be held accountable to. (Unlike engineers, medical professionals, securities traders, etc, etc, etc) There's also no clear time frame between when a vulnerability is published and when it becomes /totally irresponsible/ to continue integrating that library (Zend, I'm looking at you). PCI and PA-DSS are little better than a blaming mechanism much like an unregulated and one-sided insurance-policy, as even those who claim PA-DSS don't actually pass it -- and I've found major vulnerabilities that remained unpatched for far too long in a number of PA-DSS certified ecommerce platforms.
4) There's no decent method for automating software library updates today. At best, we have a brittle system of svn externals, git subrepos and application-specific dependency management libraries that usually introduce more security problems than they solve. They all have to go through rigorous testing procedures because features and security fixes are rarely maintained separately, API changes happen within point revisions, etc. 

So, to the question of whether or not the vendor companies will sort this out voluntarily; I'm pretty sure I have an answer -- they wont.

My solution in our development environment has been to implement code reviews for all third party PHP code, ban the use of object-only code, do red-team testing and deploy two-factor authentication for all administrative interfaces. Its not a perfect solution, but I'm pretty sure there's going to be no magic bullet out there until there's some sort of penalty for publishing or certifying bad software.

What I'd like to see is a reputation client, perhaps using the apt package manager, where once we've completed a code review, we can sign the package much like giving it a +1. Users could then pick their trusted notaries and we could stop doing our own internal reviews and duplicating all this work. -- but then, see problem 3.

--

Kevin McArthur

[Pádraic Brady]

Hi Kevin,

I shouldn't be surprised your solution is similar to the one I use
here. We review all 3rd party code from scratch without exception. On
the accountability side, I've been ignored, mocked, received reports
on my lack of knowledge and understanding, or been given
acknowledgments while Github repos remain dead to any fixes for
months. There's even cases where reports at alpha/beta still remain
open after high profile final releases... As usual, naming names would
be a great for shaming them into compliance but it's often
irresponsible even if a cursory Github search would show issues. It
took months just to name HTML Sanitisers responsibly. Always a
tiresome wait...

That said, establishing a standard and having it adopted by a
community group is better than nothing at all. Like it or not, we're
self regulating with serious discipline issues ;). That won't change
any time soon. At least the tools for distributing vulnerability data
will exist for those who want to go the extra mile and earn some
goodwill. As Chris mentioned, one barrier is how to integrate 3rd
party disclosures into a voluntary system - there's no easy solution
there though I hope there's some method that could be implemented to
serve the target of all this - the folk checking if their dependency
versions are vulnerable to something. One step at a time, I suppose!

For now, the idea with PHP-FIG was come up with something its members
would feel fine with adopting. It's a really small club but it
encompasses the likes of Symfony, Zend, Drupal and others (yes, even
Composer) that can establish a standard and put in developers' hands.

Paddy

--

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative