¿Qué implicaciones de seguridad tiene tener un gestor de arranque desbloqueado?

En resumen: Todas(?) las recuperaciones actuales de terceros son inseguras, es decir, ofrecen instalar los update.zip sin comprobar sus firmas. Además, ejecutan un proceso Root adbd, que posteriormente puede ser utilizado para extraer/cambiar datos sin autenticación. Las recuperaciones de stock sólo permiten update.zip's firmados y no ofrecen adb. Ah, y a veces no te dejan hacer un downgrade a una versión anterior (quizás insegura) aunque la firma del .zip esté bien. Ah, por cierto: puedes entrar en el recovery reiniciando el teléfono pulsando alguna combinación de botones.

@ce4 ¿Entonces cómo es que he rooteado mi dispositivo usando el recovery de stock? ¿Esta explotando un bug del recovery o esta legítimamente firmado? Si está explotando un bug, entonces es tan inseguro como cualquier otro firmware, ¿no? Y si está firmado, bueno, ¿para qué sirve entonces la firma?

Sólo se pueden hacer conjeturas (sin conocer su modelo): ¿Tu teléfono tiene un recovery de stock inseguro?

@ce4 Puede ser, es un Samsung Galaxy Fit por cierto. Y acabo de comprobarlo: CWM 5 tiene una opción para activar la verificación de firmas, pero estaba desactivada por defecto y nunca me había fijado en ella hasta ahora. Y el flasheo de CM nocturno mientras está encendido funcionó como siempre... Esto es raro! pero interesante :D

Ok, Samsung es otra historia, tienen bootloaders desbloqueados en general (todos los dispositivos de compra libre y la mayoría de operador subvencionados, excepto VZN). Y tampoco tienen fastboot, sino flashmode/odin-mode (o como se llame). Además: CWM es un recovery personalizado, que muy probablemente instalaste tú mismo usando Heimdall/Odin (en Flashmode), ¿no? CWM sólo lo instalan los usuarios finales para hacer modding.

@ce4: Los firmwares personalizados, con Root habilitado, como escribiste, son capaces de actualizar /system arrancando en un custom recovery flasheado temporalmente, obviando la necesidad de desbloquear el bootloader, evitándote el habitual desbloqueo del bootloader, el borrado de /datos y la restauración de la copia de seguridad. ¿Pero qué pasa si estás en una rom personalizada con el Root deshabilitado (leí que esto es posible, incluso común, es decir, el nuevo cyanogenmod)? Entonces no puedes hacer este bypass en el dispositivo. ¿Solución para esto?

Todavía se puede utilizar el método de "adb backup" (necesita pin) para obtener los datos de la aplicación del dispositivo, utilizar Airdroid o MTP para hacer una copia de seguridad del contenido de la sdcard, a continuación, desbloquear el BL de nuevo (haciendo un wipe) y volver a instalar una recuperación personalizada / o ROM.

Una información importante: La copia de seguridad adb sin root no hace una copia de seguridad de las características clave de telefonía (contactos, registro de llamadas, sms, ) como yo probado . La pregunta es si la copia de seguridad adb rooteado tira más que la no rooteado. Si no, necesito copias de seguridad Nandroid, y la pregunta es si estas se pueden hacer desde el sistema rooteado en vivo o sólo dentro del modo de recuperación? Esto último significaría, flashear un custom recovery temporal, hacer una copia de seguridad en un medio externo, que reiniciar y restaurar el stock recovery y el bootloader bloqueado. Todo un esfuerzo.

Otra razón por la que CWM como recuperación permanente para CM es inseguro: Cuando se restaura desde una copia de seguridad, la seguridad del keyguard se restablece (patrón en mi caso). Supongo que esto es por diseño, para que un usuario no se bloquee a sí mismo, si él/ella no puede recordar su antiguo patrón/pin/contraseña. ¡Entonces el atacante no tiene los datos más recientes, pero al menos el estado de la copia de seguridad, y si contiene cuentas en la nube, entonces gran parte del contenido actual puede ser simplemente recuperado! ¡Un aspecto más de que un CWM permanente es inseguro!

@ce4: Primero volví a bloquear el bootloader desde el ordenador a través de fastboot oem lock , luego en el propio dispositivo Android quería volver a flashear el recovery de stock. Dispositivo Android > Terminal su concedido, entonces flash_image recovery /storage/emulated/0/sw/stock-roms/yakju-jwr66y/recovery.img falló con el error can't find recovery partition failed with error: -1 . Parecía ilógico: si permite instalar un recovery personalizado, entonces por qué no el recovery de stock. O flash_image recovery recovery.img ¿no fue todo el procedimiento? Volverá a solicitarlo oem unlock (aceptar la limpieza adjunta) y luego adb restore .

@ce4: Después de eso hice adb oem lock y en el dispositivo su la concedió, whoami me confirmó como root entonces flash_image recovery /storage/emulated/0/sw/custom-recoveries/recovery-clockwork-‌​6.0.1.5-maguro.img Esto falló con error opening /storage/emulated/0/sw/custom-recoveries/recovery-clockwork-‌​6.0.1.5-maguro.img failed with error: -1 . Siendo Root, creo que los problemas de permisos se pueden solucionar. ¿Qué más ha fallado?

Puede ser grupos de montaje por usuario / selinux habilitado en 4.3 que está causando esto. Voy a echar un vistazo .... (Actualmente sólo en mi móvil)

@ce4: Mi CM 10.1.3 instalado es Android 4.2.2. ¿Alguna idea ya de cómo flashear un recovery temporal desde este dispositivo, con su bootloader bloqueado y el stock recovery? Si no, tengo que desbloquear (¡wipe!), flashear custom recovery, actualizar CM, restaurar.

Intenta arrancar el custom recovery usando kexec o haz una copia de seguridad de tus datos usando Titanium Backup (y copia el contenido de la sdcard a mano) o adb backup antes de hacer el wipe.

Si hay un flash_image que funcione podrías usarlo para instalar cwm también

¿Podré instalar el recovery de stock, volver a bloquear mi BL, y todavía ser capaz de flashear imágenes del sistema (Google Factory Images) y Root sin sistema desde el sistema en ejecución? PS. Dispositivo Nexus, ROM stock rooteado.

¿Significa esto que los riesgos son reales sólo si alguien se hace con el dispositivo?

Más o menos, se llama ataque de criada malvada. Ver schneier.com/blog/archives/2009/10/evil_maid_attac.html