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.
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."
The ebuilds are already in the tree. 5.0.90-r1 just needs to go to stable.
So, are they ok to go stable?
arches, please stabilize dev-db/mysql-5.0.90-r2.
target keywords: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86
(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
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
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.
Created attachment 222727 [details]
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).
# Jeroen Roovers <email@example.com> (02 Mar 2010)
# Depends on >=sys-devel/gcc-4.3 which lack HPPA keywords (bug #307251)
ppc done too; failed same 5 tests as x86
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.
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.
(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.
Stable for HPPA.
what's your status on this
(In reply to comment #12)
> ppc64 done
It's not done. You marked 5.0.83 stable instead of 5.0.90-r2.
ppc64 did mysql-5.0.90-r2 now
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?
(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
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.
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.
arm is waiting on bug 313095
arm stable via bug #339717
what's your status on this?
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?
All arches have stabilized this, or a newer version in bug 344987. Added to existing GLSA request.
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).