Bug 80485 - Postgres ODBC lib Crashes in free(). Possible Buffer Overflow.
Postgres ODBC lib Crashes in free(). Possible Buffer Overflow.
Product: Red Hat Linux
Classification: Retired
Component: postgresql (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Andrew Overholt
David Lawrence
: Security
Depends On:
  Show dependency treegraph
Reported: 2002-12-26 21:31 EST by Matthew
Modified: 2007-04-18 12:49 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-30 03:48:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthew 2002-12-26 21:31:01 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
I work for a small software development firm and we are wanting to offer a
turn-key solution which includes a small server, RH8, and our software.

However, when we try to install our software on a stock RH8 install php
segfaults.  This also happens when all updates are applied.  The installation
works on RH 7.3.

Our application is written in PHP.  During the installation a PHP script opens a
file that contains the database CREATE TABLE statements necessary for creating
our database.  The script reads and executes these statements.  However, on RH8
it executes the first, then segfaults before executing the second.  The problem
appears to be in the libodbcpsql.so library.  I can reproduce it without the web
server by executing the php binary from the command line.  I have a stack trace
from gdb that points to the Postgres ODBC library.  

I can furnish the stack trace, the php script that opens the DDL files, the DDL
file itself, and the error message received in Apaches error_log file.

Like I said, it works under RH7.3.  I've tried 3 different workstations with RH8
and they all segfault identically.  I can walk you through a reproduction if you
would like.

Stack Trace: gdb php

(gdb) r run_ddl.php
Starting program: /usr/bin/php run_ddl.php
(no debugging symbols found)...[New Thread 8192 (LWP 2568)]
X-Powered-By: PHP/4.2.2
Content-type: text/html

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 2568)]
0x42074a1a in free () from /lib/i686/libc.so.6
(gdb) where
#0  0x42074a1a in free () from /lib/i686/libc.so.6
#1  0x40aa7c48 in TL_Destructor () from /usr/lib/libodbcpsql.so
#2  0x40aa306f in QR_Destructor () from /usr/lib/libodbcpsql.so
#3  0x40aa644f in PG_SQLFreeStmt () from /usr/lib/libodbcpsql.so
#4  0x40aa64c7 in SQLFreeStmt () from /usr/lib/libodbcpsql.so
#5  0x40961261 in SQLFreeEnv () from /usr/lib/libodbc.so.1
#6  0x40961923 in SQLFreeStmt () from /usr/lib/libodbc.so.1
#7  0x408a6050 in _free_odbc_result () from /usr/lib/php4/odbc.so
#8  0x08140202 in list_entry_destructor ()
#9  0x0813ea8a in zend_hash_del_key_or_index ()
#10 0x0813ff51 in _zend_list_delete ()
#11 0x408aa870 in zif_odbc_close () from /usr/lib/php4/odbc.so
#12 0x08152f6c in execute ()
#13 0x08152cdd in execute ()
#14 0x0813a186 in zend_execute_scripts ()
#15 0x080703ca in php_execute_script ()
#16 0x0806d4a8 in main ()
#17 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run php
2. Pass run_ddl.php to executable (or call from apache)
3. Watch boobery.

Actual Results:  Segmentation fault in free().  Thats bad news.

Expected Results:  Run to completion as it does on RH 7.3

Additional info:

I'm marking this as a security bug.  Possible buffer overflow, and since the
infected app is network-centric the possibilities of a remote root exploit are
Comment 1 Patrick Macdonald 2003-01-15 15:04:30 EST

This is a PostgreSQL ODBC related bug not unixODBC.  We'll
take a look at it once it's in its proper place.

Comment 2 Matthew 2003-01-18 01:03:13 EST
So is this going to get fixed?  I really don't want to ship the product using mysql.

Comment 3 Patrick Macdonald 2003-02-04 14:55:41 EST
Andrew, please handle.
Comment 4 Andrew Overholt 2003-02-04 15:44:24 EST
What versions of the various components are you running (unixODBC, PHP, and most
importantly PostgreSQL)?  There was an erratum for PostgreSQL not too long ago
and I'm wondering if it was fixed by that.
Comment 5 Andrew Overholt 2003-03-04 12:38:34 EST
Assigning to me (for posterity).
Comment 6 Andrew Overholt 2003-03-12 18:05:19 EST
Need more info as requested.
Comment 7 Matthew 2003-03-13 09:13:40 EST
Nope, the newest Postgres RPM via RHN didn't fix it.

unixODBC 2.2.3
PostgreSQL 7.2.3
PHP 4.2.2
Apache 2.0.40
Comment 8 Andrew Overholt 2003-03-27 17:31:01 EST
I cannot duplicate the problem without seeing the actual PHP.  I realise that
you may not want to attach your entire script, but do you think you can isolate
the section that is causing the problem?
Comment 9 Andrew Overholt 2003-06-02 11:51:23 EDT

Did you get a chance to isolate the portion of the script that's causing the
problem?  I think you mentioned that it's only CREATE DATABASE statements so if
that's the case, can I see them?  I would really like to duplicate this here so
that I can figure out where the problem lies.
Comment 10 Mark J. Cox (Product Security) 2003-06-30 03:48:12 EDT
This has been open for 3 months without a response from reporter, therefore
closing.  If you have any more information for Andrew that can help him
reproduce this bug please reopen it.

Note You need to log in before you can comment on or make changes to this bug.