Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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