mirror of
https://github.com/php/php-src.git
synced 2024-11-23 01:44:06 +08:00
Move most of this to https://github.com/php/policies as per Policies RFC
This commit is contained in:
Derick Rethans
parent
3a5edcca47
commit
7c354b7cf2
159
SECURITY.md
159
SECURITY.md
@ -1,127 +1,4 @@
|
||||
# Vulnerability Disclosure Policy
|
||||
|
||||
*This document was originally published at <https://wiki.php.net/security>.*
|
||||
|
||||
## Introduction
|
||||
|
||||
For the sake of our users, we classify some of the issues found in PHP
|
||||
as "security issues". This document is intended to explain which issues
|
||||
are thus classified, how we handle those issues and how to report them.
|
||||
|
||||
## Classification
|
||||
|
||||
We classify as security issues bugs that:
|
||||
|
||||
- allow users to execute unauthorized actions
|
||||
- cross security boundaries
|
||||
- access data that is not intended to be accessible
|
||||
- severely impact accessibility or performance of the system
|
||||
|
||||
The purpose of this classification is to alert the users and the
|
||||
developers about the bugs that need to be prioritized in their handling.
|
||||
|
||||
We define three categories of security issues, by their severity,
|
||||
described below. Please note that this categorization is in many aspects
|
||||
subjective, so it ultimately relies on the judgement of the PHP
|
||||
developers.
|
||||
|
||||
### High severity
|
||||
|
||||
These issues may allow:
|
||||
|
||||
- third party to compromise any, or most installations of PHP
|
||||
- the execution of arbitrary code
|
||||
- disabling the system completely
|
||||
- access to any file a local PHP user can access.
|
||||
|
||||
The issue can be triggered on any, or on most typical installations, and
|
||||
does not require exotic and non-recommended settings to be triggered.
|
||||
|
||||
This category also includes issues that can be triggered in code or
|
||||
functions known to be frequently used (session, json, mysql, openssl,
|
||||
etc.) during typical usage, and that require settings or configurations
|
||||
that may not be strictly the best practice, but are commonly used.
|
||||
|
||||
This category also may include issues that require special code or code
|
||||
pattern if such code or pattern is present in many popular libraries.
|
||||
|
||||
This kind of issues usually requires a CVE report.
|
||||
|
||||
### Medium severity
|
||||
|
||||
These issues may have the same potential to compromise an installation
|
||||
as a high severity issue, but may also require:
|
||||
|
||||
- an extension that is not commonly used
|
||||
- a particular type of configuration that is used only in narrow
|
||||
specific circumstances
|
||||
- relies on old version of a third-party library being used
|
||||
- code, or patterns of code, that are known to be used infrequently
|
||||
- code that is very old, or extremely uncommon (and so is used
|
||||
infrequently)
|
||||
|
||||
This kind of issues usually will have a CVE number, unless the required
|
||||
configuration is particularly exotic to the point it's not practically
|
||||
usable.
|
||||
|
||||
### Low severity
|
||||
|
||||
This issue allows theoretical compromise of security, but practical
|
||||
attack is usually impossible or extremely hard due to common practices
|
||||
or limitations that are virtually always present or imposed.
|
||||
|
||||
This also includes problems with configuration, documentation, and other
|
||||
non-code parts of the PHP project that may mislead users, or cause them
|
||||
to make their system, or their code less secure.
|
||||
|
||||
Issues that can trigger unauthorized actions that do not seem to be
|
||||
useful for any practical attack can also be categorized as low severity.
|
||||
|
||||
Security issues, that are present only in unstable branches, belong to
|
||||
this category, too. Any branch that has no stable release, is per se not
|
||||
intended for the production use.
|
||||
|
||||
Low severity issues usually do not need to have CVE and may, at the
|
||||
discretion of the PHP developers, be disclosed publicly before the fix
|
||||
is released or available.
|
||||
|
||||
### Not a security issue
|
||||
|
||||
We do not classify as a security issue any issue that:
|
||||
|
||||
- requires invocation of specific code, which may be valid but is
|
||||
obviously malicious
|
||||
- requires invocation of functions with specific arguments, which may
|
||||
be valid but are obviously malicious
|
||||
- requires specific actions to be performed on the server, which are
|
||||
not commonly performed, or are not commonly permissible for the user
|
||||
(uid) executing PHP
|
||||
- requires privileges superior to that of the user (uid) executing PHP
|
||||
- requires the use of debugging facilities - ex. xdebug, var_dump
|
||||
- requires the use of settings not recommended for production - ex.
|
||||
error reporting to output
|
||||
- requires the use of non-standard environment variables - ex.
|
||||
USE_ZEND_ALLOC
|
||||
- requires the use of non-standard builds - ex. obscure embedded
|
||||
platform, not commonly used compiler
|
||||
- requires the use of code or settings known to be insecure
|
||||
- requires the use of FFI
|
||||
- requires an open_basedir bypass
|
||||
|
||||
## Handling issues
|
||||
|
||||
High and medium severity fixes are merged into a private security repository,
|
||||
and then merged to the main repository before the release is tagged.
|
||||
|
||||
Low severity fixes are merged immediately after the fix is available and
|
||||
handled like all regular bugs are handled consequently. However, release
|
||||
managers may choose to pull those fixes into the RC branch after the
|
||||
branch is created, and also backport them into a security-only release
|
||||
branch.
|
||||
|
||||
## FAQ
|
||||
|
||||
### How do I report a security issue?
|
||||
# Reporting Security Issues
|
||||
|
||||
Please report security vulnerabilities on GitHub at:
|
||||
<https://github.com/php/php-src/security/advisories/new>
|
||||
@ -134,35 +11,7 @@ Vulnerability reports remain private until published. When published, you will
|
||||
be credited as a contributor, and your contribution will reflect the MITRE
|
||||
Credit System.
|
||||
|
||||
### What do you consider a responsible disclosure?
|
||||
# Vulnerability Policy
|
||||
|
||||
Please report the issue as described above. Please communicate with
|
||||
the developers about when the fix will be released - usually it's the
|
||||
next monthly release after the bug was reported. Some issues can take
|
||||
longer. After the fix is released (releases usually happen on Thursdays)
|
||||
please feel free to disclose the issue as you see fit.
|
||||
|
||||
### What if I think it's a security issue but the developers disagree?
|
||||
|
||||
Please read the above and try to explain to us why it fits the
|
||||
description.
|
||||
|
||||
### What if the developers still don't think it's a security issue?
|
||||
|
||||
We'll have to agree to disagree.
|
||||
|
||||
### The bug I submitted was classified as "not a security issue." You don't believe it's real?
|
||||
|
||||
It has nothing to do with the bug being real or its importance to
|
||||
you. It just means it does not fit our specific definitions for issues
|
||||
that we will handle in a special way. We fix a lot of non-security bugs
|
||||
and pull requests are always welcome.
|
||||
|
||||
### But you classified bug #424242 as a security issue, but not this one?!
|
||||
|
||||
Each bug usually has its aspects, if a short discussion does not
|
||||
yield agreement we'd rather do more fixing and less arguing.
|
||||
|
||||
### Do you pay bounties for security issues?
|
||||
|
||||
PHP is a volunteer project. We have no money, thus we can't pay bounties.
|
||||
Our full policy is described at
|
||||
https://github.com/php/policies/blob/main/security-classification.rst
|
||||
|
||||
Loading…
Reference in New Issue
Block a user