Percona Server being downstream of Oracle MySQL (as well as PXC) it makes sense that this would mirror upstream by default (and yes if you enabled local_infile and re-run the tests they are vulnerable to this issue, however what I have highlighted in this post is the default OTB state of each fork and version tested).

There’s no intent to paint Percona Server nor PXC in a positive light, had they been vulnerable by default this would have been noted here regardless, we do not (and should not) show bias to even our own products at Percona.

The difference here was MariaDB was allowing local_infile by default, there should now be workaround fix in place such that if there is no SQL statement issues which would require the server to send the file request packet, if a packet is received it is instead ignored (as noted from MariaDB to myself in email).

w.r.t rogue_mysql_server.py I’d suggest such discrepancies were intentional to ensure only those whom understand the protocol can re-arm the rogue_mysql_server to achieve the desired result, as stated I am waiting on response from a fork at this time and can not go into much detail at the moment on this.

w.r.t the disabling of local_infile; and the vulnerabilities of enabling it again, that is true and for the record I personally think MariaDB has the best proposed workaround here in having the client respond only if SQL is known to have been issued with LOAD … and ignore all other requests if this has not been the case.

_if_ you compile from source and ensure that local_infile support is disabled, and this fits your use case in your deployments, excellent; of course this will protect against this particular issue.

However you have to weigh this against maintaining your own builds for future releases which patch other security vulnerabilities.

The analysis here has been intended to cover all forks, not to paint one or another more or less favourably by any means.

There is a bug in the rogue_mysql_server.py implementation which underspecifies the salt in the handshake packet which may explain this discrepancy.

1) The ‘feature abuse’occurs in the client handling of the INFILE packet request from the server, this is made clear in the network flows which unfortunately are redacted at this moment in time, once we’ve had response from the one fork whim has not provided indicate they have made an appropriate response or Feb 28th is reached I will update this post with the redacted detail in line this will provide more clarity on where the abuse / exploitation occurs. As the SQL issues by the client is ignored, the client need not actually send a LOAD XML / LOAD DATA … the malicious server will always just respond with the file request packet and where local_infile is enabled the client will respond with the file contents if accessible. I’ve taken this approach to ensure responsible disclosure practises are followed the rest of this content however is already in the public domain, hence this post has been released with this detail adding testing and mitigation recomendations.

2) This was added as a consideration based on feedback from one of our dev leads, this consideration was for the fix only I’ll follow up with them and query this. As noted in post and in response above, the exploitation ocurrs when the client has local_infile enabled, it will always respond with the file contents if accessible; this allows the ‘server’ to send the packet in responds to any SQL sent in testing.