I reviewed mariadb 1:11.8.3-1build1 as checked into resolute. This
shouldn't be considered a full audit but rather a quick gauge of
maintainability.
mariadb is a relational database solution designed as a drop-in replacement
for MySQL with more features, new storage engines, fewer bugs, and better
performance.
- CVE History
- A lot of CVEs
- 242 in the `mariadb` package. This only amounts to CVEs from 2023
as the `mariadb` package was introduced around that time, and was
packaged individually with appended version beforehand.
- Many of these CVEs affect MySQL and were subsequently also assigned
to `mariadb`. Most of these CVEs would need to be properly triaged to
see whether they affect `mariadb` as well. Other distribution's
trackers don't target `mariadb` for MySQL CVEs.
- MySQL upstream does not reference commits to CVEs, and with many
changes between versions triaging those vulnerabilities is rather
tedious. Due to this, Ubuntu usually updates the package version
to fix vulnerabilities instead of backporting specific commits.
- `mariadb` upstream has a comprehensive web page that lists all CVEs
that affect MySQL but not `mariadb`. This could be used to triage
these CVEs for Ubuntu
-
https://mariadb.com/docs/server/security/securing-mariadb/security-vulnerabilities-in-oracle-mysql-that-did-not-exist-in-mariadb
- A few examples:
- CVE-2025-53042
- CVE-2025-50100
- CVE-2024-21142
- CVE-2024-20967
- CVE-2024-21238
- For CVEs that specifically affect MariaDB (such as `CVE-2023-52970`
or `CVE-2023-52971`), `mariadb` upstream references the internal bug
tracking issue as part of the CVE, which many times contains the
patch to fix the issue, or references a commit/github pull request.
- For CVEs that do end up affecting both MySQL and MariaDB, getting the
specific patches seems to be significantly harder, as the internal
bug tracker does not link issues with CVEs. Issues could be
identified with the patch notes, as those provide a list of security
fixes with a brief description and the bug link, but no CVE entry in
this case either, so there would be need to try to match each brief
description with the CVE description and try to guess which issue
references which CVE.
- It would be great if there was an overall easier way of obtaining
patches, and that the CVEs were linked not just with the internal
tracker but also with the respective commit that fixed the issue.
Currently it is an improvement over MySQL, but it is still cumbersome.
- For newer releases using the same approach as MySQL and updating
specific versions still supported by MariaDB would be valid, but as
Ubuntu releases are now supported for 15 years which far outweighs
the community support of MariaDB of ~3 years, backporting patches
would become necessary.
- Build-Depends
- Normal build depends.
- pre/post inst/rm scripts
- A few pre/post inst/rm scripts
- preinst
- ./mariadb-server.preinst
- Manages upgrades/downgrades/installs by stopping service if
running, checking previous installations, creating default user
and group to not run as root, etc. Looks fine.
- ./mariadb-common.preinst
- Small script to handle a specific version upgrade (for config
incompatibility between a new and old version). Looks fine.
- postinst
- ./mariadb-server.postinst
- Manages init.d files (if they exist), restores some symlink
updates made by preinit script, sets permissions to files by
managing ownership with the new default user. Looks fine.
- ./mariadb-common.postinst
- Small script for managing symlinks. Looks fine.
- ./mariadb-plugin-mroonga.postinst
- One line script to install "Mroonga". Looks fine.
- prerm
- ./mariadb-plugin-mroonga.prerm
- One line script to uninstall "Mroonga". Looks fine.
- postrm
- ./mariadb-server.postrm
- General install cleanup, removing logs, removing users, and
removing files in /var/lib/mysql. Looks fine.
- ./mariadb-common.postrm
- Seems to remove a previously set symlink. Looks fine.
- These scripts have very comprehensive comments which is very much
appreciated. Overall they look good.
- init scripts
- ./etc/init.d/mariadb
- systemd units
- ./usr/lib/systemd/system/mariadb-extra.socket
- ./usr/lib/systemd/system/[email protected]
- ./usr/lib/systemd/system/mariadb.service
- ./usr/lib/systemd/system/mariadb.socket
- ./usr/lib/systemd/system/[email protected]
- ./usr/lib/systemd/system/[email protected]
-
./usr/lib/systemd/system/[email protected]/use_galera_new_cluster.conf
- ./usr/lib/systemd/system/mysql.service -> mariadb.service
- ./usr/lib/systemd/system/mysqld.service -> mariadb.service
- The systemd service seems to be well commented, and runs with the mysql
user. However, running `systemd-analyze security mariadb.service` gives
a score of 8.8.
- Further hardening would be appreciated; for example, with
`CapabilityBoundingSet`.
- dbus services
- None
- setuid binaries
- None
- binaries in PATH
- Quite a few, with many symlinks for mysql commands to mariadb ones.
- All seem to be in bin and not sbin except for the main `mariadb`
executable
- ./usr/sbin/mariadbd
- ./usr/sbin/mysqld -> mariadbd
- sudo fragments
- None
- polkit files
- None
- udev rules
- None
- unit tests / autopkgtests
- Has a very extensive unit test suite (1160 tests).
- Also an extensive autopkgtests suite.
- cron jobs
- None
- Build logs
- A few warnings, don't look concerning.
- Processes spawned
- A few processes spawned, like execlp. Upstream also seems to overload
exec as an internal class function.
- Seems fine.
- Memory management
- Upstream has an internal malloc implementation called `my_malloc` with
some safety checks. This is used throughout the project.
- Seems fine.
- File IO
- Same with memory management, `my_open` internal implementation.
- Seems fine.
- Logging
- Seems fine.
- Environment variable usage
- Seems fine. Uses internal mariadb/mysql environmental variables that
start with `MYSQL_` or `MARIADB_`.
- Use of privileged functions
- Uses setreuid(0, 0) in `auth_pam_tool.c` file and other `setreuid`
calls in mysqld.cc.
- Seems fine.
- Use of cryptography / random number sources etc
- Uses SSL/TLS.
- Supports either OpenSSL or GnuTLS. Ubuntu version seems to use OpenSSL.
- Seems fine.
- Use of temp files
- Seems fine.
- Use of networking
- Seems fine.
- Use of WebKit
- None
- Use of PolicyKit
- None
- Any significant cppcheck results
- 731 warnings from cppcheck.
- Around half are from test code. Overall, no true positives were
detected, and it seems like many detections came from wrong build
options from the tool such as uninitialized variables/unknown macros
which are otherwise initialized/known.
- Any significant Coverity results
- Coverity identified 4376 defects.
- It is important to note that upstream has access to Coverity, and
performs semi-regular scanning.
- Mostly false positives and small issues. For example, complaining
about left shifting more than 31 bits, but it is always limited to
6 at most due to earlier checks.
- At the same time, due to upstream already performing Coverity
scanning and the general reputability of the MariaDB project, not
a lot of emphasis went into checking all of the results due to the
size of the project and time availability.
- Any significant shellcheck results
- None
- Any significant bandit results
- Some subprocess calls with `shell=True` were identified in rocksdb, as
well as some os.system calls, which are generally heavily discouraged
as they can allow os injection attacks from user controlled input.
- storage/rocksdb/myrocks_hotbackup.py
- This seems to call `os.system` with a tar command, as well as a
file name. This is used through MySQLBackup.
- An injection attack could be possible if file creation can be
controlled during the backup process.
- storage/rocksdb/rocksdb/buckifier/util.py
- This is a function wrapper around the subprocess.Popen called
"run_shell_command". Doesn't seem to be used in the code.
- storage/rocksdb/rocksdb/build_tools/precommit_checker.py
- Seems to run tests before commit by passing commands to the
subprocess shell
- Commands obtained through build_tools/rocksdb-lego-determinator
- Also replaces some env variables if J env variable is present
- storage/rocksdb/rocksdb/tools/advisor/advisor/db_bench_runner.py
- Seems to be done as a benchmark runner, where commands are ran as
part of experiments.
- storage/rocksdb/rocksdb/tools/advisor/advisor/db_stats_fetcher.py
- Seems to display some rocksdb stats from logs, which contains a
wrapper for command execution.
- storage/rocksdb/rocksdb/tools/write_stress_runner.py
- Executes some write stress tests. The command also does not have
user input at any point.
- Overall, they seem to be limited to testing functionality, however,
this cannot be said with certainty.
- Any significant govulncheck results
- N/A
- Any significant Semgrep results
- Nothing relevant, some `strtok` usages instead of `strtok_r` but ouside
of threads, and many detections in test code/docs. Also repeat of
`shell=True` from bandit.
The code seems clean and maintainable, and the upstream is very reputable,
which gives confidence in the project. While he handling of security issues
is also better than MySQL, there is still room for improvement, especially
when it comes to vulnerability tracking with specific commit fixes in the
MySQL specific CVEs that also happen to affect MariaDB.
The package has an extensive testing suite (both at build time and
autopkgtest), but there are a few pendings issues. While the systemd
hardening would be appreciated but is not required, the mariadb package has
apparmor profiles disabled by packaging an empty profile:
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/apparmor-profile
It has been around 6 years since the decision was made, and while no
mariadb-specific profile exists for Ubuntu, since then the mysql profile
has been improved and has been demonstrated to not be an undue burden in
practice. Moving this package to main seems to be an ideal time to reassess
and hopefully improve the system confinement.
Security team ACK for promoting mariadb to main, given that the apparmor
profile change is reassessed or proper reasoning is provided.
** CVE added: https://cve.org/CVERecord?id=CVE-2023-52970
** CVE added: https://cve.org/CVERecord?id=CVE-2023-52971
** CVE added: https://cve.org/CVERecord?id=CVE-2024-20967
** CVE added: https://cve.org/CVERecord?id=CVE-2024-21142
** CVE added: https://cve.org/CVERecord?id=CVE-2024-21238
** CVE added: https://cve.org/CVERecord?id=CVE-2025-50100
** CVE added: https://cve.org/CVERecord?id=CVE-2025-53042
** Changed in: mariadb (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
** Changed in: mariadb (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2122095
Title:
[MIR] mariadb
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mariadb/+bug/2122095/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
