Requesting ports-secteam@ be added to this, in addition to the port maintainer.
The database/mariadb*-server ports contain quite a list of CVEs in vuxml, many of which are bogus, and others which are missing. I believe the former is caused by an assumption being made by someone (not necessarily the port maintainer!) that (Oracle) MySQL vulnerabilities affect MariaDB. That isn't the case; each CVE must be reviewed on a case-by-case basis.
To help with that, I'll provide this:
The MariaDB folks maintain two web pages, and have for a while, that document CVEs MariaDB is affected by: https://mariadb.com/kb/en/library/security/
...and Oracle MysQL CVEs that *do not* apply to MariaDB: https://mariadb.com/kb/en/library/security-vulnerabilities-in-oracle-mysql-that-did-not-exist-in-mariadb/
Let's review what vuxml says for determine which of them in the list are legit vs. bogus based on those pages. Per pkg audit as of 2018/11/08 @ 01:20 PST/UTC-0800 with investigative results inline, done per port/pkg:
$ pkg audit mariadb102-server-10.2.18
mariadb102-server-10.2.18 is vulnerable:
MySQL -- multiple vulnerabilities
CVE: CVE-2018-3286 -- bogus
CVE: CVE-2018-3283 -- bogus
CVE: CVE-2018-3284 -- legitimate
CVE: CVE-2018-3282 -- legitimate
CVE: CVE-2018-3279 -- bogus
CVE: CVE-2018-3278 -- bogus
CVE: CVE-2018-3161 -- bogus
CVE: CVE-2018-3186 -- bogus
CVE: CVE-2018-3280 -- bogus
CVE: CVE-2018-3212 -- bogus
CVE: CVE-2018-3170 -- bogus
CVE: CVE-2018-3200 -- legitimate
CVE: CVE-2018-3173 -- legitimate
CVE: CVE-2018-3162 -- legitimate
CVE: CVE-2018-3277 -- legitimate
CVE: CVE-2018-3171 -- bogus
CVE: CVE-2018-3174 -- legitimate
CVE: CVE-2018-3187 -- bogus
CVE: CVE-2018-3247 -- bogus
CVE: CVE-2018-3195 -- bogus
CVE: CVE-2018-3185 -- legitimate
CVE: CVE-2018-3144 -- bogus
CVE: CVE-2018-3145 -- bogus
CVE: CVE-2018-3133 -- incorrect; fixed as of 10.2.13
CVE: CVE-2018-3203 -- bogus
CVE: CVE-2018-3137 -- bogus
CVE: CVE-2018-3182 -- bogus
CVE: CVE-2018-3251 -- legitimate
CVE: CVE-2018-3156 -- legitimate
CVE: CVE-2018-3143 -- legitimate
CVE: CVE-2018-3155 -- bogus
CVE: CVE-2016-9843 -- legitimate
- 19 of 32 are bogus / do not apply to MariaDB
- 1 of 32 is outdated (was fixed as of 10.2.13)
- 12 of 32 are confirmed (and fixed in the newer 10.2.19)
$ pkg audit mariadb102-server-10.3.10
0 problem(s) in the installed packages found.
This is inaccurate. There are several CVEs which exist in 10.3.10 (fixed in 10.3.11) that should be showing up here, such as CVE-2018-3143, CVE-2018-3156, etc.. What's strange: those CVEs show up for mariadb102-server but not mariadb1013-server.
$ pkg audit mariadb102-server-10.1.37
The situation here is dire: results are split across 6 completely separate vuxml sections, for a total of 151 CVEs. However, at least one (CVE-2016-9843) is bogus for that release of MariaDB, which makes me think there are probably others.
Can these situations be rectified to reflect reality?
(In reply to Jeremy Chadwick from comment #0)
Thanks for the feedback. You'll find that it is usually me who commits these vuxml entries. I commit these knowing that they are inaccurate for MariaDB, but also for MySQL versions (not all vulnerabilities are found in all versions). At the time of publishing, by Oracle, of the vulnerabilities, there is no information on MariaDB. History tells me the "current" versions of MariaDB will be vulnerable too unless they were just released, these latter ones get the info added to the release notes after the vulnerabilities are published.
I'm curious to learn how you've come to the conclusion about 10.3.10. I was (am) expecting that 10.3.11 contains fixes to vulnerabilities but I only find out when MariaDB releases this information in the release notes. If you have a source that provides this information earlier, I'd be happy to adapt.
UPDATE: they are available today by guessing the URL but weren't earlier, the 10.3.11 release is planned for over a week. Expect an update to the vuxml entry shortly.
If ports-secteam advises to use separate vuxml entries for MariaDB and MySQL, and potentially different vuxml entries for different versions, I will try to keep up for MariaDB but will stop creating entries for MySQL and Percona (too much work). Additionally this will mean that MariaDB users will be informed about vulnerabilities considerably later, when MariaDB releases the next version.
A commit references this bug:
Date: Thu Nov 8 17:29:07 UTC 2018
New revision: 484465
security/vuxml: Mark MariaDB 10.3.10 vulnerable
- From MariaDB release notes (not released yet)
Re: 1st paragraph: no guesswork is needed: the links I gave in comment #0 clearly denote which MariaDB versions are affected (or not affected) by what CVEs, including the MariaDB version number in which the CVE was fixed. This information should help with the vuxml entries (which use version ranges, IIRC).
Re: 2nd paragraph: please see https://mariadb.com/kb/en/library/security/ , section "Full List of CVEs fixed in MariaDB". The CVEs are listed, alongside the version of MariaDB in which the CVE in question was fixed. That's how I know. :-)
Re: 3rd paragraph: there will always be some amount of delay or "outdatedness" due to how the CVE impact is provided by the MariaDB folks. Sadly they don't have a mailing list for security issues (their announce@ and maria-discuss@ lists don't seem to have this stuff either), thus the only way to know if a CVE is truly affects/doesn't affect MariaDB is by looking at the aforementioned pages periodically. That's just the nature of the beast, and not your fault in the least.
(In reply to Jeremy Chadwick from comment #3)
Until further guidance is provided by ports-secteam and more timely information is provided by MariaDB there will be no further action from me re. this PR.