GSD-2015-8994
Vulnerability from gsd - Updated: 2023-12-13 01:20Details
An issue was discovered in PHP 5.x and 7.x, when the configuration uses apache2handler/mod_php or php-fpm with OpCache enabled. With 5.x after 5.6.28 or 7.x after 7.0.13, the issue is resolved in a non-default configuration with the opcache.validate_permission=1 setting. The vulnerability details are as follows. In PHP SAPIs where PHP interpreters share a common parent process, Zend OpCache creates a shared memory object owned by the common parent during initialization. Child PHP processes inherit the SHM descriptor, using it to cache and retrieve compiled script bytecode ("opcode" in PHP jargon). Cache keys vary depending on configuration, but filename is a central key component, and compiled opcode can generally be run if a script's filename is known or can be guessed. Many common shared-hosting configurations change EUID in child processes to enforce privilege separation among hosted users (for example using mod_ruid2 for the Apache HTTP Server, or php-fpm user settings). In these scenarios, the default Zend OpCache behavior defeats script file permissions by sharing a single SHM cache among all child PHP processes. PHP scripts often contain sensitive information: Think of CMS configurations where reading or running another user's script usually means gaining privileges to the CMS database.
Aliases
Aliases
{
"GSD": {
"alias": "CVE-2015-8994",
"description": "An issue was discovered in PHP 5.x and 7.x, when the configuration uses apache2handler/mod_php or php-fpm with OpCache enabled. With 5.x after 5.6.28 or 7.x after 7.0.13, the issue is resolved in a non-default configuration with the opcache.validate_permission=1 setting. The vulnerability details are as follows. In PHP SAPIs where PHP interpreters share a common parent process, Zend OpCache creates a shared memory object owned by the common parent during initialization. Child PHP processes inherit the SHM descriptor, using it to cache and retrieve compiled script bytecode (\"opcode\" in PHP jargon). Cache keys vary depending on configuration, but filename is a central key component, and compiled opcode can generally be run if a script\u0027s filename is known or can be guessed. Many common shared-hosting configurations change EUID in child processes to enforce privilege separation among hosted users (for example using mod_ruid2 for the Apache HTTP Server, or php-fpm user settings). In these scenarios, the default Zend OpCache behavior defeats script file permissions by sharing a single SHM cache among all child PHP processes. PHP scripts often contain sensitive information: Think of CMS configurations where reading or running another user\u0027s script usually means gaining privileges to the CMS database.",
"id": "GSD-2015-8994",
"references": [
"https://www.suse.com/security/cve/CVE-2015-8994.html",
"https://ubuntu.com/security/CVE-2015-8994"
]
},
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2015-8994"
],
"details": "An issue was discovered in PHP 5.x and 7.x, when the configuration uses apache2handler/mod_php or php-fpm with OpCache enabled. With 5.x after 5.6.28 or 7.x after 7.0.13, the issue is resolved in a non-default configuration with the opcache.validate_permission=1 setting. The vulnerability details are as follows. In PHP SAPIs where PHP interpreters share a common parent process, Zend OpCache creates a shared memory object owned by the common parent during initialization. Child PHP processes inherit the SHM descriptor, using it to cache and retrieve compiled script bytecode (\"opcode\" in PHP jargon). Cache keys vary depending on configuration, but filename is a central key component, and compiled opcode can generally be run if a script\u0027s filename is known or can be guessed. Many common shared-hosting configurations change EUID in child processes to enforce privilege separation among hosted users (for example using mod_ruid2 for the Apache HTTP Server, or php-fpm user settings). In these scenarios, the default Zend OpCache behavior defeats script file permissions by sharing a single SHM cache among all child PHP processes. PHP scripts often contain sensitive information: Think of CMS configurations where reading or running another user\u0027s script usually means gaining privileges to the CMS database.",
"id": "GSD-2015-8994",
"modified": "2023-12-13T01:20:03.413539Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@mitre.org",
"ID": "CVE-2015-8994",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "n/a",
"version": {
"version_data": [
{
"version_value": "n/a"
}
]
}
}
]
},
"vendor_name": "n/a"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "An issue was discovered in PHP 5.x and 7.x, when the configuration uses apache2handler/mod_php or php-fpm with OpCache enabled. With 5.x after 5.6.28 or 7.x after 7.0.13, the issue is resolved in a non-default configuration with the opcache.validate_permission=1 setting. The vulnerability details are as follows. In PHP SAPIs where PHP interpreters share a common parent process, Zend OpCache creates a shared memory object owned by the common parent during initialization. Child PHP processes inherit the SHM descriptor, using it to cache and retrieve compiled script bytecode (\"opcode\" in PHP jargon). Cache keys vary depending on configuration, but filename is a central key component, and compiled opcode can generally be run if a script\u0027s filename is known or can be guessed. Many common shared-hosting configurations change EUID in child processes to enforce privilege separation among hosted users (for example using mod_ruid2 for the Apache HTTP Server, or php-fpm user settings). In these scenarios, the default Zend OpCache behavior defeats script file permissions by sharing a single SHM cache among all child PHP processes. PHP scripts often contain sensitive information: Think of CMS configurations where reading or running another user\u0027s script usually means gaining privileges to the CMS database."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "http://openwall.com/lists/oss-security/2017/02/28/1",
"refsource": "MISC",
"url": "http://openwall.com/lists/oss-security/2017/02/28/1"
},
{
"name": "http://seclists.org/oss-sec/2017/q1/520",
"refsource": "MISC",
"url": "http://seclists.org/oss-sec/2017/q1/520"
},
{
"name": "http://marc.info/?l=php-internals\u0026m=147921016724565\u0026w=2",
"refsource": "MISC",
"url": "http://marc.info/?l=php-internals\u0026m=147921016724565\u0026w=2"
},
{
"name": "https://ma.ttias.be/a-better-way-to-run-php-fpm/",
"refsource": "MISC",
"url": "https://ma.ttias.be/a-better-way-to-run-php-fpm/"
},
{
"name": "http://marc.info/?l=php-internals\u0026m=147876797317925\u0026w=2",
"refsource": "MISC",
"url": "http://marc.info/?l=php-internals\u0026m=147876797317925\u0026w=2"
},
{
"name": "http://seclists.org/oss-sec/2016/q4/343",
"refsource": "MISC",
"url": "http://seclists.org/oss-sec/2016/q4/343"
},
{
"name": "https://bugs.php.net/bug.php?id=69090",
"refsource": "MISC",
"url": "https://bugs.php.net/bug.php?id=69090"
}
]
}
},
"nvd.nist.gov": {
"configurations": {
"CVE_data_version": "4.0",
"nodes": [
{
"children": [],
"cpe_match": [
{
"cpe23Uri": "cpe:2.3:a:php:php:*:*:*:*:*:*:*:*",
"cpe_name": [],
"versionEndIncluding": "5.6.29",
"versionStartIncluding": "5.0.0",
"vulnerable": true
},
{
"cpe23Uri": "cpe:2.3:a:php:php:*:*:*:*:*:*:*:*",
"cpe_name": [],
"versionEndExcluding": "7.0.14",
"versionStartIncluding": "7.0.0",
"vulnerable": true
}
],
"operator": "OR"
}
]
},
"cve": {
"CVE_data_meta": {
"ASSIGNER": "cve@mitre.org",
"ID": "CVE-2015-8994"
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "en",
"value": "An issue was discovered in PHP 5.x and 7.x, when the configuration uses apache2handler/mod_php or php-fpm with OpCache enabled. With 5.x after 5.6.28 or 7.x after 7.0.13, the issue is resolved in a non-default configuration with the opcache.validate_permission=1 setting. The vulnerability details are as follows. In PHP SAPIs where PHP interpreters share a common parent process, Zend OpCache creates a shared memory object owned by the common parent during initialization. Child PHP processes inherit the SHM descriptor, using it to cache and retrieve compiled script bytecode (\"opcode\" in PHP jargon). Cache keys vary depending on configuration, but filename is a central key component, and compiled opcode can generally be run if a script\u0027s filename is known or can be guessed. Many common shared-hosting configurations change EUID in child processes to enforce privilege separation among hosted users (for example using mod_ruid2 for the Apache HTTP Server, or php-fpm user settings). In these scenarios, the default Zend OpCache behavior defeats script file permissions by sharing a single SHM cache among all child PHP processes. PHP scripts often contain sensitive information: Think of CMS configurations where reading or running another user\u0027s script usually means gaining privileges to the CMS database."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "en",
"value": "CWE-264"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://ma.ttias.be/a-better-way-to-run-php-fpm/",
"refsource": "MISC",
"tags": [
"Exploit",
"Technical Description",
"Third Party Advisory"
],
"url": "https://ma.ttias.be/a-better-way-to-run-php-fpm/"
},
{
"name": "https://bugs.php.net/bug.php?id=69090",
"refsource": "MISC",
"tags": [
"Exploit",
"Issue Tracking"
],
"url": "https://bugs.php.net/bug.php?id=69090"
},
{
"name": "http://seclists.org/oss-sec/2017/q1/520",
"refsource": "MISC",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "http://seclists.org/oss-sec/2017/q1/520"
},
{
"name": "http://seclists.org/oss-sec/2016/q4/343",
"refsource": "MISC",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "http://seclists.org/oss-sec/2016/q4/343"
},
{
"name": "http://openwall.com/lists/oss-security/2017/02/28/1",
"refsource": "MISC",
"tags": [
"Mailing List"
],
"url": "http://openwall.com/lists/oss-security/2017/02/28/1"
},
{
"name": "http://marc.info/?l=php-internals\u0026m=147921016724565\u0026w=2",
"refsource": "MISC",
"tags": [
"Mailing List"
],
"url": "http://marc.info/?l=php-internals\u0026m=147921016724565\u0026w=2"
},
{
"name": "http://marc.info/?l=php-internals\u0026m=147876797317925\u0026w=2",
"refsource": "MISC",
"tags": [
"Mailing List"
],
"url": "http://marc.info/?l=php-internals\u0026m=147876797317925\u0026w=2"
}
]
}
},
"impact": {
"baseMetricV2": {
"cvssV2": {
"accessComplexity": "MEDIUM",
"accessVector": "NETWORK",
"authentication": "NONE",
"availabilityImpact": "PARTIAL",
"baseScore": 6.8,
"confidentialityImpact": "PARTIAL",
"integrityImpact": "PARTIAL",
"vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P",
"version": "2.0"
},
"exploitabilityScore": 8.6,
"impactScore": 6.4,
"obtainAllPrivilege": false,
"obtainOtherPrivilege": false,
"obtainUserPrivilege": false,
"severity": "MEDIUM",
"userInteractionRequired": false
},
"baseMetricV3": {
"cvssV3": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.6,
"impactScore": 5.9
}
},
"lastModifiedDate": "2022-08-16T13:16Z",
"publishedDate": "2017-03-02T06:59Z"
}
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…