Date: Tue, 05 Jun 2012 23:22:50 -0600 From: Kurt Seifried <kseifried@...hat.com> To: oss-security@...ts.openwall.com CC: Tomas Hoger <thoger@...hat.com>, Felipe Pena <felipensp@...il.com> Subject: Re: CVE id request: Multiple buffer overflow in unixODBC -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/31/2012 08:44 AM, Tomas Hoger wrote: > On Wed, 30 May 2012 13:02:53 -0600 Kurt Seifried wrote: > >> On 05/30/2012 11:40 AM, Felipe Pena wrote: >> >>> It isn't limited to the configuration files. Such input can be >>> passed to the `isql' interactive tool that come together >>> unixODBC. The same string can be used to connect through PHP >>> PDO, for example. > > Agree, anything that parses such connect string can be crashed > this way. The question is if any trust boundary is crossed with > that, which depends on whether there are any apps that allow > untrusted connect strings. > >>> $ ./isql "FILEDSN=$(python -c "print 'A'*10000");UID=user" -k > > Anyone having shell access to run isql directly should be assumed > to have ability to edit ~/.odbcinst.ini, which should be enough to > crash isql or inject code to it without having to trigger one of > the mentioned overflows. > >> Is this something that an attacker can typically control, or does >> the PHP author need to write code that does this? > > For PHP applications, would you assume attacker can typically > control settings as database name, host, port or username? It's > not really quite common. Possible use cases that come to mind: > > - DB management application similar to phpMyAdmin, that may take > some DB connection info as input from user. If something like that > exists for ODBC, another question would be if the info from user > can actually be used to sneak in values for FILEDSN or DRIVER. - Of > course, this may allow safe_mode bypass, which may not be possible > via odbcinst.ini (e.g. PHP script may not be allowed to edit it > and safe_mode does not allow setting ODBCINSTINI environment > variable). > Forgot to follow up, in light of this I think it's safe to let the CVE stand as is. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPzukqAAoJEBYNRVNeJnmTskMP/0xfDKnEm5jXoNld34jYG+Ph RwMNBj5VICzdOTCNWdqNd4RmEzN9bEyQS3h859IIE0W3JOZXvZV+jMXFKaqIEO12 12cpUHoALz85Gettke7HDulcPzojzpYAezq/Ifw+L+pV180gJrxRooHXmnUXCjeK W7xEPaJWRRdcIstnp1b7vNaNOr219gWG+ftuEvNNzFD8dV0C1hXtBWYq42XSP3rm OFL9prwIaRnWGL8jjYiJFeRTmckiFwU+1i/FOR9ig9fUjWaJjBN+CbYlwCRxH5l4 HemaYGhYLwKh7/lJHDBvz3xa3kFeuChtBuk8OsxTrLJ7hKXOUGVCyiBUGMaHjAKO 143EOcw6iPbOjyEUuLjbKFBao+cK5qgYvLOcX2jWsct+RHYa22GcJr736G/1JRHc 1vFJZSn4VMwNuNgmvRy272JjJqrAXGMzhysN+Dck/s2U9zu1YS50V1hrz9JFtNZj BYTJV2rh/f4JUuRNH0tM7BJTo6gGr81+FFgEYcrnxZm1/SwndJ8SOQ63PCs9qwZE EqlCeQQxCR4W0rldWEAsWuaHNvyANyw14ReAFGoh6/tsMiCUBqKn++OeMG93BwKE E0SdlwaCY7u5yd94WbyhvEYKEdWEBJiXysVigsh9Jbujr3dt3fuXQCv6M0FlQT8l ViSlgG6MXmrI2eQfkBDP =RZi3 -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