Oracle paltry patch opens MySQL man-in-the-middle diddle

It's got a logo and a website: Behold the awesomeness that is BACKRONYM!

Adam Goodman of Duo Security has found a vulnerability in the 'vast majority' of Oracle MySQL databases that allows SSL to be stripped, exposing sensitive data to man-in-the-middle attackers.

Goodman says Oracle attempted to sling a patch at the problem last year but did so only for some versions and further borked the effort by turning the SSL requirement off by default.

Oracle has been contacted for comment.

"Earlier this year, I - along with some members of our DevOps team - noticed some interesting behavior in libmysqlclient and the MySQL CLI: no matter how hard we tried (no matter how many MYSQL_OPT_SSL_* options we set) we could not make the client enforce the use of SSL," Goodman says in a post.

"If the server claimed not to support it, the client would happily communicate over plain old, unencrypted TCP!

"This means that MySQL clients are super-vulnerable to an attack [attackers] can intercept the MySQL server’s handshake packet, unset the flag that says 'I support SSL', and then observe every query and response, or even inject her own!"

The REQUIRE SSL option does not work since attackers can run a "bona-fide" TLS session with servers while communicating to clients in plaintext.

The vulnerability, in line with recent best practice, has been awarded a logo , website, and the name BACKRONYM (Bad Authentication Causes Kritical Risk Over Networks, Yikes MySQL), a tongue-in-cheek overreaching piss-take of a title designed to mock some of named vulnerabilities that have made headlines in recent years.

Despite Goodman's attempt to "maximise PR hype", he says the attack should not inspire dread in most users since an attacker needs to be between the database and client and most database servers are adjacent or on the same box as clients.

But he says the libmysqlclient developer's claim in documentation that man-in-the-middle attacks are prevented is "demonstrably false".

The researcher says attackers can:

  • Unset the CLIENT_SSL flag in the Initial Handshake Packet;

  • Construct an SSL Connection Request Packet from the Handshake Response Packet (i.e. take the first 32 bytes of the Handshake Response Packet, and set the CLIENT_SSL flag);
  • Perform a TLS handshake with the server,
  • Proxy traffic back and forth between the client and server (since the server has seen one more packet than the client, an attacker will also have to increment and decrement packet sequence IDs for a few roundtrips until they reset).


Biting the hand that feeds IT © 1998–2021