diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000000..cdc5a8be15b --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,165 @@ +# Security Classification Document + +*The canonical version of this document is located at . +Where there are discrepancies, the canonical version takes precedence.* + +## Meta + +- Authors: Release Managers +- Date: November 2016 +- Version: 1.0.1 +- RFC: [Security Issue Classification](https://wiki.php.net/rfc/security-classification) + +## 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 security repository and +merged 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 security-only release +branch. + +## FAQ + +Q. How do I report a security issue?\ +A. Please report it on , choosing type "Security". +This will automatically make it private. If for some reason you can not +do that, or need to talk to somebody about a PHP security issue that is +not exactly a bug report, please write to security@php.net. + +Q. What do you consider a responsible disclosure?\ +A. 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 Thursday) +please feel free to disclose the issue as you see fit. + +Q. What if I think it's a security issue but developers disagree?\ +A. Please read the above and try to explain to us why it fits the +description. + +Q. What if developers still don't think it's a security issue?\ +A. We'll have to agree to disagree. + +Q. The bug I submitted was classified as "not a security issue", you +don't believe it's real?\ +A. 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. + +Q. But you classified bug #424242 as security issue, but not this +one?!\ +A. Each bug usually has its aspects, if a short discussion does not +yield agreement we'd rather do more fixing and less arguing. + +Q. Do you pay bounties for security issues?\ +A. PHP is a volunteer project. We have no money, thus we can't pay them.