libstagefright integer overflow checks can by bypassed with extended chunk lengths

[GoogleCodeExporter]

The following fix to an integer overflow issue (part of the stage fright issues 
presented at BlackHat) does not work as intended:

https://android.googlesource.com/platform/frameworks/av/+/f6dda8df18979200a27ca4
62a9dfa38c11a0e80c%5E!/

The check:

+            if (SIZE_MAX - chunk_size <= size) {
+                return ERROR_MALFORMED;
+            }

is ineffective because chunk_size can be a 64 bit value if extended chunk 
lengths are used. In the attached sample, SIZE_MAX = 0xffffffff, chunk_size = 
0xffffffffffffffff and size = 0x40.Therefore, SIZE_MAX - check_size = 
0xffffffff00000000 which passes the check as it is more than 0x40. This then 
causes an integer overflow in the allocation and read:

            uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];
            if (buffer == NULL) {
                return ERROR_MALFORMED;
            }

            if (size > 0) {
                memcpy(buffer, data, size);
            }

            if ((size_t)(mDataSource->readAt(*offset, buffer + size, chunk_size))

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

Original issue reported on code.google.com by natashe...@google.com on 12 Aug 2015 at 6:30

Attachments:

• subtitletest.mp4

[GoogleCodeExporter]

This is a duplicate:
https://code.google.com/p/android/issues/detail?id=182559

Public now, unrestricting. 
http://blog.exodusintel.com/2015/08/13/stagefright-mission-accomplished/

Original comment by natashe...@google.com on 13 Aug 2015 at 8:43

• Removed labels: Restrict-View-Commit

[GoogleCodeExporter]

Might as well unrestrict 182559 then...

Original comment by berendjanwever on 14 Aug 2015 at 3:43

[GoogleCodeExporter]

nice

Original comment by wangwei...@gmail.com on 26 Aug 2015 at 3:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Updating with a proof-of-concept exploit by Mark Brand. See the Project Zero 
blog for more details.

Original comment by haw...@google.com on 16 Sep 2015 at 6:30

Attachments:

• mp4_stagefright_release.py

[GoogleCodeExporter]

Could you please tell me that where i can get the "shellcode.bin" in the Exp 
file mp4_stagefright_release.py?

Original comment by jiangsha...@gmail.com on 10 Oct 2015 at 9:03

[GoogleCodeExporter]

Original comment by natashe...@google.com on 29 Oct 2015 at 5:33

• Changed state: Fixed

[GoogleCodeExporter]

jiangsha,

You can use any shellcode, either build from scratch or take an existing one.

You can use Zimpirium's remote shell, that was originally taken from Linux 
ARMLE 'shell_reverse_tcp' then modified to pass environment and fork + exit:

https://blog.zimperium.com/the-latest-on-stagefright-cve-2015-1538-exploit-is-no
w-available-for-testing-purposes

Good luck!

Original comment by tsahites...@gmail.com on 1 Nov 2015 at 8:52

[GoogleCodeExporter]

BTW, anyone knows the exact version of Android 5.x that works with Google's 
security research exploit? It crashes my LG-G2 (5.0.2) and Samsung S4 (5.0.1).

Original comment by tsahites...@gmail.com on 1 Nov 2015 at 8:54

[GoogleCodeExporter]

Does the exploit work?
You make the assumption that the spray_address is the vtable pointer, which is 
0x1c bytes ahead of the virtual function "readAt"(actually stack pivot 
address),but later when you copy the shellcode, you ignore the offset and just 
copy from spray_address - 0xed0 to your buffer:

  page += p32(mmap_address)             # r0 = dst
  page += p32(spray_address - 0xed0)    # r1 = src
  page += p32(0xed0)                    # r2 = size
  page += p32(0x33333333)               # r3
  page += p32(ldr_lr_bx_lr)             # pc

this is not correct. You need to copy from spray_address - 0xed0 - 0x1c 
actually.

Hope you can clarify this as you are Project Zero!

Original comment by 0xs...@gmail.com on 23 Dec 2015 at 2:21

[GoogleCodeExporter]

In my test machine only to crash. Output MP4 file has 16M. EXP there may be a 
problem, right? Thank you ~~~ hope to get help

Original comment by risingsu...@gmail.com on 24 Dec 2015 at 4:47

[GoogleCodeExporter]

I am seriously wondering if there is a reliably-working exploit against 
libstagefright. anyone knows?

Original comment by rexperie...@gmail.com on 14 Jan 2016 at 2:29