Summary: | <dev-lang/php-5.2.10-r1 DoS (CVE-2009-2687) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Alex Legler (RETIRED) <a3li> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | php-bugs |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.php.net/releases/5_2_10.php | ||
Whiteboard: | A3 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Alex Legler (RETIRED)
2009-06-19 07:20:52 UTC
Ah that's what killed my server this morning -.- I just saw something uploading a jpg :( php-5.2.10 is in the tree now. Please give it a day or two before stabilization, to see whether any problems pop up. I won't be available on the weekend. The mentioned DoS issue is most likely not the only one, I have a list of possibly security-relevant bugs, and I'll go through it and format it once I've got more time again. Thanks hoffe. There is also a PHP safe_mode bypass which I stumbled upon, so I thought I might add it here: http://www.packetstormsecurity.com/0906-exploits/php5210-bypass.txt (In reply to comment #3) > Thanks hoffe. There is also a PHP safe_mode bypass which I stumbled upon, so I > thought I might add it here: > http://www.packetstormsecurity.com/0906-exploits/php5210-bypass.txt That's a win32-only issue which seems to have been fixed in 5.2.9 already. http://bugs.php.net/bug.php?id=45997 Is it ok to stabilize now? Maybe you have some time today and want to fix #256941 first so that we minimize version bumps? If I don't get a reply today, I'll add arches so that we don't delay this too much. (In reply to comment #5) > Is it ok to stabilize now? Maybe you have some time today and want to fix > #256941 first so that we minimize version bumps? If I don't get a reply today, > I'll add arches so that we don't delay this too much. Well no, I have no immediate fix for it, and I don't think reverting this change just now is a good idea either. Arches, please test and mark stable: =dev-lang/php-5.2.10 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86" Repoman complained thusly: RepoMan scours the neighborhood... IUSE.invalid 2 dev-lang/php/php-5.2.9-r2.ebuild: zip-external dev-lang/php/php-5.2.10.ebuild: zip-external Note: use --include-dev (-d) to check dependencies for 'dev' profiles Please fix these important QA issues first. RepoMan sez: "Make your QA payment on time and you'll never see the likes of me." and that's obviously a bug in repoman, so I put back that line in metadata.xml temporarily to work around the problem. Stable for HPPA. (In reply to comment #8) > RepoMan scours the neighborhood... > IUSE.invalid 2 > dev-lang/php/php-5.2.9-r2.ebuild: zip-external > dev-lang/php/php-5.2.10.ebuild: zip-external > > Note: use --include-dev (-d) to check dependencies for 'dev' profiles > > Please fix these important QA issues first. > RepoMan sez: "Make your QA payment on time and you'll never see the likes of > me." > > and that's obviously a bug in repoman, so I put back that line in metadata.xml > temporarily to work around the problem. Are you sure your eclass/ directory is up-to-date? I don't see a repoman warning with repoman full here.. If you still do, I'll revert metadata.xml for now (or you can feel free to do so as well, if I can't do it in time). ppc64 done ppc done i couldnt commit either because of the same problem; adding us back in. (In reply to comment #8) > and that's obviously a bug in repoman, so I put back that line in metadata.xml > temporarily to work around the problem. (In reply to comment #12) > i couldnt commit either because of the same problem; adding us back in. Well, I have reverted metadata.xml to the previous revision which includes the zip-external USE flag (basically what jer did locally). I have neither an idea what causes/caused this problem nor am I able to reproduce it on ~amd64 or stable x86. What I did miss was a zip-external line in profiles/base/package.use.mask, but I doubt this was the problem. Fixed now anyway. Please go ahead with stabilization. x86 stable amd64 stable Stable on alpha There is a regression in ext/curl which renders certain code snippets unusuable. As this happens only with USE=curl and specific code, I'd be against masking, but I think we should not let the remaining arches stable it. Security, what's more important, this issue or the DoS problem? http://news.php.net/php.internals/44469 http://bugs.php.net/bug.php?id=48518 ppc64 done ppc done arm/ia64/s390/sh/sparc stable CVE-2009-2687 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2687): The exif_read_data function in the Exif module in PHP before 5.2.10 allows remote attackers to cause a denial of service (crash) via a malformed JPEG image with invalid offset fields, a different issue than CVE-2005-3353. php-5.2.11 has been stabilized meanwhile, I'm including this in the next PHP GLSA. GLSA 201001-03. Thank you everyone, sorry about the delay. |