Follow @Openwall on Twitter for new release announcements and other news
[<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.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.