MariaDB
MariaDB Server is one of the most popular open source database servers in the world. It is developed and maintained by the original developers of MySQL and guaranteed to stay open source.
The MariaDB Foundation supports continuity and open collaboration in the MariaDB ecosystem. The Foundation guarantees that there is a global contact point for collaboration and that the community can always rely upon MariaDB Server.
The Foundation is committed to working with security experts to stay up to date with the latest security techniques and towards the security of your database deployments. Feel free to inspect, analyze and fuzz our source code as you wish. If you discovered a security issue in either research or production that you believe we should know about, please let us know via responsible disclosure and we'll make every effort to quickly correct the issue following a vulnerability handling process that is respectful and considerate to you, all users, partners, companies and forks of MariaDB. If you'd like to bring additional attention to a report or feel we can improve with our report handling please let us know at security@mariadb.org.
A note on upstream MySQL and third party storage engines,
MySQL, which is the base of MariaDB, is a product and trademark of Oracle Corporation, Inc. MariaDB is a fork of MySQL and the Foundation is committed to keeping MariaDB on par and go beyond feature, security, performance and reliability wise, as well as keep drop-in compatibility to the best of our efforts for certain branches. This implies that some security issues could originate in the upstream source code before the initial fork, or be introduced later via a subsequent merge, in which case our biggest priority is to resolve the issue for MariaDB users as quickly and responsibly as possible and at the same time report upstream if applicable. We can report the vulnerability to Oracle on your behalf, unless you prefer to do it yourself. However, if you report it only to Oracle, we will never know about it and might never fix it.
Also, MariaDB, in the default source offering, incorporates various third party open source modules, for example, Storage Engines that provide different backend store facilities with focus on performance, efficiency, or scaling. Examples include TokuDB, XtraDB from Percona, and MyRocks originally from Facebook. If your report specifically targets one of those third party modules that is part of the original MariaDB source offering, we encourage you to report it to us, in which case, our biggest priority is to resolve the issue for MariaDB users quickly and responsibly and at the same time notify and collaborate with the original upstream source to mitigate risk and develop a resolution that has the widest outreach possible.
If you are unsure of the scope of your vulnerability report, don't worry too much about it, just make sure you are following the responsible disclosure guidelines and we will get in touch with you about the classification and scope specifics upon verification and validation of the report. In either case, you will be kept in the loop for the entire life-time of the disclosure and handling process.
MariaDB is a server product used in both public and private environments, with a wide reach ranging from being the default database system on Debian flavored distributions and availability in most other Linux and BSD package repositories, to corporate, enterprise and governmental deployments, to supplying database needs for many internet sites and services, and ultimately to being the go-to choice for many personal individuals all around the globe. To that end we strongly encourage you to follow the responsible disclosure philosophy and guidelines when stumbling across vulnerabilities in critical infrastructure software, MariaDB included.
A quick summary of the rules defining responsible disclosure:
You must be the first reporter of the vulnerability to be eligible for recognition. Please check our bug database prior to classifying it as a new issue.
The vulnerability must demonstrate security impact, either implicitly or explicitly. You must be available for further clarification, detail requests from our security team and developers. See Report Eligibility section.
You must not publicly disclose the vulnerability, nor privately to another third party, prior to the report being resolved in a reasonable manner, in compliance with the process described in the HackerOne Vulnerability Disclosure Guidelines and terms in this document. As an exception to this rule, you may disclose it to Oracle and Percona security contacts. If you prefer not to do it and we discover that other MySQL variants are affected, we will notify them on your behalf.
Share the security issue with us in detail; See Bug Report section.
You agree with the public disclosure of any valid security issue reported to us pending resolution.
Submitter must not be the author of the vulnerable code nor otherwise involved in its contribution to the MariaDB project (such as by providing code/PR/merge reviews). Employees of the Foundation and its subsidiaries, affiliate companies are ineligible.
Act in good faith to avoid privacy violations, destruction of data, and interruption or degradation of services (including denial of service) for us and our users at large and comply with all applicable laws.
You must agree and comply to our stated Policy and implicit HackerOne program rules.
We will respond as quickly as possible to your initial submission.
Pending our ability to reproduce your findings, we will evaluate the severity of the report, affected products and releases and get back to you with our dissemination.
We will coordinate together towards fashioning a reasonable vulnerability fix timeline that is knowledgeable and respectful of all parties affected by the issue.
We will notify other MySQL variants on your behalf if we determine that they are also affected by the vulnerability.
We will draft a security advisory, public announcement, and urge users to upgrade accordingly. At this stage you will also receive public recognition (at your discretion).
We will commit to post-resolution future-proofing mitigation activities, such as identification of the original cause of the defect that made this possible in the first place, creating test suites and pro-actively looking for further similar class vulnerabilities that we can readily identify via our Continuous Integration and Testing platform.
We will keep you updated as we work throughout this entire process. You can be part of this at all stages.
A good vulnerability bug report should include at least the following information:
The environment (operating system, hardware and MariaDB version, including plugins and storage engines).
Code affected, along with your explanation of the faulty behavior.
Configuration, SQL tables, queries, network actions required to reproduce the behavior.
Core dumps, stack-traces, error logs, data dumps, failed test cases or network packets required to diagnose or reproduce the attack.
Proof of Concept (PoC) code that successfully triggers/exploits the vulnerability in at least one given scenario.
In gist, vulnerability reports need to be documented in a way that they can be reproduced, easily understood and classified by our developers without duplicating everything you did already from scratch. The more details you send in, the easier it is for our developers to rely on the effort already put in by you and act faster. Send screen-shots, code, video; whatever helps to understand the flaw as quickly as possible.
For details on how to submit a comprehensive bug report that's specifically tailored to MariaDB see Bug Reporting in our Knowledge Base.
Due to the nature of our client-server protocol, replication technologies, plugin system, and overall architecture of MariaDB sever and deployment specifics, there are a variety of forms that a security vulnerability can take, so in order to simplify our classification of reports for eligibility, we try and base our evaluations on a combination of risk, impact, exposure and common sense to evaluate severity for a particular vulnerability report and the threat posed to users. It is considered a good practice to assess any particular vulnerability using the Common Vulnerability Scoring System CVSS3 standard in order to easily come up with a metric that can be easily understood and shared by many in the industry.
Unless otherwise stated by the MariaDB security team, pending completion of report evaluation and analysis, we currently consider this classification for qualifying vulnerabilities:
Security vulnerabilities in active development branches and released versions that are still in the supported timeline, such as:
Gaining unauthorized remote code execution on the server, slave or client machine (i.e. RCE).
Database authentication bypass, privilege escalation and other access control bypass attacks.
Data corruption attacks that affect the integrity of the database without authentication or privileges to do that normally.
Data exfiltration attacks that affect the confidentiality of the database without authorization to do that normally.
Denial of Service (DoS) attacks that permanently corrupt the server state or configuration, preventing the user from easily restarting the service, thus resulting in total loss of availability.
Vulnerabilities in clients or connectors (only those, available from https://downloads.mariadb.org/).
Vulnerabilities that don't lead to a severe compromise of the server, data and information leakage or privilege escalation, but do affect normal operation, up-time and service reliability are considered of limited scope:
In addition to the main product offerings of MariaDB, we are also considering critical security issues in our website, support, development, testing and release infrastructure that could potentially affect end users of MariaDB server as part of this policy and in limited scope. Examples could be server side attacks that lead to binary release distribution integrity corruption or web attacks that could lead to serious compromise of our infrastructure, such as:
Cross Site Scripting (XSS)
Cross Site Request Forgery (CSRF)
Server Side Request Forgery (SSRF)
Remote Code Execution (RCE)
SQL Injection (SQLi)
Please, note, MariaDB Foundation is a non-profit organization with limited resources and while we do our best to keep everything up to date and secure, there's still the chance that some underused service, daemon or forgotten installation might gradually slide down the path of irrelevance and obsoleteness and thus, potentially expose us to attacks. If you happen to find such problems in our infrastructure, please notify us first. We will be grateful and acknowledge you with thanks on HackerOne at least.
Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder or the Foundation. Engaging in a full-blown penetration test of our infrastructure and live systems without a prior agreement from the Foundation is especially prohibited. If you're planning to look for vulnerabilities in our infrastructure, we'd like to ask you to refrain from:
Denial of service
Spamming
Social engineering (including phishing) of MariaDB staff or contractors
Any physical attempts against MariaDB property or data centers
Automated scans and evaluations that can impair the functionality of our services
Vulnerabilities in old, unmaintained versions of MariaDB.
Vulnerabilities that have already been submitted by another user and/or that we are already aware of.
Vulnerabilities in third-party modules, connectors, and clients that are not available from https://downloads.mariadb.org/.
Files located at: https://jira.mariadb.org/secure/attachment/
Note that this Hacker One program is run by the MariaDB Foundation. Any issues related to the MariaDB Corporation (mariadb.com) are out of scope.
If you're in doubt, feel free to report it anyway or e-mail us at security@mariadb.org.
The MariaDB Server developers classify all security vulnerabilities according to their threat level and thus handle them with the appropriate consideration. The threat level can be one of:
CRITICAL: an exploitable vulnerability that causes arbitrary code execution or allows an unauthenticated user to crash the server or get access to the data.
MEDIUM: everything else.
We promise to fix any CRITICAL security vulnerability immediately, usually within hours, and release fixed MariaDB binaries as soon as possible, usually the next day.
We will fix MEDIUM security vulnerability as soon as possible, but we will not change our planned release schedule to get the fix out earlier.
The MariaDB Foundation security policy at https://mariadb.org/about/security-policy/
| Scope Type | Scope Name |
|---|---|
| undefined | MariaDB Server & Connectors - Remote Code Execution |
| undefined | MariaDB Server & Connectors - Access control bypass |
| undefined | MariaDB Server & Connectors - Data corruption, exfiltration, disclosure |
| undefined | MariaDB Server & Connectors - Denial of Service |
| web_application | mariadb.org |
This program feature scope type like web_application, undefined.
FireBounty © 2015-2024
