From fuzzing to remote code execution in Samsung android

from Fuzzing to remote code execution

Google’s Project Zero, google’s own special team dedicated
to find zero days and hack a wide range of products has found
a heap overflow in Samsung’s android Skia image processing library.
That was found by the team member Mateusz Jurczyk.
Making a malicious MMS being able trigger a remote code execution. The vulnerability lays in the image processing of files
that happens when a MMS is received and the image is process
by android’s Skia library without user interaction.
So receiving a malicious image that will trigger the cause a
heap overflow in the image processing will lead to a remote
code execution.

Fuzzing

The bug was found using the popular afl(American fuzzing lop) program which has been used to found a
wide range of bugs in several big software projects such as
Apache, Perl, iOS Kernel, OpenBSD, VLC, clang, putty, firefox and the list goes on.

American fuzzing loop logo

AFL was created by Michal Zalewski who has been a working at google’s Project
Zero but is currently working
for snap the company behind the social media platform Snapchat.

But what is fuzzing?

Fuzzing is the art of throwing as much different/random type of data in to the
targeted program as input
as possible. With the aim of finding bugs.

Google has an automated fuzzing engine called OSS-Fuzz which has found over
16 000 bugs in a wide range of different software
https://bugs.chromium.org/p/oss-fuzz/issues/list?q=-status%3AWontFix%2CDuplicate%20-component%3AInfra&can=1

A great read for getting more in dept information about fuzzing is reading the book:
“Fuzzing for Software Security Testing and Quality Assurance”

Another way of visualizing fuzzing is to think of a person throwing different
stones at a wall until the person
finds the perfect stone that breaks the wall with one hit.

The vulnerability was given the CVE of CVE-2020-8899 with a high severity. Link to CVE:
https://vulns.firosolutions.com/cve/CVE-2020-8899/

The vulnerability

The author targeted the Skia library which is a graphical 3d
library used by Android(also used by Google Chrome, Chrome OS, Mozilla Firefox
and Firefox OS) to load and display images.
By default Skia is support the following image formats:
* ICO
* BMP
* WBMP
* PNG
* JPEG
* GIF
* WEBP
* HEIF
* RAW

Using binary analysis tool IDA pro the author is able to
see that Samsung has added custom support for
* QM
* QG
* ASTC
* PIO

