mariadb is vulnerable to CVE-2021-27928 (RCE)

CVE-2021-27928 04:15

A remote code execution issue was discovered in MariaDB 10.2 before

10.2.37, 10.3 before 10.3.28, 10.4 before 10.4.18, and 10.5 before

10.5.9; Percona Server through 2021-03-03; and the wsrep patch through

2021-03-03 for MySQL. An untrusted search path leads to eval injection,

in which a database SUPER user can execute OS commands after modifying

wsrep_provider and wsrep_notify_cmd. NOTE: this does not affect an

Oracle product.

From https://jira.mariadb.org/browse/MDEV-25179it looks like 10.5.9

fixes it for us since we package 10.5.8 currently.

However:

$ ./pre-inst-env guix refresh -l mariadb

Building the following 552 packages would ensure 1047 dependent

packages are rebuilt:

[..]

Is it possible to graft mariadb you think? I am thinking this issue

doesnt need updating of the "lib" output which is what's causing the

high number of dependents AIUI. I am not sure we could actually update

individual outputs right now though. Might be a good idea to split the

packages for the future.

Léo

tags 47257 + security

quit

You need to graft: when building a package, the output hash depends on the inputs, sources and instructions, so even if the content of the lib output does not change, its store path does, leading to a rebuild.

Le 19 mars 2021 06:25:31 GMT-04:00, "Léo Le Bouter via Bug reports for GNU Guix" <bug-guix@gnu.org> a écrit :

(mariadb)[replacement]: Graft.

---

gnu/packages/databases.scm | 33 +++++++++++++++++++++++++++++++++

1 file changed, 33 insertions(+)

I made a patch, please review and push if you think that's OK, I will otherwise

push it myself after some time.

The patch produces some test error, not sure if deterministic, looks related to

networking disabled in build sandboxes, log:

The servers were restarted 778 times

Spent 6689.041 of 234 seconds executing testcases

Failure: Failed 1/2711 tests, 99.96% were successful.

Failing test(s): main.system_mysql_db

The log files in var/log may give you some hint of what went wrong.

If you want to report this error, please read first the documentation

at http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html

969 tests were skipped, 161 by the test itself.

mysql-test-run: *** ERROR: there were failing test cases

Error happened at lib/mtr_report.pm line 687.

mtr_report::mtr_error("there were failing test cases") called at lib/mtr_report.pm line 556

mtr_report::mtr_report_stats("Failure", 1, ARRAY(0x19d75d0), ARRAY(0x1420d08)) called at /tmp/guix-build-mariadb-10.5.9.drv-0/mariadb-10.5.9/mysql-test/mysql-test-run.pl line 586

main::main() called at /tmp/guix-build-mariadb-10.5.9.drv-0/mariadb-10.5.9/mysql-test/mysql-test-run.pl line 387

command "./mtr" "--verbose" "--retry=3" "--testcase-timeout=40" "--suite-timeout=600" "--parallel" "48" "--skip-rpl" "--skip-test-list=unstable-tests" failed with status 1

builder for `/gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv' failed with exit code 1

@ build-failed /gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv - 1 builder for `/gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv' failed with exit code 1

derivation '/gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv' offloaded to 'www.proxmox-2.schmilblick.org' failed: build of `/gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv' failed

build of /gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv failed

View build log at '/var/log/guix/drvs/hk/1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv.bz2'.

guix build: error: build of `/gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv' failed

Léo Le Bouter (1):

gnu: mariadb: Update to 10.5.9 [fixes CVE-2021-27928].

gnu/packages/databases.scm | 33 +++++++++++++++++++++++++++++++++

1 file changed, 33 insertions(+)

--

2.31.0

Hi,

On Fri, 19 Mar 2021 at 11:25, Léo Le Bouter via Bug reports for GNU Guix <bug-guix@gnu.org> wrote:

Instead of grafting, I would fix first check the compatibility between

mariadb and zstd. Because mariadb@10.5.8 does not build with

zstd@1.4.9, at least on my machine.

Other said, I seem better to do this fix as a whole on core-updates

without any graft. Instead of grafting here and there; and not

necessary small changes (zstd from 1.4.4 to 1.4.9, mariadb from 10.5.8

to 10.5.8).

All the best,

simon

Hi Léo,

Léo Le Bouter via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Please don't use 'package/inherit' when the package you're defining is a

replacement to the package you're inheriting from. It creates a package

object with an infinite chain of grafts. I guess that the infinite

chain gets truncated somewhere in the grafting machinery, but I seem to

recall that this kind of thing has caused real problems in the past.

'package/inherit' is usually the right thing when defining other kinds

of package variants, however.

Thanks again for all of your recent work on improving our security. It

is a great help.

Regards,

Mark

Mark H Weaver <mhw@netris.org> writes:

One addendum to this guideline: if the package variant you're defining

overrides the 'source' field[*], it's probably pointless to use

