security

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
security [2016/11/11 12:59] krakjoesecurity [2024/01/30 17:35] (current) derick
Line 3: Line 3:
    * Authors: Release Managers    * Authors: Release Managers
    * Date: November 2016    * Date: November 2016
-   * Version: 1.0.0+   * Version: 1.0.1
    * RFC: [[rfc:security-classification|Security Issue Classification]]    * RFC: [[rfc:security-classification|Security Issue Classification]]
 +
 +<blockquote>**The canonical version of this document now lives at https://github.com/php/policies/blob/main/security-classification.rst**</blockquote>
  
 ====== Introduction ====== ====== Introduction ======
Line 38: Line 40:
 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 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 require a CVE report.+This kind of issues usually requires a CVE report.
  
 ===== Medium severity ===== ===== Medium severity =====
Line 54: Line 56:
 ===== Low severity ===== ===== 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. +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.  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. 
Line 68: Line 70:
 We do not classify as a security issue any issue that:  We do not classify as a security issue any issue that: 
  
-  * requires invocation of specific code, which may be valid but is obviously malicious (unless it is a very simple frequently used code, such as starting a session, calling a constructor, throwing an exception, etc.) +  * 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 (unless such arguments commonly are supplied by the external user in typical code - e.g. bug in input sanitizing functions).  +  * requires invocation of functions with specific arguments, which may be valid but are obviously malicious 
-  * requires specific actions to be performed on the server to trigger it, which is not commonly performed and is not commonly accessible to the remote user+  * 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 privileges superior to that of the user (uid) executing PHP
   * requires the use of debugging facilities - ex. xdebug, var_dump   * 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 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 environment variables - ex. USE_ZEND_ALLOC
-  * requires the use of non-standard builds+  * 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 code or settings known to be insecure
 +  * requires the use of FFI
 +  * requires an open_basedir bypass
 +
  
 ====== Handling issues ====== ====== Handling issues ======
Line 83: Line 88:
  
 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.  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 ====== ====== FAQ ======
  
 Q. How do I report a security issue?\\ Q. How do I report a security issue?\\
-A. Please report it on http://bugs.php.net, 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 PHP security issue that is not exactly a bug report, please write to security@php.net. +A. Please report it on http://bugs.php.net, 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 PHP security issue that is not exactly a bug report, please write to security@php.net. You can also submit a security report on Github: https://github.com/php/php-src/security/advisories/new
  
 Q. What do you consider a responsible disclosure?\\ Q. What do you consider a responsible disclosure?\\
security.1478869192.txt.gz · Last modified: 2017/09/22 13:28 (external edit)