From 7c354b7cf2360828bff3566cea350ce1dc07aac2 Mon Sep 17 00:00:00 2001 From: Derick Rethans Date: Tue, 30 Jan 2024 17:31:55 +0000 Subject: [PATCH] Move most of this to https://github.com/php/policies as per Policies RFC --- SECURITY.md | 159 ++-------------------------------------------------- 1 file changed, 4 insertions(+), 155 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 161e0810b58..deb5a7a950a 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,127 +1,4 @@ -# Vulnerability Disclosure Policy - -*This document was originally published at .* - -## 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: @@ -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