Bug #28089 Combination of FEDERATED and EVENTs allows for self-replicating worm

• Submitted: 25 Apr 2007 9:35
• Modified: 26 Apr 2007 15:46
• Reporter: Beat Vontobel (Silver Quality Contributor) (OCA)
• Status: Not a Bug
• Category: MySQL Server: General
• Severity: S2 (Serious)
• Version: 5.1
• OS: Any
• CPU Architecture: Any
• Tags: events, federated, Security, worm

[25 Apr 2007 9:35] Beat Vontobel

Description:
The combination of FEDERATED tables and EVENTs makes it possible to code a worm in pure SQL. A MySQL worm is basically just a stored routine that scans the Internet for other MySQL servers by creating FEDERATED tables against random host addresses (or maybe with a more clever pattern than random selection). It has to guess administrative accounts (user name and password) with brute force attacks, which could be implemented quite efficiently in a stored routine. As soon as it gets access to a remote server, the worm inserts its own code into the mysql.event table there and schedules itself for execution.

While maybe not considered an actual security hole (the worm has to abuse weakly protected accounts and servers), it could still present a threat once 5.1 will be in wide deployment.

How to repeat:
n/a
(see http://www.futhark.ch/mysql/150.html for a more detailed description)

Suggested fix:
The FEDERATED storage engine could actually be patched to just disallow any connections to mysql.event tables (and probably the other system tables as well). This would be a restriction that shouldn't be too limiting for users.

Other fixes seem more difficult: The usual place to actually counter such an attack would be on the targeted server. But that server has actually no idea it's federated to. A connection from a federating server just looks like any other connection from an ordinary client. And you don't want to restrict those other client's possibility to schedule EVENTs.

Of course everything would be solved if the mysql.event table wouldn't be exposed as a table at all and EVENTs could only be scheduled through the dedicated commands to which a federated table has no access. But this would make it much harder to take backups of scheduler settings.

[26 Apr 2007 15:46] Giuseppe Maxia

Thanks for this report.
From your description, for the "worm" to work, the following facts must happen:

1. the DBA has to create a global user with access to the mysql database;
2. the above user must be given grants to connect from anywhere
3. the user must be given a guessable username and password.
4. and, of course, the above facts must be in combination with the events being enabled.

If the above conditions are fulfilled, the worm is theoretically feasible, assuming that there are enough careless (suicidal?) users who are willingly exposing their credentials to the web.

However, the same would be true for any application that accepts connections across the network. Using the same principle, you could write a shell script "worm" that exploits Linux installations with "root/root" username and password combinations. You could scan the internet looking for this combination to be exploited, and you may succeed, but you don't hold accountable Ubuntu or Fedora for it.

Similarly, MySQL can't be blamed for the possibility of users weakening their system. If the described scenario were exploitable with MySQL default setup, then you would have a point. But the default setup won't allow access to the mysql database across the network.

Therefore, much as I agree that this scenario has some tiny chances to be exploited, that can happen due to people taking some explicit self-damaging action.