The lack of symlink checks while doing installation and upgrades, which initiate various system write operations, can cause privileged users unknowingly to overwrite critical system files. Details: To be vulnerable, a non-privileged user that has access to the system must explicitly create a symlink from a predictable location, to which PEAR will write, with an end point at a system critical file such as /etc/passwd. A non-privileged user is not required to have permission to the symlink endpoint, the required privileges are obtained by asking a privileged user to perform a routine task, such as installation or upgrade of packages, which will in turn write to a predictable location; the whole process is transparent for the privileged user and will in turn write to the symbolically linked endpoint. It is not possible to inject arbitrary information with this approach, it is only possible to overwrite symlinked files with one of the files coming from the PEAR package being installed/updated.
Maintainers, is it OK to stabilize =dev-php/PEAR-PEAR-1.9.2?
Please go ahead.
Thank you. Arches, please stabilize =dev-php/PEAR-PEAR-1.9.2
amd64 done
Added CVE assignment per http://www.openwall.com/lists/oss-security/2011/02/28/12.
Shouldn't =dev-php/pear-1.9.2 also go stable at the same time? Otherwise it tends to downgrade PEAR-PEAR again because of rdeps.... at least on my x86 testbox.
Indeed. It is important to simultaneously stabilise dev-php/pear as a system should never install PEAR-PEAR directly, but as a dependency to pear.
Ok, they both look ready to go, here on x86.
amd64, please also stabilize =dev-php/pear-1.9.2 Sorry about that. The full stabilization list is: =dev-php/pear-1.9.2 =dev-php/PEAR-PEAR-1.9.2
x86 done. Thanks.
Stable for HPPA.
(In reply to comment #9) > amd64, please also stabilize =dev-php/pear-1.9.2 > > Sorry about that. The full stabilization list is: > > =dev-php/pear-1.9.2 > =dev-php/PEAR-PEAR-1.9.2 > works for me :)
ppc64 stable
ppc stable
alpha/arm/ia64/s390/sh/sparc stable
Thanks, everyone. GLSA Vote: yes.
This vulnerability has not been totally fixed as per the following messages: http://seclists.org/oss-sec/2011/q1/346 and http://seclists.org/oss-sec/2011/q1/444 (as well as others in the thread) Summary is as follows: Not the full fix was in the patch for CVE-2011-1072, New CVE-2011-1144 was opened to address the incomplete Fix in 1072. Release is in the 1.9.3 tree, with the actual patch that is claimed to fix the issue. Patch is here: http://news.php.net/php.pear.core/9791 which is part of the PEAR-1.9.3 tree.
(In reply to comment #18) > This vulnerability has not been totally fixed as per the following messages: > Thanks, Yury. @php, looks like we have an upstream patch but no new release...
Added PEAR-PEAR-1.9.2-r1 with the patch. Hopefully this will do the trick.
(In reply to comment #20) > Added PEAR-PEAR-1.9.2-r1 with the patch. Hopefully this will do the trick. Great, thank you. Arches, please test and mark stable: =dev-php/PEAR-PEAR-1.9.2-r1 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
amd64 ok
amd64 done. Thanks Agostino
ppc/ppc64 stable
x86 done... again.
Thanks a second time, everyone. Still GLSA Vote: yes.
CVE-2011-1144 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1144): The installer in PEAR 1.9.2 and earlier allows local users to overwrite arbitrary files via a symlink attack on the package.xml file, related to the (1) download_dir, (2) cache_dir, (3) tmp_dir, and (4) pear-build-download directories. NOTE: this vulnerability exists because of an incomplete fix for CVE-2011-1072. CVE-2011-1072 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1072): The installer in PEAR before 1.9.2 allows local users to overwrite arbitrary files via a symlink attack on the package.xml file, related to the (1) download_dir, (2) cache_dir, (3) tmp_dir, and (4) pear-build-download directories, a different vulnerability than CVE-2007-2519.
Vote: YES. New GLSA request filed.
This issue was resolved and addressed in GLSA 201412-09 at http://security.gentoo.org/glsa/glsa-201412-09.xml by GLSA coordinator Sean Amoss (ackle).
