An Unprivileged User can crash your MySQL Server

Yes, your read the title correctly: an unprivileged user can crash your MySQL Server.  This applies for the default configuration of MySQL 8.0.21 (and it is probably the case for all MySQL 8 GA versions).  Depending on your configuration, it might also be the case for MySQL 5.7.  This needs malicious intent and a lot of determination, so no need to panic as this will not happen by accident.  I am not sharing the exploit in this post (I might do it later), but I am telling you how to avoid the problem.

Update 2021-12-09: I wrote a follow-up post on this subject: Follow-up on an Unprivileged User can Crash your MySQL Server.

Update 2022-01-19: I published the exploit in a follow-up post: Crashing MySQL with Malicious Intent and a lot of Determination.

The vulnerability is in the Write Set feature of replication.  This feature was introduced for Group Replication and it is also used for improving parallelism identification for Multi-Threaded Slave.  I blogged and talk about these in the past, below are some links:

• MySQL Parallel Replication by Booking.com (FOSDEM 2018)
• The Full MySQL and MariaDB Parallel Replication Tutorial (Percona Live 2018)
• An update on Write Set (parallel replication) bug fix in MySQL 8.0
• Write Set in MySQL 5.7: Group Replication
• More Write Set in MySQL: Group Replication Certification

If you are not using Group Replication, and that you are not using Write Set optimized Parallel Replication, the crashing condition can be avoided by setting transaction_write_set_extraction to OFF.  The default value of this parameter is XXHASH64 in MySQL 8.0, so the standard configuration is vulnerable.  In MySQL 5.7, the default value of this parameter is OFF, so the standard configuration is not vulnerable.

If you are using Group Replication or Write Set optimized Parallel Replication, you need transaction_write_set_extraction to XXHASH64, in which case, an unprivileged user could crash your MySQL server (but as I wrote above, it needs malicious intent and a lot of determination).  The exploit involves crafting a big transaction, so you could proactively kill such transactions to avoid reaching the crashing condition.  Transactions modifying fewer than one million rows should not cause a crash, so normal workloads should not be impacted (I told you exploiting this needs a lot of determination).  And such big transactions are probably also executing for a long time, so killing transactions opened for more than five minutes should also mitigate the problem.  Depending on the maturity of your MySQL installation, you probably already have some sort of query / session killer, so modifying it to kill big or long transactions should not be too complicated.  If you do not have such killer, maybe you should consider implementing one (no need to drop everything to implement a query killer though, I consider the risk of this vulnerability relatively small, and you might have more important things to do than implementing a query killer in a hurry, but this is not a reason not to blog about it).

Some attributions as I am not the person who found this.  It was reported in Bug#101129 by Sergei Fabrichnikov on October 12.  This was brought to my attention in a tweet by Valerii Kravchuk in his MySQL Bug of the Day series.  It is also worth noting that I consider that this bug was not handled properly as it was first classified as "Not a Bug" and later as a feature request, which caused the vulnerability and the exploit to be public for a few days.  The bug then became private between October 15 and 18, so it looks like someone finally took this seriously.

And a few words about why I am blogging about this...  Some are saying that talking about vulnerabilities makes software less secure which I do not agree with as this is security through obscurity.  On the other side, there are people that are in favor of the full disclosure of security vulnerability, which risks making an exploit public while there is no possible mitigation, and this is a bad thing.  I am in the middle and I believe in the responsible disclose of security vulnerabilities.  In the case of the subject of this post, you can see that I do not show how to exploit the vulnerability, and that I give ways to protect your system by avoiding or mitigating the risk.  I think it is important to share these mitigations.  I also think it is important to put the right amount of incentive on software editors to fix vulnerabilities, and the non-disclosure policy prevents that.

That is all for now.  In a few weeks I might publish more details about this vulnerability.

Update 2022-01-19: I published the exploit in a follow-up post: Crashing MySQL with Malicious Intent and a lot of Determination.