Summary: | <dev-lang/php-{5.4.34,5.5.18}: multiple vulnerabilities (CVE-2014-{3668,3669,3670}) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | morlix, php-bugs |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | A2 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Agostino Sarubbo
2014-10-20 09:44:27 UTC
Please go ahead with stabilisation. I've tested 5.4.34 and 5.5.18 on amd64 (about 15 servers), both seem to work fine. Arches, please test and mark stable: =dev-lang/php-5.4.34 =dev-lang/php-5.5.18 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sparc x86" Stable for HPPA. amd64 stable x86 stable sparc stable Stable on alpha. arm stable ppc stable ppc64 stable ia64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one. GLSA is being drafted. CVE-2014-3670 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-3670): The exif_ifd_make_value function in exif.c in the EXIF extension in PHP before 5.4.34, 5.5.x before 5.5.18, and 5.6.x before 5.6.2 operates on floating-point arrays incorrectly, which allows remote attackers to cause a denial of service (heap memory corruption and application crash) or possibly execute arbitrary code via a crafted JPEG image with TIFF thumbnail data that is improperly handled by the exif_thumbnail function. CVE-2014-3669 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-3669): Integer overflow in the object_custom function in ext/standard/var_unserializer.c in PHP before 5.4.34, 5.5.x before 5.5.18, and 5.6.x before 5.6.2 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via an argument to the unserialize function that triggers calculation of a large length value. CVE-2014-3668 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-3668): Buffer overflow in the date_from_ISO8601 function in the mkgmtime implementation in libxmlrpc/xmlrpc.c in the XMLRPC extension in PHP before 5.4.34, 5.5.x before 5.5.18, and 5.6.x before 5.6.2 allows remote attackers to cause a denial of service (application crash) via (1) a crafted first argument to the xmlrpc_set_type function or (2) a crafted argument to the xmlrpc_decode function, related to an out-of-bounds read operation. This issue was resolved and addressed in GLSA 201411-04 at http://security.gentoo.org/glsa/glsa-201411-04.xml by GLSA coordinator Sean Amoss (ackle). How is it possible that according to "glsa-check -l" i'm affected by those two GLSAs when my php installations are up to date? # glsa-check -l affected [A] means this GLSA was marked as applied (injected), [U] means the system is not affected and [N] indicates that the system might be affected. 201408-11 [N] PHP: Multiple vulnerabilities ( dev-lang/php ) 201411-04 [N] PHP: Multiple vulnerabilities ( dev-lang/php ) # equery l php * Searching for php ... [IP-] [ ] dev-lang/php-5.4.36:5.4 [IP-] [ ] dev-lang/php-5.5.20:5.5 Kind regards (In reply to Timo Eissler from comment #16) > How is it possible that according to "glsa-check -l" i'm affected by those > two GLSAs when my php installations are up to date? This has to do with the way GLSAmake works without supporting slots, so a GLSA needs to retroactively be updated to add versions not vulnerable if not using the latest slot. Please file a new bug about it under Gentoo Security with component GLSA errors. Some more detailed info specific to this case for your benefit (you can look this up in the glsa xml in /usr/portage/metadata/glsa). <unaffected range="ge">5.5.16</unaffected> <unaffected range="rge">5.4.32</unaffected> <unaffected range="rge">5.3.29</unaffected> <unaffected range="rge">5.4.34</unaffected> <vulnerable range="lt">5.5.16</vulnerable> I.e anything below 5.5.16 is by default vulnerable according to its definition, but there are added exceptions for *>= (rge, i.e. it ignores revision bumps after this version) for 5.4.32 and 5.4.34, this fix in this specific case is for us to add further 5.4 versions (e.g. up to 5.4.40) to the list of unaffected packages. Anyhow, upen a new bug about it and we'll get to it.. |