Security_Of_phpMyAdmin

A web application like phpMyAdmin can be vulnerable to a number of attacks. Even though the team does it's best to code securely things happen...we're human.

Please see our documentation for more details on security policy and usual types of vulnerabilities:

https://docs.phpmyadmin.net/en/latest/security.html

On this page we try to differentiate between the different threats. And explain how phpMyAdmin sees these.

Think you have found an issue, please contact the security team via security@phpmyadmin.net

When are security updates released?

When notified of a problem the security team does it's best to quickly come up with a patch.

TODO: specify the levels we also use in advisories

Critical

For critical issues it can be necessary to immediately make a release.

These releases usually contain only security fixes and use four digit version number (such as 4.8.0.1).

Minor

When an issue is deemed minor no special release is made, the fix will be included in the next stable release. The Changelog would describe the fix and should include the [security] prefix.

Process

The security coordinator

• is the official voice of communication for security issues
  • acknowledges issues with the reporters
  • requests CVE ids
  • communicates the outcome to the reporters when fixes are released
• ensures that all issues have been answered

The security team

• communicates on the private security mailing list only
• verifies issues
• prepares and test fixes
• discusses the target version for fixes

PGP handling

• every security member has access to shared PGP key
• reporters can encrypt reports to make them secret
• the PGP key is sent to every member encrypted
• every member of security team is expected to sign this key and publish the signature on keyservers

Tracking issues

Tracking of security issues happens in the phpmyadmin-security repository:

• Every issue is created once the report is received
• Anybody working on that can assign it to himself
• The issue is assigned labels according to release which need fixes (eg. 4.6.x)
• Once it is clear we need PMASA for this issue, it gets pmasa needed label
• Once the issue is fixed in the security repos (all branches), it gets resolved label
• Once PMASA is written, it's number is written at the end of summary, linked from the issue comment and label pmasa needed is removed
• Once the security release is out, the issue is closed

The tracker is here: https://github.com/phpmyadmin/phpmyadmin-security/issues

Preparing fixes

Preparation takes place in the Git_Security repository, and is internally communicated via the security mailinglist.

If a security team member wishes to submit a pull request before merging the changes, the process is to create and push a new branch to the security repository, then create the pull request inside the repository from that private branch. This way, the changes aren't revealed before the security issue is made public.

• Add separate commit to every affected (and supported) branch (usually bunch of older MAINT_*-security and last QA_*-security).
• Merge the latest QA_*-security branch with fix to master-security (this is especially needed with intrusive fixes or things which have meanwhile changed in master to ensure we have master branch ready with all the fixes at time of release).

Preparing a PMASA

See the template guide in PMASA for details. The PMASA should be drafted and reviewed by several security team members for accuracy, then published when a new phpMyAdmin release occurs.

Obtaining CVE ID

If the issue has not yet assigned CVE ID, the security coordinator will ask for one by submitting through the MITRE CVE web form at https://cve.mitre.org/cve/request_id.html

The web form has several questions that we should attempt to answer consistently.

• Contact email address: the security submission email list
• Product name: phpMyAdmin
• Vendor name: phpMyAdmin
• Version affected: example: "4.0.10.17 and older, 4.4.15.8 and older, 4.6.4 and older"
• Version fixed: example: 4.0.10.18, 4.4.15.9, 4.6.5

Preparing for release

If the issue is not yet disclosed, the release date and possible references should be checked with reporter.

A reporter might want to include his name or company name together with a link in PMASA, which should be honored (so long as they responsibly disclose the vulnerability privately).

Releasing and disclosing

Once all changes are ready, they are pushed to public repository together with PMASA announcements and standard release process follows, see Releasing for more details.

Category:Security Category:Devel