'package/inherit', because the fixes embodied in the original package's

replacement would most likely be lost anyway.

[*] One exception is if the overridden 'source' field merely adds some

additional patches to the original package, while taking care to

preserve any existing patches -- that last part is important, even if

the original package doesn't including any patches at the time you look.

In that case, 'package/inherit' might well be helpful.

More generally, when inheriting from another package, it's useful to ask

yourself what should happen if the package you're inheriting from is

later grafted, and to try to arrange for that to happen automatically.

Thanks,

Mark

(mariadb)[replacement]: Graft.

---

gnu/local.mk | 1 +

gnu/packages/databases.scm | 34 +

.../patches/mariadb-CVE-2021-27928.patch | 629 ++++++++++++++++++

3 files changed, 664 insertions(+)

create mode 100644 gnu/packages/patches/mariadb-CVE-2021-27928.patch

I think you can simplify the patch a bit by inheriting the source too:

(source

(origin

(inherit (package-source mariadb))

(patches …)))

Otherwise, untested but looks good.

On Fri, 2021-03-19 at 12:35 +0100, zimoun wrote:

Can you post build logs and repro scenario? mariadb@10.5.8 built fine

for me on core-updates which has zstd@1.4.9.

We can't patch security issues through core-updates, especially this

RCE.

(mariadb)[replacement]: Graft.

---

gnu/local.mk | 1 +

gnu/packages/databases.scm | 8 +

.../patches/mariadb-CVE-2021-27928.patch | 642 ++++++++++++++++++

3 files changed, 651 insertions(+)

create mode 100644 gnu/packages/patches/mariadb-CVE-2021-27928.patch

v3 tested and builds fine:

$ ./pre-inst-env guix build mariadb

/gnu/store/f70jymwyfcnsghy4jg8caibci59p8rgq-mariadb-10.5.8-dev

/gnu/store/cj3qym1x1jjh02m2g23cqpbhchrbmn6c-mariadb-10.5.8-lib

/gnu/store/mpb5bdf1vkwazqfmmwcvskdm50g191bg-mariadb-10.5.8

Since we don't have PoC, I can't verify the rebased patch actually

fixes the security issue but it should. That's what we get when

manually rebasing stuff to earlier versions. Test suite passes but not

sure it actually tests this security issue being fixed.

Please review, then I will push, it's been 7 days so, let's get this

in.

Léo Le Bouter via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Looks good to me. Please push. Thank you!

Mark

On Thu, 2021-03-25 at 21:16 -0400, Mark H Weaver wrote:

Thank you for the review, pushed as

52c8d07a4f7033534a71ac7efeec21a65d35c125.

On Thu, 25 Mar 2021 at 12:28, Léo Le Bouter <lle-bout@zaclys.net> wrote:

On core-updates, I get this:

Maybe, I am not doing something wrong. Then on master, it "works"

except after the ungraft. Well, it seems coherent with what I get

from core-updates. So if I am doing wrong, I do not know where.

I could be wrong... and I have not investigated more. As I said

elsewhere, grafting zstd from 1.4.4 to 1.4.9 seems totally *wrong*.

There is ~1.5 years and 4 releases between these 2 releases.

BTW, note that:

$ guix graph --path mariadb zstd

guix graph: error: no path from 'mariadb@10.5.8' to 'zstd@1.4.9'

Grafting MariaDB makes sense here. The culprit is zstd, IMHO.

I will not comment because I am bored by all that.

Last, you have been prompted to commit a major update and disable the

test-suite for zstd, and I am still waiting that you are prompt again

to fix it; especially when a proposal fix is done here:

Best regards,

simon

Hello!

Simon,

I pushed 00c67375b17f4a4cfad53399d1918f2e7eba2c7d to core-updates. Your

patch. Thank you for it. Let's watch for upstream zstd fix also.

I pushed 9feef62b73e284e106717a386624d6da90750a3d to master.

Ubuntu released a patch in the mean time, so while we couldnt make such

patch in a timely manner because the backport was non-trivial and

security-sensitive also didnt want to risk failing to fix the flaw

because I don't have much expertise on it, Ubuntu now has done that

work and we can just use it.

Léo

Hi Léo,

On Tue, 30 Mar 2021 at 02:26, Léo Le Bouter <lle-bout@zaclys.net> wrote:

Thanks. It mitigates zstd, even if it does not solve MariaDB. One

foot, then another. :-)

Cool! LTGM.

Thanks for taking care. And do not consider my concerns as a slowdown

but instead as a way to reach something better. For instance

9feef62b73 seems The Right Thing (AFAIU), whereas 6f873731a0 and

2bcfb944bd are not (AFAIK). On one hand, I agree that ~3 weeks

appears long through the lens of security vulnerabilities. On the

other hand, it is usually worth to take the time; as here. :-)

Examine the various options and so the best move always takes time.

Well, thanks for pushing forward with security.

All the best,

simon