|Summary:||<dev-db/mysql-5.0.90-r2 multiple stack-based buffer overflows in bundled yaSSL (CVE-2009-4484)|
|Product:||Gentoo Security||Reporter:||Stefan Behte (RETIRED) <craig>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:||313095|
|Bug Blocks:||220813, 277717, 294187|
Description Stefan Behte (RETIRED) 2010-02-06 15:22:24 UTC
CVE-2009-4484 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-4484): Multiple stack-based buffer overflows in the CertDecoder::GetName function in src/asn.cpp in TaoCrypt in yaSSL before 1.9.9, as used in mysqld in MySQL 5.0.x before 5.0.90, MySQL 5.1.x before 5.1.43, MySQL 5.5.x through 5.5.0-m2, and other products, allow remote attackers to execute arbitrary code or cause a denial of service (memory corruption and daemon crash) by establishing an SSL connection and sending an X.509 client certificate with a crafted name field, as demonstrated by mysql_overflow1.py and the vd_mysql5 module in VulnDisco Pack Professional 8.11. NOTE: this was originally reported for MySQL 5.0.51a.
Comment 1 Stefan Behte (RETIRED) 2010-02-07 12:50:20 UTC
Comment 2 Stefan Behte (RETIRED) 2010-02-07 12:51:58 UTC
The rating was wrong, of course, as SSL is not enabled by default. "This Metasploit module exploits a stack buffer overflow in the yaSSL (1.9.8 and earlier) implementation bundled with MySQL. By sending a specially crafted client certificate, an attacker can execute arbitrary code. This vulnerability is present within the CertDecoder::GetName function inside ./taocrypt/src/asn.cpp. However, the stack buffer that is written to exists within a parent function stack frame. NOTE: This vulnerability requires a non-default configuration. First, the attacker must be able to pass the host-based authentication. Next, the server must be configured to listen on an accessible network interface. Lastly, the server must have been manually configured to use SSL. The binary from version 5.5.0-m2 was built with /GS and /SafeSEH. During testing on Windows XP SP3, these protections successfully prevented exploitation. Testing was also done with mysql on Ubuntu 9.04. Although the vulnerable code is present, both version 5.5.0-m2 built from source and version 5.0.75 from a binary package were not exploitable due to the use of the compiler's FORTIFY feature. Although suse11 was mentioned in the original blog post, the binary package they provide does not contain yaSSL or support SSL."
Comment 3 Robin Johnson 2010-02-08 15:57:09 UTC
The ebuilds are already in the tree. 5.0.90-r1 just needs to go to stable.
Comment 4 Stefan Behte (RETIRED) 2010-03-06 17:05:50 UTC
So, are they ok to go stable?
Comment 5 Robin Johnson 2010-03-06 21:35:47 UTC
arches, please stabilize dev-db/mysql-5.0.90-r2. target keywords: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86 test instructions: (see the ebuild) USE='berkdb -cluster embedded extraengine perl ssl community' \ FEATURES='test userpriv -usersandbox' \ ebuild mysql-5.0.90-r2.ebuild \ digest clean package
Comment 6 Christian Faulhammer (RETIRED) 2010-03-08 11:24:25 UTC
I still get failures with your test plan: mysql-test-run in ps-protocol mode: *** Failing the test(s): alter_table fulltext2 mysql_client_test ps sp mysql-test-run: *** ERROR: there were failing test cases
Comment 7 Robin Johnson 2010-03-08 21:01:10 UTC
fauli: can you please give me the test output in an attachment? mysql_client_test is the only false positive in your output that I know about.
Comment 8 Christian Faulhammer (RETIRED) 2010-03-08 21:22:54 UTC
Created attachment 222727 [details] complete build.log
Comment 9 Robin Johnson 2010-03-08 21:28:13 UTC
fauli: lots of new false positives there, thanks for that. +1 for you marking it stable in the meantime. I'm taking that log to upstream to talk to them about it. (if anybody else gets the same false positives, I'd like to hear about it as well, just because I don't get them on amd64).
Comment 10 Christian Faulhammer (RETIRED) 2010-03-09 10:08:43 UTC
Comment 11 Jeroen Roovers (RETIRED) 2010-03-09 14:38:19 UTC
# Jeroen Roovers <email@example.com> (02 Mar 2010) # Depends on >=sys-devel/gcc-4.3 which lack HPPA keywords (bug #307251) >=dev-db/mysql-5.0.83 =virtual/mysql-5.1
Comment 12 Brent Baude (RETIRED) 2010-03-12 18:50:59 UTC
Comment 13 Brent Baude (RETIRED) 2010-03-23 20:13:17 UTC
ppc done too; failed same 5 tests as x86
Comment 14 Robin Johnson 2010-03-24 03:37:25 UTC
fauli/ppc: those new testsuite failures you noted were due to a GCC change causing a cosmetic difference mainly, I've backported the fix from 5.1 series, per bug #308999.
Comment 15 Robin Johnson 2010-04-01 20:44:52 UTC
hppa: the matter that caused you to be blocked due to the GCC4.3 requirement has been resolved in a different matter. Turns out that 4.3 was only needed 5.0.8[3-6], and was removed by other changes that arrived in our tree in 5.0.87. I have confirmed that 5.0.90-r2 compiles even w/ hardened GCC3.4.6, so that should be great for you. I've updated the ebuilds and eclasses suitably.
Comment 16 Jeroen Roovers (RETIRED) 2010-04-01 22:21:58 UTC
(In reply to comment #15) > hppa: the matter that caused you to be blocked due to the GCC4.3 requirement > has been resolved in a different matter. Turns out that 4.3 was only needed > 5.0.8[3-6], and was removed by other changes that arrived in our tree in > 5.0.87. I have confirmed that 5.0.90-r2 compiles even w/ hardened GCC3.4.6, so > that should be great for you. I've updated the ebuilds and eclasses suitably. I'll give that a go, then.
Comment 17 Jeroen Roovers (RETIRED) 2010-04-02 17:09:37 UTC
Stable for HPPA.
Comment 18 Markos Chandras (RETIRED) 2010-04-04 16:52:44 UTC
Comment 19 Raúl Porcel (RETIRED) 2010-04-04 17:43:45 UTC
Comment 20 Robin Johnson 2010-06-06 20:46:25 UTC
arm/s390/sh: what's your status on this ranger: (In reply to comment #12) > ppc64 done It's not done. You marked 5.0.83 stable instead of 5.0.90-r2.
Comment 21 Brent Baude (RETIRED) 2010-06-07 14:54:32 UTC
ppc64 did mysql-5.0.90-r2 now
Comment 22 Joakim 2010-08-09 09:16:33 UTC
New ebuild mysql-5.0.91 changelog hint to this bug as a "version bump for security" but the tarball for the ebuild doesn't seem to be found anywhere around by portage. Is this just a temporary matter due to propagation or do I need to go somewhere special to fetch them manually now after the Oracle takeover?
Comment 23 Robin Johnson 2010-08-09 18:59:43 UTC
(In reply to comment #22) > New ebuild mysql-5.0.91 changelog hint to this bug as a "version bump for > security" but the tarball for the ebuild doesn't seem to be found anywhere > around by portage. Is this just a temporary matter due to propagation or do I > need to go somewhere special to fetch them manually now after the Oracle > takeover? Looks like some of the upstream mirrors are really lagging. It is available on http://mysql.rediris.es/Downloads/MySQL-5.0/mysql-5.0.91.tar.gz And i'll pre-seed our mirrors with it now.
Comment 24 Robin Johnson 2010-08-09 19:33:57 UTC
I take that back. Upstream changed mirror layout, and that mirror I linked above is actually broken and does bad redirects. Fixed in the eclass now.
Comment 27 Jorge Manuel B. S. Vicetto 2010-11-16 14:20:15 UTC
@s390/sh: what's your status on this?
Comment 28 Paweł Hajdan, Jr. (RETIRED) 2011-01-10 11:45:44 UTC
s390/sh are not security supported arches according to http://www.gentoo.org/security/en/vulnerability-policy.xml Should we make the decision about GLSA?
Comment 29 Tim Sammut (RETIRED) 2011-05-14 20:15:06 UTC
All arches have stabilized this, or a newer version in bug 344987. Added to existing GLSA request.
Comment 30 GLSAMaker/CVETool Bot 2012-01-05 22:46:52 UTC
This issue was resolved and addressed in GLSA 201201-02 at http://security.gentoo.org/glsa/glsa-201201-02.xml by GLSA coordinator Tim Sammut (underling).