Использование checkCallingOrSelfPermission () для атаки эскалации привилегий

Я проходил checkCallingOrSelfPermission () в классе Context и задавался вопросом, как его можно использовать; Т.е. если какое-либо приложение запускает метод вызываемого абонента / вашего приложения, которое в свою очередь вызывает checkCallingOrSelfPermission (), наконец, дает доступ к этому разрешению другому приложению или освобождает конфиденциальную информацию, которая в противном случае требовала бы этого разрешения.

Это то, что я понял после прохождения Java Doc:

Этот метод может использоваться только при использовании любого вызывающего приложения, которое находится в том же процессе приложения вызываемого абонента. Чтобы попасть в один и тот же процесс, приложения должны иметь один и тот же shareuserid и процесс в файле манифеста, а также подписываться одним и тем же сертификатом.

Поэтому вызывающее приложение должно выполнить следующее.

  1. Должен знать, под каким процессом и идентификатором shareuser запускается приложение callee. (Я не уверен, насколько это возможно?)

  2. Должна быть подписана с тем же сертификатом, с которым была подписана заявка на вызов (маловероятно, что сертификат сохранен в безопасности).

Является ли это методом эксплуатации, о котором предупреждает документация checkCallingOrSelfPermission (), или существуют другие (более реалистичные) способы его использования.

Я также проверил этот пост , но ответ был неудовлетворительным.

В нормальных условиях Binder.callingPid() == Process.myPid() . Это изменяется при обработке запроса IPC, система изменяет значение вызывающего PID, хранящееся Binder , оно присваивает его PID приложения-вызывающего. Однако это изменение влияет только на поток, где выполняется удаленный метод , а в других потоках равенство сохраняется. Поэтому, если checkCallingOrSelfPermission() вызывается в таком незатронутом потоке, он вернет PERMISSION_GRANTED (если сервисное приложение имеет это разрешение), и может произойти утечка (или другие библейские последствия).

В качестве альтернативы, если clearCallingIdentity() вызывается перед checkCallingOrSelfPermission() то может возникнуть checkCallingOrSelfPermission() та же проблема, хотя я считаю, что она менее вероятна.

Протестировано на Nexus 6P, Android 6.0.1 (MHC19I).

Все в коде.

CheckCallingOrSelfPermission () безопасен при вызове IPC. Проверьте реализацию checkCallingOrSelfPermission() и checkCallingPermission() здесь . Они оба проверяют разрешение клиента IPC / вызывающего. Когда вызывающий извне, они точно такие же!

Если вызывающий абонент изнутри (тот же процесс), ну, если кто-то может выполнить код внутри вашего процесса, он уже используется. Не нужно использовать checkCallingOrSelfPermission() раз.