Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Explorando checkCallingOrSelfPermission () para el ataque de escalado de privilegios

Yo estaba pasando por checkCallingOrSelfPermission () en la clase Context y me preguntaba cómo se puede explotar; Es decir, si alguna aplicación desencadena un método de la callee / su aplicación que a su vez llama a checkCallingOrSelfPermission (), finalmente dar acceso a ese permiso a la otra aplicación, o la liberación de información sensible que de otro modo requeriría que el permiso.

Esto es lo que entendí después de pasar por el Java Doc:

Este método sólo puede ser explotado por cualquier aplicación de llamada que esté en el mismo proceso de aplicación de callee. Para entrar en el mismo proceso ambas aplicaciones necesitan tener el mismo shareuserid y proceso en el archivo de manifiesto, además de estar firmado por el mismo certificado.

Así que la aplicación que llama tiene que hacer lo siguiente.

  1. Tiene que saber en qué proceso y el ID de usuario compartido se está ejecutando la aplicación del receptor. (No estoy seguro de lo factible que es esto?)

  2. Tiene que ser firmado con el mismo certificado con el que se firmó la solicitud de callee (improbable suponiendo que el certificado se mantenga seguro).

¿Es este el método de explotación que la documentación checkCallingOrSelfPermission () es una advertencia contra, o hay otras maneras (más realistas) de que podría ser explotada.

También he comprobado este post , pero la respuesta no fue satisfactoria.

  • ¿Cómo detectar el cambio de estado Bluetooth con un receptor de difusión?
  • Android revoca el permiso al inicio de cada prueba
  • "No se puede cambiar la configuración privada de seguridad" - ¿cómo cambiar la vibración del tono de llamada en Android 6?
  • Intención FLAG_GRANT_READ_URI_PERMISSION Uso de FileProvider en Gingerbread
  • Permiso denegado (¿falta el permiso de INTERNET?): Pero se da permiso
  • No se puede resolver el símbolo Manifest.permission.READ_PHONE_STATE
  • Solicitar permiso en Android M sólo cuando se apunta a una API inferior
  • OnCreate () se llama cuando se vuelve a abrir desde una tarea reciente después de cambiar la configuración del permiso
  • 2 Solutions collect form web for “Explorando checkCallingOrSelfPermission () para el ataque de escalado de privilegios”

    En circunstancias normales Binder.callingPid() == Process.myPid() mantiene. Esto cambia al manejar una solicitud IPC, el sistema modifica el valor PID de llamada almacenado por Binder , lo asigna al PID de la aplicación llamante. Sin embargo, este cambio sólo afecta al subproceso donde se ejecuta el método denominado remotelly , en otros subprocesos la igualdad todavía se mantiene. Por lo tanto, si checkCallingOrSelfPermission() se llama en un hilo no afectado, devolverá PERMISSION_GRANTED (siempre que la aplicación de servicio contenga ese permiso) y se pueda producir una pérdida (u otras consecuencias bíblicas).

    Alternativamente, si clearCallingIdentity() se llama antes de checkCallingOrSelfPermission() el mismo problema puede surgir, aunque creo que es menos probable que suceda.

    Probado en Nexus 6P, Android 6.0.1 (MHC19I).

    Todo está en el código.

    El checkCallingOrSelfPermission () es seguro en la llamada IPC. Compruebe la implementación de checkCallingOrSelfPermission() y checkCallingPermission() aquí . Ambos revisan el permiso del cliente IPC / la persona que llama. Cuando la persona que llama es de fuera, son exactamente iguales!

    Si el llamador es de dentro (el mismo proceso), bueno, si alguien puede ejecutar código dentro de su proceso, ya está explotado. No es necesario explotar el uso checkCallingOrSelfPermission() nuevo.

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.