Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-32654

CVE-2017-3291

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Not a Bug
    • None
    • N/A
    • Server
    • Fedora / RHEL / CentOS Stream / upstream RPMs

    Description

      Hello,
      I'am digging through an old CVE-2017-3291

      It explains, that the `--ledir` option of mysqld_safe MUST NOT be accepted from config file, as an attacker with permission to edit at least some config files can re-define it to run malicious custom version of the server from a custom location.

      This was fixed in MySQL upstream in this commit:
      https://github.com/mysql/mysql-server/commit/53230ba274a37fa13d65e802c6ef3766cd0c6d91#diff-c9bb8f11d208a2bbeb6a062052ea37cfed9bc624b0b8222c063ae8df901a0019L221

      And it is present in the MySQL code base to this day:
      https://github.com/mysql/mysql-server/blob/8.0/scripts/mysqld_safe.sh#L248

      The MariaDB upstream claims, it fixed the CVE in:
      MariaDB 5.5.54, MariaDB 10.1.21, MariaDB 10.0.29
      https://mariadb.com/kb/en/security/

      The commit that implemented the fix in MariaDB 10.1.21 is this:
      https://github.com/MariaDB/server/commit/8fcdd6b0ecbb966f4479856efe93a963a7a422f7#diff-c9bb8f11d208a2bbeb6a062052ea37cfed9bc624b0b8222c063ae8df901a0019R242

      The fix is present in MariaDB 10.1 series to this day:
      https://github.com/MariaDB/server/blob/10.1/scripts/mysqld_safe.sh#L332

      But it never made it into MariaDB 10.2 and later:
      https://github.com/MariaDB/server/blob/10.2/scripts/mysqld_safe.sh#L343
      https://github.com/MariaDB/server/blob/11.2/scripts/mysqld_safe.sh#L330

      So it seems like a security regression in the upstream code of MariaDB.

      The mysqld_safe is meant to be used on distros without Systemd:

      mysqld_safe is the recommended way to start mysqld on Linux and Unix distributions that do not support systemd. Additionally, the mysql.server init script used by sysVinit starts mysqld with mysqld_safe by default.

      As per: https://mariadb.com/kb/en/mysqld_safe/

      Neither Fedora, CentOS Stream, RHEL:
      https://gitlab.com/redhat/centos-stream/rpms/mariadb/-/blob/c9s/mysql.service.in#L41
      nor upstream:
      https://github.com/MariaDB/server/blob/11.3/support-files/mariadb.service.in#L94
      use it in the Systemd service files.

      That IMO greatly reduces the area of attack, as the server admin had to configure custom systemd service file that would be used for starting the DB, so it would use the mysqld_safe.

      I'm not sure how to regression came to be.
      It doesn't seem to be intended, as the it was not reverted. It was just never applied in MariaDB 10.2, as far as I can tell.

      However since we (upstream, Fedora, CentOS Stream, RHEL) all still ship the mysqld_safe (or mariadb-safe), I'd like to clarify, whether it is an overlooked regression, or whether the base ground for this CVE does not exists to begin with in MariaDB 10.2 and later.

      Attachments

        Activity

          serg Sergei Golubchik added a comment -

          The fix in MariaDB commit 8fcdd6b0ec rejects --ledir if it comes from my.cnf in the datadir (indeed, because the server has write access to the datadir, so it can modify its own settings there). This fix disappeared in the commit Merge branch '10.1' into 10.2. Part of the merge's diff is

             then
          		 
               log_error "WARNING: Found $DATADIR/my.cnf
          		 
          -The data directory is a deprecated location for my.cnf, please move it to
          		 
          +The data directory is not a valid location for my.cnf, please move it to
          		 
           $MY_BASEDIR_VERSION/my.cnf"
          		 
          -    unsafe_my_cnf=1
          		 
          -    MYSQL_HOME=$DATADIR
          		 
          -  else
          		 
          -    MYSQL_HOME=$MY_BASEDIR_VERSION
          		 
             fi
          		 
          +  MYSQL_HOME=$MY_BASEDIR_VERSION
          		 
           fi

          that is, since 10.2 the server no longer reads my.cnf from the datadir at all. Thus a special protection check for that particular case is no longer needed.

          serg Sergei Golubchik added a comment - The fix in MariaDB commit 8fcdd6b0ec rejects --ledir if it comes from my.cnf in the datadir (indeed, because the server has write access to the datadir, so it can modify its own settings there). This fix disappeared in the commit Merge branch '10.1' into 10.2 . Part of the merge's diff is then log_error "WARNING: Found $DATADIR/my.cnf -The data directory is a deprecated location for my.cnf, please move it to +The data directory is not a valid location for my.cnf, please move it to $MY_BASEDIR_VERSION/my.cnf" - unsafe_my_cnf=1 - MYSQL_HOME=$DATADIR - else - MYSQL_HOME=$MY_BASEDIR_VERSION fi + MYSQL_HOME=$MY_BASEDIR_VERSION fi that is, since 10.2 the server no longer reads my.cnf from the datadir at all. Thus a special protection check for that particular case is no longer needed.

          People

            serg Sergei Golubchik
            mschorm Michal Schorm
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.