back to article Bad news: MySQL can dish out root access to cunning miscreants

Security holes in MySQL can be abused to gain remote root access on poorly configured servers, it emerged on Monday. Patches to fix up the programming blunders were quietly released last week. The flaws are present in all default installations of MySQL 5.5, 5.6 and 5.7. Grab versions 5.5.52, 5.6.33 and 5.7.15 to avoid any …

  1. depicus
    Facepalm

    ....and there's no patch (yet) !!!

  2. Dan 55 Silver badge

    I've got a cunning plan my lord

    If I can get root access, I can overwrite a root-owned config file and upload an evil shared library, and with that I can get root access.

    1. TitterYeNot

      Re: I've got a cunning plan my lord

      "If I can get root access, I can overwrite a root-owned config file and upload an evil shared library, and with that I can get root access."

      <Sighs> This root wouldn't happen to be a turnip would it, Baldrick?

    2. zebthecat

      Re: I've got a cunning plan my lord

      I was wondering that too.

    3. Doctor Syntax Silver badge

      Re: I've got a cunning plan my lord

      According to TFA it can be done via injected SQL so root access might not be needed.

      1. Lee D Silver badge

        Re: I've got a cunning plan my lord

        If you've already uploaded a malicious library that you know the path of, that's in a place where MySQL will load it, and modify the configuration file to point to that malicious library.

        Again, that's a lot of if's.

        1. Anonymous Coward
          Anonymous Coward

          Re: I've got a cunning plan my lord

          On the other hand why on earth does any part of MySQL run as root? I've used several other RDBMSs and no part of them runs as root.

          1. Displacement Activity

            Re: I've got a cunning plan my lord

            > On the other hand why on earth does any part of MySQL run as root?

            > I've used several other RDBMSs and no part of them runs as root.

            For the same reason that everything else runs as root: if you want to listen on a "system" port (less than 1024) then you have to *start* as root. Not just MySQL: MariaDB, all your other RDBMSs, Apache. If you don't want to do this (and why would you?), then don't run mysqld_safe as root.

            Apache normally listens on 80/443, so has to be started as root before it drops privileges. The docs have lots of useful advice on how to protect your system during this time, which cover exactly the issues in this article. The problem isn't that your attacker can load malicious code if they already have root access, it's that they can load malicious code when they're *not* root, which is the cunning plan.

            1. Anonymous Coward
              Anonymous Coward

              Re: I've got a cunning plan my lord

              Aren't you a bit out of date?

              setcap 'cap_net_bind_service=+ep' /path/to/program

  3. Anonymous Coward
    Anonymous Coward

    amusingly

    Hooray for systemd!!

    I think this is much less of a story than people would like it to be.

    Most systems should have moved over to MariaDB anyway.

    1. a_yank_lurker Silver badge

      Re: amusingly

      MariaDB and Percona are drop in replacements for MySQL so it is likely that both could have this bug. So to say MariaDB and Percona users are absolutely safe from this without confirmation from either is, bluntly, idiotic.

      1. Fungus Bob

        Re: amusingly

        Only if the root you seek access to is a turnip.

        1. Pompous Git Silver badge

          Re: amusingly

          Only if the root you seek access to is a turnip.

          What happens if it's a swede?

  4. Spudley

    For those who haven't jumped ship to MariaDB, this kind of thing is a strong incentive to do so.

    Seriously, if a major open source project wants to be taken seriously, an issue like this ought to be patched within days, not months.

    1. phuzz Silver badge
      Gimp

      MariaDB is based on MySQL, and is affected by the exact same bug, so what exactly is the advantage?

    2. batfastad

      Recent versions of MariaDB are diverging away very quickly from the MySQL/Percona/Facebook/WebScaleSQL pack.

      As much as I dislike Oracle, I would stick with Percona or upstream (Oracle MySQL) for now.

      Oracle to be fair has done some outstanding work with MySQL 5.6 and onwards, it just seems like it took a few years for it to be fully Borged.

      How long it will take before it's fully Borked though!

  5. cheekybuddha

    Umm... Hasn't this been patched already?

    https://www.percona.com/blog/2016/09/12/database-affected-cve-2016-6662/

    https://www.psce.com/blog/2016/09/12/how-to-quickly-patch-mysql-server-against-cve-2016-6662/

  6. TrevorH

    mariadb is affected too

    Don't assume that mariadb is immune - it was a fork of mysql and at least some of the vulnerabilities discovered here are also present. Mariadb also helpfully reads $datadir/my.cnf so you can do something similar with it too.

  7. Anonymous Coward
    Linux

    As always...

    Many eyes, all looking at nudie pics

    1. Anonymous Coward
      Anonymous Coward

      Re: As always...

      It's worst than that. It's the Unix outdated permission systems with scripts run as root and software that must drop privileges itself because of lack of a more granular permission system on processes and files. Of course all the downvoters have no clue about a proper permission systems...

      1. Steve Davies 3 Silver badge

        Re: As always...

        Come on then, you know you want to...

        Tell us what OS has proper permission systems?

        I think that there might be several. Z/OS and VMS are two that come to mind.

      2. JulieM

        Re: As always...

        "Proper" fine-grained permissions systems like VMS ACLs are necessarily hard to use, and tend to get about as much use in practice, as a pay toilet in a forest.

        At least the old Unix "me", "my group" and "everyone else" system does get used (most Linux distributions even put each user in their own group), and most of the time it even works reasonably well.

      3. Doctor Syntax Silver badge

        Re: As always...

        "It's the Unix outdated permission systems with scripts run as root and software that must drop privileges itself because of lack of a more granular permission system on processes and files."

        No, it's developers* wanting to run their database engines with root permission when they shouldn't need to. There should be a $DatabaseEngine user and group. They can own the scripts, data and everything else to do with the engine. You're obviously unaware that such setups are not only practical but that they've been in use for decades.

        "Of course all the downvoters have no clue about a proper permission systems."

        No. We're the ones who actually do have a clue. And practical experience.

        *Oracle have been around long enough to know better.

        1. boltar Silver badge

          Re: As always...

          "No, it's developers* wanting to run their database engines with root permission when they shouldn't need to. "

          Not only databases. For reasons no one can fathom , google seems to think its a good idea having the chrome sandbox process running as root on linux. No doubt they think their sandbox code is perfect and has zero security holes but anyone with a clue should install a different browser IMO.

          1. fajensen Silver badge
            Coat

            Re: As always...

            The better to spy on you, my dear.

            Anyone still installing and running anything from Google are just asking for digital AIDS.

        2. Crazy Operations Guy

          Re: As always...

          I go one step further: every DB hosted on my DB server gets two partitions, several dedicated user accounts, and dedicated groups. The first partition stores the SQL daemon and configuration files and is mounter read-only. The second partition holds the actual db itself and is mounted within the first partition as read-write. As for users: The server daemon runs under its own process and is denied remote login to the server (its also assigned a null shell), multiple admin accounts are created for each db instance where each account is assigned to a specific physical person to admin that specific database, it has permissions to sudo as the server daemon.

          Within the DB itself, two user accounts are created for every logical group of tables. One account has read-only access to the group of tables, the other has write. Every action by write group and queries by the read-only group that return far more than the expected amount of data, are logged into our monitoring and alerting tools. On top of that, everything is stored procedures. The security is set up like this so that even if someone where to discover the password for one of the SQL accounts (which are the only accounts that can connect to the DB servers from a non-IT subnet and only then can connect from the web boxen).

  8. Paul Crawford Silver badge

    Anyone here using an apparmor profile to stop this general class of nonsense from taking place? (e.g. blocking writes to places like /etc, blocking execute from anywhere but correct system lockations, etc, etc).

  9. Daniel B.

    SELinux

    That should avoid modifying configuration files.

  10. Anonymous Coward
    Anonymous Coward

    If you read the post describing the issue neither Apparmor nor SELinux can stop the issue.

    1. Daniel B.
      Boffin

      If you actually spend some time configuring SELinux policies, you can actually make it so that the mysql daemons are unable to write to the configuration file even if they have UNIX permissions. The whole point of SELinux is to lock down everything at the OS level.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021