[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
DEVELOPMENT PROGRESS / CHANGE LOG

26-05-2018 started this thread listing vulnerabilities found during many weeks of research done right after buy of my XZ1c phone

06-06-2018 post#7: managed to boot kernel from the 47.1.A.2.281 fw in qemu

16-06-2018 post#25: simple out of bounds overwrite not useful, complex exploiting of use after free needed

02-07-2018 post#33: explained how use after free exploit would work, but timing is impossible: kfree from rcu too late

06-07-2018 post#44 and post#48: more details about exploiting use after free and kfree_rcu too late kfree timing problem

17-07-2018 post#53: first kernel to test timing, did not boot when tried with unlocked xz1c

27-07-2018 post#73: solved the problem with delayed kfree from kfree_rcu, basic inotify/rename proof of concept running in qemu for long filenames

27-07-2018 post#75: found a way to build xz1c kernel from source which can be booted on unlocked xz1c, confirmed the delayed kfree from rcu timing problem

11-08-2018 post#88: extensive testing of timing

20-08-2018 post#104: inotify/rename exploit now works with long filenames, allowing kernel heap (256 bytes slub unit) overflow, overview of next phases of the exploit yet to be implemented

31-08-2018 post#118: implemented mostly arbitrary kernel write _together_ with mostly arbitrary kernel read, first bypass of KASLR but we need to bypass PXN & PAN too

15-09-2018 post#131: found that we will need ROP/JOP gadgets to overcome PXN & PAN oreo mitigations, more details in post#135

22-09-2018 post#137: first arbitrary kernel space read and write proof of concept working in qemu

22-09-2018 post#138: with great timing luck kernel space R/W poc worked on still locked xz1c

05-10-2018 post#146: first backup of my xz1c locked TA done: asking for an unlock-and-TA-restore test volunteer

07-10-2018 post#151: confirmed that BL unlock removed 66667 unit - device master key?

18-10-2018 post#162: exploit not reliable enough for public use yet

22-10-2018 post#165: renoroot preview video, send initial test version to [MENTION=5677791]tramtrist[/MENTION]

22-10-2018 post#168: renoroot initial test results - after TA restore camera works, BL remains unlocked

25-10-2018 post#185: more initial test results directly from [MENTION=5677791]tramtrist[/MENTION]

28-10-2018 post#199: researched possible uses of various keys from security service menu

03-11-2018 post#206: renoroot temp root including tools and howto for TA partition (drm keys) backup released, put everything on the first page

05-11-2018 post#235: renoroot confirmed working with other phone models

10-11-2018 post#287: ordered a new xz1c just for testing and development work

18-11-2018 post#348: the new xz1c arrived

22-11-2018 post#372: a persistent root from a temp root possibility - but not with selinux

11-12-2018 post#428: possibly the fastest temp root - 6.03 seconds with just 53 events and 1 overwrite

05-01-2019 post#493: explained about TA restore not re-locking bootloader - good for us!

09-01-2019 post#515: intercept BL unlock of xz1c in the middle of the procedure

10-01-2019 post#516: posted few videos to highlight key points when preparing for unlock with backup of TA via renoroot temproot

10-01-2019 post#517: video showing xz1c bl unlock with twrp booted in the middle

11-01-2019 post#520: howto for unlock with the twrp booted in the middle

19-01-2019 post#602: info about test to write dev master key TA unit from the secd process

30-01-2019 post#620: info about TA restore and various drm keys

02-02-2019 post#623: preview of FOTA system update fully installed with unlocked and rooted XZ1c - it confirms all functionality of a locked phone have been restored

05-02-2019 post#633: tested fota system update from oreo to pie - posted a video

10-02-2019 post#645: kernels hiding bootloader unlock released for XZ1c/XZ1/XZp - with locked TA restored this brings root with all locked phone functionality of stock fw restored

16-02-2019 post#652: ported BL unlock hiding patch to TAMA platform for testing with XZ2 (it worked, but cannot be booted via fastboot due to bug in bootloader according to sony /more details here/)

19-02-2019 post#663: patched XZ2 kernel to make it boot via 'fastboot boot' command from usb (tested successfully by [MENTION=3989065]serajr[/MENTION] post#664) - shall be useful for twrp setup on TAMA platform (post#668 by [MENTION=6031898]MartinX3[/MENTION])

19-02-2019 post#672: fota system update with my rooted kernels verified with XZ2 phone by [MENTION=3989065]serajr[/MENTION] - so we may have fota system update with root on xz2/xz2c/xz2p/xz3 phones too (theoretically)

---->> moved the original opening post in here ----

Downgrade XZ1 Compact to 47.1.A.2.281 firmware version (not sure if this downgrade is safe, see android-attest-key-lost thread here please). The 47.1.A.2.324_CE1 version might be better to try first.

The 2.281 fw results with android security patch level 2017-08-05, kernel 4.4.74, android oreo.

BlueBorne vulnerabilities are not patched yet with this firmware:

CVE-2017-0785 Android information leak vulnerability PoC seems to work - tested myself.

Not sure, but it seems that bluetooth service is not a 32bit process anymore, contrary the note in BlueBorne whitepaper /The​ ​Bluetooth​ ​service​ ​in​ ​Android​ ​runs​ ​under​ ​Zygote​ ​(Android​ ​service​ ​manager),​ ​and​ ​is surprisingly​ ​a​ ​32-bit​ ​process​ ​(even​ ​when​ ​the​ ​OS​ ​and​ ​CPU​ ​are​ ​ARM-64​ ​for​ ​instance/ - example of stack dump obtained:

000000b0 00 00 00 00 ff ff ff fd ff ff ff ff d8 69 f4 80 │····│····│····│·i··│
000000c0 00 00 00 73 e8 60 0c 10 00 00 00 73 e8 60 01 40 │···s│·`··│···s│·`·@│
000000d0 00 00 00 73 d8 6b 20 08 00 00 00 73 e8 69 06 d0 │···s│·k ·│···s│·i··│
...
000007e0 00 00 00 73 2c 32 34 38 72 68 74 20 20 64 61 65 │···s│,248│rht │ dae│
000007f0 65 6d 61 6e 5f 74 62 20 6b 72 6f 77 75 65 75 71 │eman│_tb │krow│ueuq│
00000800 74 73 20 65 65 74 72 61 00 00 00 64 00 00 00 00 │ts e│etra│···d│····│

Those '00 00 00 73' are often present, quite possibly the upper 32bit part of a 64bit pointer. The text at 7e8 may be something like 'thread name bt_workqueue started', possibly indicating the CVE-2017-078 PoC worked (modified so that 'n = 90' to receive more data).

The first idea was to make the Android BlueBorne exploit working to obtain bluetooth service credentails and use that with some kernel exploit to switch to root in order to finally do TA partition backup (to save DRM keys).

The bluetooth user seems to have the NET_ADMIN capability, that could be very useful.

I've researched further possible kernel exploits and it seems to me that the kernel from 2.281 firmware seems to contain (at least) following vulnerabilities:

CVE-2017-7308 AF_PACKET packet_set_ring

This needs NET_RAW capability, that may be hard to obtain, bluetooth service seems not to have it.

CVE-2017-7533 race between inotify_handle_event() and vfs_rename()

https://exploit.kitploit.com/2017/08/linux-kernel-412-race-condition.html

This may work as a standalone exploit - checked the kernel source - vulnerability is not fixed, not sure about SElinux limitations and other android security mitigations - please discuss this.

Found only demo poc not getting root, but it may be possibly developed to full temp root standalone exploit.

This currently seems to be the most promising.

CVE-2017-1000112 memory corruption in UDP fragmentation offload

https://securingtomorrow.mcafee.com...vilege-escalation-analyzing-cve-2017-1000112/

https://ricklarabee.blogspot.cz/2017/12/adapting-poc-for-cve-2017-1000112-to.html

https://www.exploit-db.com/exploits/43418/

This could be used after BlueBorne done, as it needs NET_ADMIN capability.

HELP NEEDED PLEASE - let's collaborate and develop together the needed exploits!

For example it is hard for me to develop only with a locked device, better debugging may be possible on stock firmware with unlocked bootloader as some modifications may be flashed. My free time is quite limitted, so it would be useful to split the work.

----<< moved the original opening post in here ----

It seems that 'CVE-2017-7533 race between inotify_handle_event() and vfs_rename()' is not possible to trigger from adb shell - possibly some android security mitigations/selinux limitation?

Built exploit.c from CVE-2017-7533 with attached View attachment 4510875 android makefiles, adb pushed to /data/local/tmp:

G8441:/ $ uname -a
Linux localhost 4.4.74-perf+ #1 SMP PREEMPT Wed Aug 9 16:09:57 2017 aarch64
G8441:/ $ cd /data/local/tmp
G8441:/data/local/tmp $ ./exploit 2>err.log
Listening for events.
Listening for events.
alloc_len : 50
longname="test_dir/bbbb32103210321032100��1����test_dir/bbbb3210321032103210"
alloc_len : 50
callrename done.
G8441:/data/local/tmp $

the notify events seem not to be received:(

The rename function works in the exploit (tested separately), but many errors such as

rename1: No such file or directory

rename2: No such file or directory

are returned from the exploit though.

The inotify_init1 function returns valid fd, so it looks like everything is ok, but for unknown reason, inotify events are not received.

Running the same code in linux with vulnerable kernel results with this:

Linux 4.8.0 #1 SMP Tue Oct 25 09:09:01 UTC 2016 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux

Listening for events.
Listening for events.
alloc_len : 50
longname="test_dir/bbbb32103210321032100ÿÿ1ÿÿÿÿ"
handle_events() event->name : bbbb32103210321032100ÿÿ1ÿÿÿÿ, event->len : 32
handle_events() event->name : b, event->len : 16
Detected overwrite!!!
callrename done.
alloc_len : 50

Note the 'handle_events' log message presence - that indicates receive of inotify event. The rename errors are not returned in this case.

That means even though the kernel is vulnerable (as verified in sony release source code - it is fixed since 47.1.A.12.34 version as can be seen with 'git log --stat -p origin/47.1.A.12.xxx -- fs/dcache.c' in sony's kernel git repository), it looks like we cannot trigger the bug simply from adb shell.

This is what is configured in the kernel (using sony's build instructions):

CONFIG_FSNOTIFY=y

CONFIG_DNOTIFY=y

CONFIG_INOTIFY_USER=y

# CONFIG_FANOTIFY is not set

Am I missing something? Any idea why the bug cannot be triggered?

--previous edit-- 27-05-2018 at 22:58. Reason: added info about rename() on xz1c; added info about inotify_init1() on xz1c; added info about 1st fw version with a fix and relevant kernel config options