Bugzilla – Bug 864566
VUL-0: CVE-2014-2020: php5: gd missing data type checking allows unauthorized disclosure of information
Last modified: 2015-03-30 15:08:59 UTC
CVE-2014-2020 ext/gd/gd.c in PHP 5.5.x before 5.5.9 does not check data types, which might allow remote attackers to obtain sensitive information by using a (1) string or (2) array data type in place of a numeric data type, as demonstrated by an imagecrop function call with a string for the x dimension value, a different vulnerability than CVE-2013-7226. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2020 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2020
The SWAMPID for this issue is 56288. This issue was rated as moderate. Please submit fixed packages until 2014-03-05. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
Affected packages: SLE-11-SP3: php53, php5 SLE-10-SP3-TERADATA: php5 SLE-11-SP2: php53, php5
bugbot adjusting priority
(In reply to comment #0) > ext/gd/gd.c in PHP 5.5.x before 5.5.9 does not check data types, which might We haven't such php anywhere.
The SWAMPID for this issue is 56343. This issue was rated as important. Please submit fixed packages until 2014-02-27. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
ext/gd/gd.c is in SLES 11 SP3 php53... please note that affectedness from CVE entries might occasionaly be misleading and does not include older versions unsupported by upstream. The patch seems to match the php53 code we have there. https://github.com/php/php-src/commit/2938329ce19cb8c4197dec146c3ec887c6f61d01
I know, but POCs in the php bug are using imagecrop function, which, as you note in other bug, doesn't exist before php 5.5.x. Also patches from the bug involves only gd_crop.c and imagecrop function in gd.c. Have I missed something obvious?
The patch had me confused, as it actually does not change imagecrop, but references it. The problem as it stands is: This kind of pattern: if (zend_hash_find(HASH_OF(z_rect), "width", sizeof("width"), (void **)&tmp) != FAILURE) { rect.width = Z_LVAL_PP(tmp); does not verify that tmp is actually a "LONG" value, it could be a string value or anything else. This would lead to memory corruptions. (a good pattern would include the convert_to_long() call before.). While this still lives the small issue that passed in arrays in various functionms got their content changed (converted to long), I would not consider that as a security issue currently. So yes, this problem here only affects imagecrop(). So yes, it is not relevant for anything but the new products. Sorry for the mess here.
An update workflow for this issue was started. This issue was rated as moderate. Please submit fixed packages until 2015-04-13. When done, reassign the bug to security-team@suse.de. https://swamp.suse.de/webswamp/wf/61384