The su request used by CyanogenMod 10. x can be hijacked. As a result, the normal request cannot be responded, and the app fails to escalate the permission. Although the writing vendor is CyanogenMod, this version of su may be used by many other ROM.
It is easy to analyze open-source code.
1. su directly uses the am command to send an Elevation of Privilege request to broadcast to superuser (root authorization management software). For the code, see
Https://github.com/CyanogenMod/android_system_su/blob/ics/activity.c
Sprintf (command, "(/system/bin/am broadcast-a '% s' -- es socket' % s' -- ei caller_uid '% d' -- ei allow' % d' -- ei version_code' % d '% s)> /dev/null ",
Action, socket_path, ctx-> from. uid, allow, VERSION_CODE,
Strcmp (action, ACTION_RESULT )? "":"&");
This broadcast does not verify the identity of the receiver, and am sends an ordered broadcast, so you can register a high-priority receiver to receive and terminate the broadcast.
Register the broadcast receiver FakeSuRequestReceiver
Receive and terminate broadcast
Public class FakeSuRequestReceiver extends BroadcastReceiver {
Public void onReceive (Context arg0, Intent arg1 ){
// Superuser will not have Ed the su request broadcast
// If we abort it here
AbortBroadcast ();
}
}
2. If the superuser does not receive the request for Elevation of Privilege, the root application of the app fails. For example, the active defense of LBE requires the root permission. After the elevation of permission fails, the active defense cannot be started, and malicious software behaviors cannot be discovered.
Broadcast hijacking is not a new problem. su and superuser are both open-source and not difficult to analyze. If you are interested, you can check the source code and easily reproduce it.
Solution:
Add permission protection for broadcast