Buffer overflow in yaSSL, as used in MySQL 5.5.20 and possibly other versions including 5.5.x before 5.5.22 and 5.1.x before 5.1.62, allows remote attackers to execute arbitrary code via unspecified vectors, as demonstrated by VulnDisco Pack Professional 9.17. NOTE: as of 20120224, this disclosure has no actionable information. However, because the module author is a reliable researcher, the issue is being assigned a CVE identifier for tracking purposes. NOTE: due to lack of details, it is not clear whether this issue is a duplicate of CVE-2012-0492 or another CVE.
Buffer overflow in yaSSL, as used in MySQL 5.1.x before 5.1.68 and 5.5.x before 5.5.28, has unspecified impact and attack vectors, a different vulnerability than CVE-2013-1492.
The vioverifycallback function in viosslfactories.c in MySQL 5.0.x before 5.0.88 and 5.1.x before 5.1.41, when OpenSSL is used, accepts a value of zero for the depth of X.509 certificates, which allows man-in-the-middle attackers to spoof arbitrary SSL-based MySQL servers via a crafted certificate, as demonstrated by a certificate presented by a server linked against the yaSSL library.
Description of problem:
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-50.html
#
Security Fix: Replication: It was possible when using statement-based replication to subvert the MySQL privilege system on a slave with a higher server release version number than that of the master by using version-specific comments in statements run on the master.
A more detailed explanation follows:
In MySQL, a version-specific comment is an SQL comment of the form /!nnnnn sql / where nnnnn represents a MySQL release version number and sql represents a string of SQL, or a portion of a string of SQL, that should be executed by the MySQL Server only if the server version is at least version n.nn. (For additional information and an example, see Section 8.6, “Comment Syntax”.)
In MySQL replication, the slave SQL thread executes with the SUPER privilege, regardless of the privileges with which statements are originally executed on the master. Specific to this issue, when using statement-based replication it was possible, when the slave was of a higher MySQL version than the master, to run statements that would have failed on the master due to insufficient privileges, except that these statements were wrapped in version-specific comments where the encoded version was greater than the MySQL server version of the master. However, if the MySQL release version of the slave was equal to or greater than the version encoded in the comment, the same statements could execute on this slave whose MySQL release version was less than the version number used in the comment.
Suppose that a master running MySQL 5.1.48 replicated to a slave running MySQL 4.1.49, and that a user user1 had privileges to run UPDATE statements on database db1 but no privileges at all on the mysql system database, so that the first of the following two statements succeeded, but the second statement failed, and thus the first statement was written to the binary log, but the second statement was not:
UPDATE db1.tb1 SET db1.tbl1.col1=2; UPDATE mysql.user SET mysql.user.Superpriv='Y' WHERE mysql.user.User='user1';
However, the text of the second statement could be wrapped in version-specific comments and thus “hidden” within the text of the first statement so that this new version of the first statement succeeded, and was written in its entireity to the binary log. The new statement containing the necessary portions of the statement affecting the “mysql.user” table wrapped within version-specific comments is shown here:
UPDATE db1.tbl1 /!514900 ,mysql.user / SET db1.tbl1.col1=2 /!514900 ,mysql.user.Superpriv='Y' WHERE mysql.user.User='user1'/;
Thus, a 5.1.48 master would see this statement as identical to the first of the original two statements shown previously (UPDATE db1.tb1 SET db1.tbl1.col1=2). However, the version-specific comments within the statement just shown, when run on the MySQL 5.1.49 slave, were ignored; thus the slave SQL thread would execute the statement, as shown here, with the SUPER privilege, on the slave:
UPDATE db1.tbl1,mysql.user SET db1.tbl1.col1=2,mysql.user.Superpriv='Y' WHERE mysql.user.User='user1';
To fix this issue, the ! (exclamation) character is now stripped from comments prior to statements containing them being applied on replication slaves; thus, version-specific comments that are not applied on the master are treated as normal comments on the slave and also not applied there. (Bug#49124)
Version-Release number of selected component (if applicable):
MySQL 5.1.49
How reproducible:
see above
Steps to Reproduce: 1. see above 2. 3. Actual results:
Expected results:
Additional info:
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.x and 5.5.x allows remote authenticated users to affect confidentiality and availability via unknown vectors, a different vulnerability than CVE-2012-0118.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.x and 5.5.x allows remote attackers to affect availability via unknown vectors.
A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL. During evaluation of arguments to extreme-value functions (such as LEAST() and GREATEST()), type errors did not propagate properly, causing the server to crash, and any other connections to the server to be terminated.
[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=55826
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.x and 5.5.x allows remote authenticated users to affect confidentiality and availability via unknown vectors, a different vulnerability than CVE-2012-0113.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.x and 5.5.x allows remote authenticated users to affect confidentiality and integrity via unknown vectors.
An unspecified vulnerability in Oracle MySQL Connectors related to the Connector/J component has partial confidentiality impact, partial integrity impact, and no availability impact.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.0.x and 5.1.x allows remote authenticated users to affect availability via unknown vectors, a different vulnerability than CVE-2012-0087 and CVE-2012-0101.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.x and 5.5.x allows remote authenticated users to affect availability via unknown vectors, a different vulnerability than CVE-2012-0112, CVE-2012-0119, CVE-2012-0120, CVE-2012-0485, and CVE-2012-0492.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.0.x, 5.1.x, and 5.5.x allows remote authenticated users to affect confidentiality via unknown vectors.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.x and 5.5.x allows remote authenticated users to affect availability via unknown vectors, a different vulnerability than CVE-2012-0112, CVE-2012-0115, CVE-2012-0119, CVE-2012-0120, and CVE-2012-0492.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.x and 5.5.x allows remote authenticated users to affect availability via unknown vectors, a different vulnerability than CVE-2012-0112, CVE-2012-0115, CVE-2012-0119, CVE-2012-0485, and CVE-2012-0492.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.0.x, 5.1.x, and 5.5.x allows remote authenticated users to affect availability via unknown vectors.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.0.x and 5.1.x allows remote authenticated users to affect availability via unknown vectors, a different vulnerability than CVE-2012-0087 and CVE-2012-0102.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.x and 5.5.x allows remote authenticated users to affect availability via unknown vectors, a different vulnerability than CVE-2012-0112, CVE-2012-0115, CVE-2012-0120, CVE-2012-0485, and CVE-2012-0492.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.0.x and 5.1.x allows remote authenticated users to affect availability via unknown vectors, a different vulnerability than CVE-2012-0101 and CVE-2012-0102.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.60 and earlier, and 5.5.19 and earlier, allows remote authenticated users to affect availability, related to MyISAM.
A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL. Upstream describes the problem as follows:
IN quantified predicates are never executed directly. They are rather wrapped inside nodes called IN Optimizers (Iteminoptimizer) which take care of the execution. However, this is not done during view preparation. Unfortunately the LIKE predicate pre-evaluates constant right-hand side arguments even during name resolution within view preparation. Likely this is meant as an optimization.
There is a patch for this available [3].
[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=54568 [3] http://lists.mysql.com/commits/112602
A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL by creating a query with the GREATEST() or LEAST() functions having a mixed list of numeric and LONGBLOB arguments.
[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=54461
This is noted as having been fixed in MySQL 5.1.51, but it does not cause a crash on MySQL 5.0.50 in Fedora 13. It also causes a crash on Red Hat Enterprise Linux 5 (5.0.77) but not Red Hat Enterprise Linux 4 (4.1.22).
A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to cause the MySQL server to enter an infinite loop by creating a query with nested JOINs when used from stored procedures and prepared statements.
[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=53544
This affects MySQL 5.x, but MySQL 4.x and early do not have support for stored procedures. This causes CPU consumption around 95-100%, however connections and queries to the database can continue. Killing the query itself is ineffective, and even a 'service mysqld restart' will fail unless the mysqld process that is handling the query is forcibly killed.
A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL by using GROUPCONCAT() together with 'WITH ROLLUP'.
[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=54476
This is noted as having been fixed in MySQL 5.1.51, but it does not cause a crash on MySQL 5.0.50 in Fedora 13. It also causes a crash on Red Hat Enterprise Linux 5 (5.0.77) but not Red Hat Enterprise Linux 4 (4.1.22). GROUPCONCAT() support looks to have been added in MySQL 4.1, so Red Hat Enterprise Linux 3 is not affected.
A patch for this flaw is included in the upstream report.
A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to cause the MySQL server to crash when improper WKB data was passed to the PolyFromWKB() function.
There is an upstream patch [3] to correct the issue.
[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=51875 [3] http://lists.mysql.com/commits/117094
A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL. A user-variable assignment expression that is evaluated in a logical expression context can be precalculated in a temporary table for GROUP BY. However, when the expression value is used after creation of the temporary table, it was re-evaluated, not read from the table and a server crash resulted.
[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=55564
A flaw in MySQL versions prior to 5.1.51 [1] was reported [2] that could allow an authenticated user to kill connections to MySQL, where the server could crash after materializing a derived table that required a temporary table for grouping.
[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html [2] http://bugs.mysql.com/bug.php?id=55568
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.x and 5.5.x allows remote authenticated users to affect availability via unknown vectors, a different vulnerability than CVE-2012-0115, CVE-2012-0119, CVE-2012-0120, CVE-2012-0485, and CVE-2012-0492.
MySQL 5.1.x before 5.1.62 and 5.5.x before 5.5.22 allows remote authenticated users to cause a denial of service (assertion failure and mysqld abort) by deleting a record and using HANDLER READ NEXT.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.0.x, 5.1.x, and 5.5.x allows local users to affect confidentiality and integrity via unknown vectors.