Created attachment 157819 [details] Document php5 security issues fixed in 389655 - Document php5 multiple vulnerabilities Security: CVE-2015-2325 Security: CVE-2015-2326 Security: CVE-2015-3414 Security: CVE-2015-3415 Security: CVE-2015-3416 == Comments == The actual update was already done. Just play catch up with the security/vuxml update. From https://svnweb.freebsd.org/changeset/ports/389655 - php5 to 5.4.42 - php55 to 5.5.26 - php56 to 5.6.10 == Validation == # make validate /bin/sh /usr/ports/security/vuxml/files/tidy.sh "/usr/ports/security/vuxml/files/tidy.xsl" "/usr/ports/security/vuxml/vuln.xml" > "/usr/ports/security/vuxml/vuln.xml.tidy" >>> Validating... /usr/local/bin/xmllint --valid --noout /usr/ports/security/vuxml/vuln.xml >>> Successful. Checking if tidy differs... ... seems okay Checking for space/tab... ... seems okay /usr/local/bin/python2.7 /usr/ports/security/vuxml/files/extra-validation.py /usr/ports/security/vuxml/vuln.xml # env PKG_DBDIR=/usr/ports/security/vuxml pkg audit php56-5.6.9 php56-5.6.9 is vulnerable: php5 -- multiple vulnerabilities CVE: CVE-2015-3416 CVE: CVE-2015-3415 CVE: CVE-2015-3414 CVE: CVE-2015-2326 CVE: CVE-2015-2325 WWW: https://vuxml.FreeBSD.org/freebsd/cdff0af2-1492-11e5-a1cf-002590263bf5.html 1 problem(s) in the installed packages found. # env PKG_DBDIR=/usr/ports/security/vuxml pkg audit php56-5.6.10 0 problem(s) in the installed packages found.
Hi, Speaking for SQLite3 (CVE-2015-3414, CVE-2015-3415, CVE-2015-3416) they were documented in dec3164f-3121-45ef-af18-bb113ac5082f. My reading of the PHP Makefile.ext is that when building these SQLite3 related modules, the port version of sqlite3 is used and therefore a version update of PHP shouldn't change anything (because they are merely wrappers). Can you verify if that's the case? If we need to document PHP's SQLite3 module (i.e. they still use the bundled code), then we should add PHP to the SQLite3 entry. The PCRE issues (CVE-2015-3210 and CVE-2015-3217) are similar (port version is used) and therefore needs verification too. Thanks for working on this by the way!
Created attachment 157848 [details] Document php5 security issues fixed in 389655 Xin, Thanks for the feedback. The revised entries removes mentioning the CVE's with the <cvename> tags but leaves the upstream's blockquote untouched. I've added the following verbiage beneath the upstream quotes so the non-applicability the CVE's is explained. "The CVE entries reported by the PHP project are not applicable as the FreeBSD port defaults to linking to the port version of sqlite3 and pcre." As far as behind the scenes: ======================================== For sqlite3, the Makefile.ext has this: CONFIGURE_ARGS+=--with-sqlite3=${LOCALBASE} CONFIGURE_ARGS+=--with-pdo-sqlite=${LOCALBASE} So the package's shared library links against sqlite3 package and not the bundled library. # pkg info -l php56-sqlite3 php56-sqlite3-5.6.10: ... <truncated> ... /usr/local/lib/php/20131226/sqlite3.so # ldd /usr/local/lib/php/20131226/sqlite3.so /usr/local/lib/php/20131226/sqlite3.so: libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x80160b000) ... <truncated> ... # pkg which /usr/local/lib/libsqlite3.so.0 /usr/local/lib/libsqlite3.so.0 was installed by package sqlite3-3.8.10.2 ======================================== For pcre, the port Makefile has LIB_DEPENDS= libpcre.so:${PORTSDIR}/devel/pcre --with-pcre-regex=${LOCALBASE} The Makefile.ext contains: --with-pcre-dir=${LOCALBASE} # pkg info -l php56 php56-5.6.10: /usr/local/bin/php ... <truncated> ... # ldd /usr/local/bin/php* php: ... <truncated> ... libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x800df0000) ... <truncated> ... # pkg which /usr/local/lib/libpcre.so.1 /usr/local/lib/libpcre.so.1 was installed by package pcre-8.37_1 CVE-2015-2325 and CVE-2015-2325 were from an older vuxml entry. Our 8.37_1 already fixes issues newer than the 8.37 in the bundled library so we are btter off. http://www.vuxml.org/freebsd/4a88e3ed-00d3-11e5-a072-d050996490d0.html ======================================== Please let me know if that all makes sense.
Xin, Pending the result of CVE assignment, we may want to hold this PR open even after the initial commit to get the affected versions in vuxml. We can come back and supplement the entry later with the CVE's based off the result of this thread: http://openwall.com/lists/oss-security/2015/06/18/3
(In reply to Jason Unovitch from comment #2) Well, if they are not affected (by the known issues that already have an entry), it doesn't make much sense to create a new entry just for PHP. However, in your comment #3, it looks like there are some additional PHP modules affected by other issues, I think we should modify the vuxml entry to reflect these.
Created attachment 157875 [details] Document php5 security issues fixed in 389655 Updated to cover the php5, php5-ftp, and php5-pgsql plus variations based off the updates to the PHP changelog. One of the security issues is in the PHP bug tracker as a security issue but does not have a CVE (yet?). - https://bugs.php.net/bug.php?id=69719 (Incorrect handling of paths with NULs) is tagged as security bug, is listed as fixed in these releases, but does not have a CVE. - CVE-2015-4642 was Windows only - CVE-2015-4643 is the -ftp packae - CVE-2015-4644 is the -pgsql package
As a general comment, our recent entries in the PHP case are rather inconsistent. Some of the entries are based off the release announcement with the general verbiage like the one for this release. "The PHP development team announces the immediate availability of PHP 5.4.42. Six security-related issues in PHP were fixed in this release, as well as several security issues in bundled sqlite library (CVE-2015-3414, CVE-2015-3415, CVE-2015-3416). All PHP 5.4 users are encouraged to upgrade to this version" Others entries, such as 31de2e13-00d2-11e5-a072-d050996490d0 list the entry from the changelog ("Fixed bug #69364 (PHP Multipart/form-data remote DoS Vulnerability). (CVE-2015-4024"). d2a892b9-2605-11e4-9da0-00a0986f28c4 lists security issues with the "fileinfo" plugin but does not list the php53-fileinfo package as impacted. I find this makes it a bit difficult to know what best template to base a new entry off. What is the preferred style (release announcement or changelog entries) and how do you feel about an audit and standardization of the recent past's entries? A one time cleanup seems like it would help lay some groundwork toward sticking with the standard in the future. Since this is not necesarily a bug I can work that and do a Phabricator review for the cleanup.
Created attachment 157908 [details] Document php5 security issues fixed in 389655 (changelog based documentation) (In reply to Jason Unovitch from comment #6) Document based off the PHP change log. As commented above this is what I'd like to clean up the recent past's entries to reflect. The "Six security-related issues in PHP were fixed in this release, as well as several security issues in bundled ..." style entries based off the PHP home page is just too vague.
Xin, Do you have any feedback on the preferred documentation approach? Either patch should be ready to be applied based of the preferred style.
A commit references this bug: Author: delphij Date: Mon Jun 22 23:39:35 UTC 2015 New revision: 390344 URL: https://svnweb.freebsd.org/changeset/ports/390344 Log: Document 3 vulnerabilities with PHP that affected 4 extensions. PR: 200926 Submitted by: Jason Unovitch Changes: head/security/vuxml/vuln.xml
I have committed a slightly changed version of vuxml.xml based on your second submission. (Note that PHP #69719 is really not a "Core" bug but affected DOM and GD extensions), thanks for your submission!