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

Users without any permissions could retrieve table names via the error message of DROP TRIGGER

Details

    Description

      Users without any permissions can retrieve table names via the error message of the DROP TRIGGER statement.
      For example, if the table `test.tbl` has a trigger named `before_insert_tbl`, a user without any permissions can retrieve the table name by executing the statement `DROP TRIGGER test.before_insert_tbl`.
      The error message displayed is "ERROR 1142 (42000): TRIGGER command denied to user 'foo'@'localhost' for table 'tbl'", which reveals the table name `tbl` to the user.

      The Proof of Concept (PoC):

      -- Use the root user to connect to MariaDB and create a trigger and an empty user
      		 
      -- Example:
      		 
      --   docker run -itd --name some-mariadb --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 -p 3306:3306 mariadb:11.7.1-rc
      		 
      --   docker exec -it some-mariadb mariadb -uroot
      		 
       
      		 
      CREATE DATABASE test;
      		 
      CREATE TABLE test.tbl (x INT);
      		 
      CREATE TRIGGER test.before_insert_tbl -- Create a trigger
      		 
      BEFORE INSERT ON test.tbl FOR EACH ROW
      		 
      INSERT INTO test SELECT 1;
      		 
      CREATE USER foo; -- Create an empty user
      		 
      QUIT; -- Exit
      		 
       
      		 
      -- Login with the user `foo` and try to drop trigger
      		 
      -- Example:
      		 
      --   docker exec -it some-mariadb mariadb -ufoo
      		 
       
      		 
      DROP TRIGGER test.test; -- Drop a non-existing trigger
      		 
      -- Error message: ERROR 1360 (HY000): Trigger does not exist
      		 
      DROP TRIGGER test.before_insert_tbl; -- Drop an existing trigger
      		 
      -- ERROR 1142 (42000): TRIGGER command denied to user 'foo'@'localhost' for table `test`.`tbl`

      From the error message when dropping an existing trigger, the user `foo` (who has no permissions) can infer the existence of the database `test`, the table `test.tbl`, and the trigger `test.before_insert_tbl`.

      If the user can "guess" a trigger name (e.g., via brute-force enumeration or by attempting commonly-used names) and the trigger name exists, the user can infer the existence of the trigger and retrieve the corresponding table name via the `DROP TRIGGER` statement.

      Since the user has no permissions, it seems unreasonable that they can obtain information about databases, tables, and triggers. Maybe it is a bug or issue?

      Instead, other statements like the DROP INDEX statement can protect such information:

      # Create index with the root user
      		 
      CREATE INDEX w ON test.tbl(x);
      		 
      QUIT; -- Exit
      		 
       
      		 
      # Connect with the empty user
      		 
      # Example:
      		 
      #   docker exec -it some-mariadb mariadb -ufoo
      		 
      # Attempting DROP INDEX
      		 
      DROP INDEX w ON test.tbl;
      		 
      -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`tbl`
      		 
      DROP INDEX w ON testx.tbl;
      		 
      -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `testx`.`tbl`
      		 
      DROP INDEX w ON `???`.tbl;
      		 
      -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `???`.`tbl`
      		 
      DROP INDEX w ON `???`.`???`;
      		 
      -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `???`.`???`
      		 
      DROP INDEX w ON `test`.`???`;
      		 
      -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`???`
      		 
      DROP INDEX `???` ON testx.tbl;
      		 
      -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`tbl`

      For the `DROP INDEX` statement, the user without permissions cannot retrieve any information about the database, table, or index because the error messages are always generic. This seems to be the correct behavior for `DROP` statements.

      So, maybe the current error message of DROP TRIGGER needs to be improved?

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          fuboat Jingzhou Fu created issue -
          fuboat Jingzhou Fu made changes -
          Field Original Value New Value
          Description Users without any permissions can retrieve table names via the error message of the DROP TRIGGER statement.
          For example, if the table `test.tbl` has a trigger named `before_insert_tbl`, a user without any permissions can retrieve the table name by executing the statement `DROP TRIGGER test.before_insert_tbl`.
          The error message displayed is "ERROR 1142 (42000): TRIGGER command denied to user 'foo'@'localhost' for table 'tbl'", which reveals the table name `tbl` to the user.

          *The Proof of Concept (PoC):*

          {code:sql}
          # Use the root user to connect to MariaDB and create a trigger and an empty user
          # Example:
          # docker run -itd --name some-mariadb --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 -p 3306:3306 mariadb:11.7.1-rc
          # docker exec -it some-mariadb mariadb -uroot

          CREATE DATABASE test;
          CREATE TABLE test.tbl (x INT);
          CREATE TRIGGER test.before_insert_tbl -- Create a trigger
          BEFORE INSERT ON test.tbl FOR EACH ROW
          INSERT INTO test SELECT 1;

          CREATE USER foo; -- Create a empty user
          QUIT; -- Exit

          # Login with the user `foo` and try to drop trigger
          # Example:
          # docker exec -it some-mariadb mariadb -ufoo

          DROP TRIGGER test.test; -- Drop a non-existing trigger
          -- ERROR 1360 (HY000): Trigger does not exist

          DROP TRIGGER test.before_insert_tbl; -- Drop an existing trigger
          -- ERROR 1142 (42000): TRIGGER command denied to user 'foo'@'localhost' for table `test`.`tbl`
          {code}


          From the error message when dropping an existing trigger, the user `foo` (who has no permissions) can infer the existence of the database `test`, the table `test.tbl`, and the trigger `test.before_insert_tbl`.

          If the user can "guess" a trigger name (e.g., via brute-force enumeration or by attempting commonly-used names) and the trigger name exists, the user can infer the existence of the trigger and retrieve the corresponding table name via the `DROP TRIGGER` statement.

          Since the user has no permissions, it seems unreasonable that they can obtain information about databases, tables, and triggers. Maybe it is a bug or issue?

          Instead, other statements like the DROP INDEX statment can protect such information:

          {code:sql}
          # Create index with the root user
          CREATE INDEX w ON test.tbl(x);
          QUIT; -- Exit

          # Connect with the empty user
          # Example:
          # docker exec -it some-mariadb mariadb -ufoo
          # Attempting DROP INDEX
          DROP INDEX w ON test.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`tbl`
          DROP INDEX w ON testx.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `testx`.`tbl`
          DROP INDEX w ON `???`.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `???`.`tbl`
          DROP INDEX w ON `???`.`???`;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `???`.`???`
          DROP INDEX w ON `test`.`???`;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`???`
          DROP INDEX `???` ON testx.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`tbl`
          {code}

          For the `DROP INDEX` statement, the user without permissions cannot retrieve any information about the database, table, or index because the error messages are always generic. This seems to be the correct behavior for `DROP` statements.

          So, maybe current error message of DROP TRIGGER need to be improved?
          		Users without any permissions can retrieve table names via the error message of the DROP TRIGGER statement.
          For example, if the table `test.tbl` has a trigger named `before_insert_tbl`, a user without any permissions can retrieve the table name by executing the statement `DROP TRIGGER test.before_insert_tbl`.
          The error message displayed is "ERROR 1142 (42000): TRIGGER command denied to user 'foo'@'localhost' for table 'tbl'", which reveals the table name `tbl` to the user.

          *The Proof of Concept (PoC):*

          {code:sql}
          -- Use the root user to connect to MariaDB and create a trigger and an empty user
          -- Example:
          -- docker run -itd --name some-mariadb --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 -p 3306:3306 mariadb:11.7.1-rc
          -- docker exec -it some-mariadb mariadb -uroot

          CREATE DATABASE test;
          CREATE TABLE test.tbl (x INT);
          CREATE TRIGGER test.before_insert_tbl -- Create a trigger
          BEFORE INSERT ON test.tbl FOR EACH ROW
          INSERT INTO test SELECT 1;
          CREATE USER foo; -- Create an empty user
          QUIT; -- Exit

          -- Login with the user `foo` and try to drop trigger
          -- Example:
          -- docker exec -it some-mariadb mariadb -ufoo

          DROP TRIGGER test.before_insert_tbl; -- Drop an existing trigger
          -- ERROR 1142 (42000): TRIGGER command denied to user 'foo'@'localhost' for table `test`.`tbl`
          {code}


          From the error message when dropping an existing trigger, the user `foo` (who has no permissions) can infer the existence of the database `test`, the table `test.tbl`, and the trigger `test.before_insert_tbl`.

          If the user can "guess" a trigger name (e.g., via brute-force enumeration or by attempting commonly-used names) and the trigger name exists, the user can infer the existence of the trigger and retrieve the corresponding table name via the `DROP TRIGGER` statement.

          Since the user has no permissions, it seems unreasonable that they can obtain information about databases, tables, and triggers. Maybe it is a bug or issue?

          *Instead, other statements like the DROP INDEX statement can protect such information:*

          {code:sql}
          # Create index with the root user
          CREATE INDEX w ON test.tbl(x);
          QUIT; -- Exit

          # Connect with the empty user
          # Example:
          # docker exec -it some-mariadb mariadb -ufoo
          # Attempting DROP INDEX
          DROP INDEX w ON test.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`tbl`
          DROP INDEX w ON testx.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `testx`.`tbl`
          DROP INDEX w ON `???`.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `???`.`tbl`
          DROP INDEX w ON `???`.`???`;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `???`.`???`
          DROP INDEX w ON `test`.`???`;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`???`
          DROP INDEX `???` ON testx.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`tbl`
          {code}

          For the `DROP INDEX` statement, the user without permissions cannot retrieve any information about the database, table, or index because the error messages are always generic. This seems to be the correct behavior for `DROP` statements.

          So, maybe the current error message of DROP TRIGGER needs to be improved?
          fuboat Jingzhou Fu made changes -
          Description Users without any permissions can retrieve table names via the error message of the DROP TRIGGER statement.
          For example, if the table `test.tbl` has a trigger named `before_insert_tbl`, a user without any permissions can retrieve the table name by executing the statement `DROP TRIGGER test.before_insert_tbl`.
          The error message displayed is "ERROR 1142 (42000): TRIGGER command denied to user 'foo'@'localhost' for table 'tbl'", which reveals the table name `tbl` to the user.

          *The Proof of Concept (PoC):*

          {code:sql}
          -- Use the root user to connect to MariaDB and create a trigger and an empty user
          -- Example:
          -- docker run -itd --name some-mariadb --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 -p 3306:3306 mariadb:11.7.1-rc
          -- docker exec -it some-mariadb mariadb -uroot

          CREATE DATABASE test;
          CREATE TABLE test.tbl (x INT);
          CREATE TRIGGER test.before_insert_tbl -- Create a trigger
          BEFORE INSERT ON test.tbl FOR EACH ROW
          INSERT INTO test SELECT 1;
          CREATE USER foo; -- Create an empty user
          QUIT; -- Exit

          -- Login with the user `foo` and try to drop trigger
          -- Example:
          -- docker exec -it some-mariadb mariadb -ufoo

          DROP TRIGGER test.before_insert_tbl; -- Drop an existing trigger
          -- ERROR 1142 (42000): TRIGGER command denied to user 'foo'@'localhost' for table `test`.`tbl`
          {code}


          From the error message when dropping an existing trigger, the user `foo` (who has no permissions) can infer the existence of the database `test`, the table `test.tbl`, and the trigger `test.before_insert_tbl`.

          If the user can "guess" a trigger name (e.g., via brute-force enumeration or by attempting commonly-used names) and the trigger name exists, the user can infer the existence of the trigger and retrieve the corresponding table name via the `DROP TRIGGER` statement.

          Since the user has no permissions, it seems unreasonable that they can obtain information about databases, tables, and triggers. Maybe it is a bug or issue?

          *Instead, other statements like the DROP INDEX statement can protect such information:*

          {code:sql}
          # Create index with the root user
          CREATE INDEX w ON test.tbl(x);
          QUIT; -- Exit

          # Connect with the empty user
          # Example:
          # docker exec -it some-mariadb mariadb -ufoo
          # Attempting DROP INDEX
          DROP INDEX w ON test.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`tbl`
          DROP INDEX w ON testx.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `testx`.`tbl`
          DROP INDEX w ON `???`.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `???`.`tbl`
          DROP INDEX w ON `???`.`???`;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `???`.`???`
          DROP INDEX w ON `test`.`???`;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`???`
          DROP INDEX `???` ON testx.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`tbl`
          {code}

          For the `DROP INDEX` statement, the user without permissions cannot retrieve any information about the database, table, or index because the error messages are always generic. This seems to be the correct behavior for `DROP` statements.

          So, maybe the current error message of DROP TRIGGER needs to be improved?
          		Users without any permissions can retrieve table names via the error message of the DROP TRIGGER statement.
          For example, if the table `test.tbl` has a trigger named `before_insert_tbl`, a user without any permissions can retrieve the table name by executing the statement `DROP TRIGGER test.before_insert_tbl`.
          The error message displayed is "ERROR 1142 (42000): TRIGGER command denied to user 'foo'@'localhost' for table 'tbl'", which reveals the table name `tbl` to the user.

          *The Proof of Concept (PoC):*

          {code:sql}
          -- Use the root user to connect to MariaDB and create a trigger and an empty user
          -- Example:
          -- docker run -itd --name some-mariadb --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 -p 3306:3306 mariadb:11.7.1-rc
          -- docker exec -it some-mariadb mariadb -uroot

          CREATE DATABASE test;
          CREATE TABLE test.tbl (x INT);
          CREATE TRIGGER test.before_insert_tbl -- Create a trigger
          BEFORE INSERT ON test.tbl FOR EACH ROW
          INSERT INTO test SELECT 1;
          CREATE USER foo; -- Create an empty user
          QUIT; -- Exit

          -- Login with the user `foo` and try to drop trigger
          -- Example:
          -- docker exec -it some-mariadb mariadb -ufoo

          DROP TRIGGER test.test; -- Drop a non-existing trigger
          -- Error message: ERROR 1360 (HY000): Trigger does not exist
          DROP TRIGGER test.before_insert_tbl; -- Drop an existing trigger
          -- ERROR 1142 (42000): TRIGGER command denied to user 'foo'@'localhost' for table `test`.`tbl`
          {code}


          From the error message when dropping an existing trigger, the user `foo` (who has no permissions) can infer the existence of the database `test`, the table `test.tbl`, and the trigger `test.before_insert_tbl`.

          If the user can "guess" a trigger name (e.g., via brute-force enumeration or by attempting commonly-used names) and the trigger name exists, the user can infer the existence of the trigger and retrieve the corresponding table name via the `DROP TRIGGER` statement.

          Since the user has no permissions, it seems unreasonable that they can obtain information about databases, tables, and triggers. Maybe it is a bug or issue?

          *Instead, other statements like the DROP INDEX statement can protect such information:*

          {code:sql}
          # Create index with the root user
          CREATE INDEX w ON test.tbl(x);
          QUIT; -- Exit

          # Connect with the empty user
          # Example:
          # docker exec -it some-mariadb mariadb -ufoo
          # Attempting DROP INDEX
          DROP INDEX w ON test.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`tbl`
          DROP INDEX w ON testx.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `testx`.`tbl`
          DROP INDEX w ON `???`.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `???`.`tbl`
          DROP INDEX w ON `???`.`???`;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `???`.`???`
          DROP INDEX w ON `test`.`???`;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`???`
          DROP INDEX `???` ON testx.tbl;
          -- ERROR 1142 (42000): INDEX command denied to user 'foo'@'localhost' for table `test`.`tbl`
          {code}

          For the `DROP INDEX` statement, the user without permissions cannot retrieve any information about the database, table, or index because the error messages are always generic. This seems to be the correct behavior for `DROP` statements.

          So, maybe the current error message of DROP TRIGGER needs to be improved?
          serg Sergei Golubchik made changes -
          Fix Version/s 10.6 [ 24028 ]
          Fix Version/s 10.11 [ 27614 ]
          Fix Version/s 11.4 [ 29301 ]
          serg Sergei Golubchik made changes -
          Assignee Oleksandr Byelkin [ sanja ]

          People

            sanja Oleksandr Byelkin
            fuboat Jingzhou Fu
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

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