Bug 900934 (CVE-2014-3622) - VUL-0: CVE-2014-3622: php: remote memory whoes
Summary: VUL-0: CVE-2014-3622: php: remote memory whoes
Status: RESOLVED FIXED
Alias: CVE-2014-3622
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Petr Gajdos
QA Contact: Security Team bot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-13 13:47 UTC by Sebastian Krahmer
Modified: 2014-10-20 13:45 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Krahmer 2014-10-13 13:47:48 UTC 
Please see

https://bugs.php.net/bug.php?id=68088
Comment 1 Swamp Workflow Management 2014-10-13 22:00:43 UTC 
bugbot adjusting priority
Comment 2 Petr Gajdos 2014-10-14 08:08:42 UTC 
add_post_var() is present from 5.6, so this is not issue for older distributions.

It is fixed in php 5.6.1 -> submitting it to factory and 13.2 will fix this issue for us.

Keeping this bug opened to ensure this is fixed in 13.2.
Comment 3 Ivan Pencak 2014-10-15 07:57:46 UTC 
Hi there, I got customer asking whether this very same CVE-2014-3622 is fixed in php versions 5.3.8 (SLES 11 SP2) and 5.3.17 (SLES 11 SP3) but as you say it's fixed since 5.6 which is not available for SLES. Can you build PTF for the latest SLES 11 SP3?
I can open L3 for that.
Comment 4 Petr Gajdos 2014-10-15 08:20:18 UTC 
I do not think php in 5.3.x is affected, see comment 2.
Comment 5 Petr Gajdos 2014-10-15 08:24:17 UTC 
More over, that could be considered as bug in the extension itself:

Right now this is not an exploitable problem, because in order for this
to be a big problem the called input filter must do something like
freeing the value supplied. Then we would have an illegal efree() that
is potentially exploitable for remote code execution.

No such extension is, of course, known.
Comment 6 Petr Gajdos 2014-10-15 08:25:04 UTC 
(In reply to Petr Gajdos from comment #5)
> Right now this is not an exploitable problem, because in order for this
> to be a big problem the called input filter must do something like
> freeing the value supplied. Then we would have an illegal efree() that
> is potentially exploitable for remote code execution.

Oh forgot to quote this. This wording is from php bug.
Comment 7 Petr Gajdos 2014-10-20 13:45:43 UTC 
13.2 has 5.6.1.