This vulnerability is for two of these custom added
formats QM and QG originally created by the Korean
software vendor (Quramsoft)[http://www.quramsoft.com].

Using an up-to-date Samsung Galaxy Note 10+ device
running Android 10 and being completely up to date with the latest
security patches as of January 2020.
By extracting QM and QG images from Samsung built in apk
applications.
The author then nicely runs an emulation version using
qemu-aarch64 to be able to run the executable binaries
as they where running natively on a Samsung device.

Compiling the binary that is going to be throw in to afl
could be a bit tricky and what is needed is the Skia source
code, Android NDK, Capstonem, libbacktrace,
lib64 and linker64 from Samsung’s android system.
Once all of these ingredients are put in to place
we are able to compile a elf binary for ARM aarch64.

As a result of fuzzing this binary over 5000 different crashes
was found in the summary of:

+-------------+-------+------------+
|             | Count | Percentage |
+-------------+-------+------------+
| write       |   174 | 3.33%      |
| sigabrt     |     3 | 0.06%      |
| read-1      |  3322 | 63.66%     |
| read-2      |   393 | 7.53%      |
| read-4      |   703 | 13.47%     |
| read-8      |    34 | 0.65%      |
| read-16     |    52 | 1.00%      |
| read-32     |     3 | 0.06%      |
| read-vector |    18 | 0.34%      |
| read-memcpy |   124 | 2.38%      |
| null-deref  |   392 | 7.51%      |
+-------------+-------+------------+

sigabrt, is a unix signal that tells the process to abort and
stop the program when a critical error appears.
Such as a heap overflow resulting in a crash.
The reads meaning an out of bound memory read and
the 174 write out of bound(CWE-787) meaning the program is able
to write outside of its dedicated allocated memory.
Being able to write outside the allocated memory will lead
to Stack and Heap based buffer overflows.
These vulnerabilities are very serious because when exploited
they will lead to arbitrary code execution and is often given
a high severity.

Crash

an exploitable crash is attached in the advisory:

Build fingerprint: 'samsung/d2sxx/d2s:10/QP1A.190711.020/N975FXXS1BSLD:user/release-keys'
Revision: '24'
ABI: 'arm64'
Timestamp: 2020-01-24 09:40:57+0100
pid: 31355, tid: 31386, name: thumbnail_threa  >>> com.sec.android.app.myfiles <<<
uid: 10088
signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0x4a4a4a4a4a4a4a
    x0  0000006ff55dc408  x1  0000006f968eb324  x2  0000000000000001  x3  0000000000000001
    x4  4a4a4a4a4a4a4a4a  x5  0000006f968eb31d  x6  00000000000000b3  x7  00000000000000b3
    x8  0000000000000000  x9  0000000000000001  x10 0000000000000001  x11 0000000000000001
    x12 0000007090d96860  x13 0000000000000001  x14 0000000000000004  x15 0000000000000002
    x16 0000007091463000  x17 0000007090ea2d94  x18 0000006f95d1a000  x19 0000006ff5709800
    x20 00000000ffffffff  x21 0000006ff55dc408  x22 00000000000000b0  x23 0000006f968ed020
    x24 0000000000000001  x25 0000000000000001  x26 0000006f968ed020  x27 0000000000000be5
    x28 0000000000012e9a  x29 0000006f968eb370
    sp  0000006f968eb310  lr  0000007090f5f7f0  pc  004a4a4a4a4a4a4a

backtrace:
      #00 pc 004a4a4a4a4a4a4a  <unknown>
      #01 pc 00000000002e97ec  /system/lib64/libhwui.so (process_run_dec_check_buffer+92) (BuildId: fcab350692b134df9e8756643e9b06a0)
      #02 pc 00000000002ddb94  /system/lib64/libhwui.so (QmageRunLengthDecodeCheckBuffer_Rev11454_141008+1320) (BuildId: fcab350692b134df9e8756643e9b06a0)
      #03 pc 00000000002d45dc  /system/lib64/libhwui.so (PVcodecDecoderIndex_Rev11454_141008+1264) (BuildId: fcab350692b134df9e8756643e9b06a0)
      #04 pc 00000000002d3fb4  /system/lib64/libhwui.so (__QM_WCodec_decode_Rev11454_141008+224) (BuildId: fcab350692b134df9e8756643e9b06a0)
      #05 pc 00000000002d3d28  /system/lib64/libhwui.so (Qmage_WDecodeFrame_Low_Rev11454_141008+192) (BuildId: fcab350692b134df9e8756643e9b06a0)
      #06 pc 00000000002d08e4  /system/lib64/libhwui.so (QuramQmageDecodeFrame_Rev11454_141008+144) (BuildId: fcab350692b134df9e8756643e9b06a0)
      #07 pc 00000000006e1f8c  /system/lib64/libhwui.so (SkQmgCodec::onGetPixels(SkImageInfo const&, void*, unsigned long, SkCodec::Options const&, int*)+1260) (BuildId: fcab350692b134df9e8756643e9b06a0)
      #08 pc 00000000004daefc  /system/lib64/libhwui.so (SkCodec::getPixels(SkImageInfo const&, void*, unsigned long, SkCodec::Options const*)+852) (BuildId: fcab350692b134df9e8756643e9b06a0)
      #09 pc 00000000006e2788  /system/lib64/libhwui.so (SkQmgAdapterCodec::onGetAndroidPixels(SkImageInfo const&, void*, unsigned long, SkAndroidCodec::AndroidOptions const&)+168) (BuildId: fcab350692b134df9e8756643e9b06a0)
      #10 pc 00000000004da494  /system/lib64/libhwui.so (SkAndroidCodec::getAndroidPixels(SkImageInfo const&, void*, unsigned long, SkAndroidCodec::AndroidOptions const*)+684) (BuildId: fcab350692b134df9e8756643e9b06a0)
      #11 pc 00000000006e0930  /system/lib64/libhwui.so (SkBitmapRegionCodec::decodeRegion(SkBitmap*, SkBRDAllocator*, SkIRect const&, int, SkColorType, bool, sk_sp<SkColorSpace>)+1168) (BuildId: fcab350692b134df9e8756643e9b06a0)
      #12 pc 00000000001991c8  /system/lib64/libandroid_runtime.so (nativeDecodeRegion(_JNIEnv*, _jobject*, long, int, int, int, int, _jobject*, long, long)+976) (BuildId: 21b5827e07da22480245498fa91e171d)
[...]

The author has also tested a wide range of samsung hardware:
1. Galaxy Note 4 (Android 4.4.4, Sep 2014)
2. Galaxy Note Edge (Android 4.4.4, Nov 2014 - Dec 2014)
3. Galaxy Note Edge (Android 5.0.1, Mar 2015 - Jun 2015)
4. Galaxy Core Prime (Android 5.1.1, Aug 2015)
5. Galaxy Note 5 (Android 5.1.1, Aug 2015)
6. Galaxy Note 4 (Android 5.1.1, Oct 2015)
7. Galaxy Note 3 (Android 5.0, Jan 2016)
8. Galaxy S7 (Android 6.0.1, Feb 2016)
9. Galaxy Note 5 (Android 6.0.1, Feb 2016)
10. Galaxy S7 (Android 7, Jan 2017)
11. Galaxy Note 5 (Android 7, Mar 2017)
12. Galaxy S8 (Android 7, Apr 2017)
13. Galaxy S8 (Android 8, Feb 2018)
14. Galaxy S7 (Android 8, Apr 2018)
15. Galaxy S9 (Android 8, Apr 2018)
16. Galaxy S8 (Android 9, Feb 2019)
17. Galaxy S9 (Android 9, Apr 2019)
18. Galaxy A50 (Android 9, Oct 2019)
19. Galaxy Note 10+ (Android 9, Nov 2019 - Dec 2019)
20. Galaxy Note 10+ (Android 10, Jan 2020)

Working exploit on Samsung Galaxy Note 10


The author is nicely triggering a heap overflow on the Samsung device
resulting the device getting hacked and the attacker gaining a reverse shell.

This vulnerability is amazingly done by Mateusz Jurczyk demonstrating the
true power of fuzzing!

Going from a just firing up AFL to achieving a zero interaction remote code
execution using a malicious MMS.

The author was nice enough to publish a 7z archive of the crashes
that can be downloaded.

Sample of one of the out of bound write crashes:

ASAN:SIGABRT
=================================================================
==284619==ERROR: AddressSanitizer: ABRT on unknown address 0xbc707f000457cb (pc 0x400372d360 sp 0x4000cfe840 bp 0x4000cfe840 T0)
    #0 0x00083360 in libc.so (abort+0xb0)
    #1 0x000cec40 in libc.so (__set_errno_internal+0x0)
    #2 0x006e33a0 in libhwui.so (SkQMCodec::onGetPixels(SkImageInfo const&, void*, unsigned long, SkCodec::Options const&, int*)+0x4e8)
    #3 0x004daf00 in libhwui.so (SkCodec::getPixels(SkImageInfo const&, void*, unsigned long, SkCodec::Options const*)+0x358)

==284619==DISASSEMBLY
    0x400372d360:	mov		x1, sp
    0x400372d364:	orr		w0, wzr, #6
    0x400372d368:	stp		q1, q0, [sp]
    0x400372d36c:	mov		x2, xzr
    0x400372d370:	bl		#0x4003791b20
    0x400372d374:	sub		x1, x29, #0x28
    0x400372d378:	orr		w0, wzr, #2
    0x400372d37c:	mov		x2, xzr
    0x400372d380:	bl		#0x4003791b10
    0x400372d384:	mov		x0, x19

==284619==CONTEXT
   x0=0000000000000000  x1=00000000000457cb  x2=0000000000000006  x3=0000004000cfe860
   x4=0000000000000000  x5=0000000000000000  x6=0000000000000000  x7=0000000000000030
   x8=00000000000000f0  x9=00000040036ce5e0 x10=0000000000000000 x11=0000000000000001
  x12=0000000000000028 x13=29726f746365746f x14=00000000000007d8 x15=000000000003e820
  x16=000000400379c8c0 x17=0000004003779870 x18=0000004000e5e000 x19=00000000000000ac
  x20=00000000000457cb x21=00000000000000b2 x22=00000000000457cb x23=00000000ffffffff
  x24=000000400827a020 x25=0000000000000000 x26=0000000000000001 x27=000000408975afc8
  x28=000000000000fa08  FP=0000004000cfe910  LR=000000400372d330  SP=0000004000cfe840

==284619==ABORTING

Google has even started a Skia android Fuzzing repository:
https://github.com/googleprojectzero/SkCodecFuzzer

Samsung has acknowledged the findings and published a patch and a security
advisory linked below:
https://security.samsungmobile.com/securityUpdate.smsb

If you want to get started fuzzing with AFL you can get a copy of it here: https://lcamtuf.coredump.cx/afl/

Pick your favorite software, compile and run it throw AFL to find bugs :)

Side note:
Several people make a living as “Bug Bounty Hunters”, some software offer a
reward when you report bugs.
For a list of these software’s you can check out https://internetbugbounty.org/.

There are also commercial companies that stand between the founder and the
company as a middle man and take a large chunk of the cash such as hackerone
and bugcrowd.

External links:
https://packetstormsecurity.com/files/157620/Samsung-Android-Remote-Code-Execution.html
https://en.wikipedia.org/wiki/Fuzzing
https://owasp.org/www-community/Fuzzing
https://skia.org
https://en.wikipedia.org/wiki/Signal_(IPC)
https://cwe.mitre.org/data/definitions/787.html
https://en.wikipedia.org/wiki/Heap_overflow
https://en.wikipedia.org/wiki/Stack_buffer_overflow
https://vulns.firosolutions.com/cve/CVE-2020-8899/