Mejoras de seguridad

Android mejora continuamente sus capacidades y ofertas de seguridad. Vea las listas de mejoras por lanzamiento en la navegación izquierda.

Androide 14

Cada versión de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Estas son algunas de las principales mejoras de seguridad disponibles en Android 14:

  • AddressSanitizer asistido por hardware (HWASan), introducido en Android 10, es una herramienta de detección de errores de memoria similar a AddressSanitizer . Android 14 trae mejoras significativas a HWASan. Descubra cómo ayuda a evitar que aparezcan errores en las versiones de Android, HWAddressSanitizer
  • En Android 14, comenzando con las aplicaciones que comparten datos de ubicación con terceros, el cuadro de diálogo de permisos de tiempo de ejecución del sistema ahora incluye una sección en la que se puede hacer clic que resalta las prácticas de intercambio de datos de la aplicación, incluida información como por qué una aplicación puede decidir compartir datos con terceros. .
  • Android 12 introdujo una opción para desactivar la compatibilidad con 2G a nivel de módem, lo que protege a los usuarios del riesgo de seguridad inherente del modelo de seguridad obsoleto de 2G. Al reconocer lo crítico que podría ser deshabilitar 2G para los clientes empresariales, Android 14 habilita esta característica de seguridad en Android Enterprise, presentando soporte para que los administradores de TI restrinjan la capacidad de un dispositivo administrado para cambiar a conectividad 2G .
  • Se agregó soporte para rechazar conexiones celulares con cifrado nulo, lo que garantiza que el tráfico de voz y SMS con conmutación de circuitos esté siempre cifrado y protegido contra la interceptación inalámbrica pasiva. Conoce más sobre el programa de Android para reforzar la conectividad celular .
  • Se agregó soporte para múltiples IMEI.
  • Desde Android 14, AES-HCTR2 es el modo preferido de cifrado de nombres de archivos para dispositivos con instrucciones de criptografía acelerada.
  • Conectividad celular
  • Documentación agregada para el Centro de seguridad de Android
  • Si su aplicación está orientada a Android 14 y utiliza carga dinámica de código (DCL), todos los archivos cargados dinámicamente deben marcarse como de solo lectura. De lo contrario, el sistema genera una excepción. Recomendamos que las aplicaciones eviten cargar código dinámicamente siempre que sea posible, ya que hacerlo aumenta en gran medida el riesgo de que una aplicación pueda verse comprometida por inyección de código o manipulación de código.

Consulte nuestras notas de la versión completa de AOSP y la lista de cambios y funciones para desarrolladores de Android.

androide 13

Cada versión de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Estas son algunas de las principales mejoras de seguridad disponibles en Android 13:

  • Android 13 agrega soporte para presentaciones de múltiples documentos. Esta nueva interfaz de sesión de presentación permite que una aplicación realice una presentación de múltiples documentos, algo que no es posible con la API existente. Para obtener más información, consulte Credencial de identidad.
  • En Android 13, las intenciones que se originan en aplicaciones externas se entregan a un componente exportado si y solo si las intenciones coinciden con sus elementos de filtro de intenciones declarados.
  • Open Mobile API (OMAPI) es una API estándar que se utiliza para comunicarse con el elemento seguro de un dispositivo. Antes de Android 13, solo las aplicaciones y los módulos del marco tenían acceso a esta interfaz. Al convertirlo en una interfaz estable del proveedor, los módulos HAL también son capaces de comunicarse con los elementos seguros a través del servicio OMAPI. Para obtener más información, consulte Interfaz estable del proveedor OMAPI .
  • A partir de Android 13-QPR, los UID compartidos están en desuso. Los usuarios de Android 13 o superior deben poner la línea `android:sharedUserMaxSdkVersion="32"` en su manifiesto. Esta entrada evita que los nuevos usuarios obtengan un UID compartido. Para obtener más información sobre los UID, consulte Firma de aplicaciones .
  • Android 13 agregó compatibilidad con primitivas criptográficas simétricas del almacén de claves, como AES (estándar de cifrado avanzado), HMAC (código de autenticación de mensajes hash con clave) y algoritmos criptográficos asimétricos (incluidos Elliptic Curve, RSA2048, RSA4096 y Curve 25519).
  • Android 13 (nivel de API 33) y versiones posteriores admiten un permiso de tiempo de ejecución para enviar notificaciones no exentas desde una aplicación . Esto les da a los usuarios control sobre qué notificaciones de permisos ven.
  • Se agregó un mensaje por uso para las aplicaciones que solicitan acceso a todos los registros del dispositivo , lo que brinda a los usuarios la posibilidad de permitir o denegar el acceso.
  • introdujo el Android Virtualization Framework (AVF) , que reúne diferentes hipervisores bajo un marco con API estandarizadas. Proporciona entornos de ejecución seguros y privados para ejecutar cargas de trabajo aisladas por hipervisor.
  • Se introdujo el esquema de firma APK v3.1. Todas las rotaciones de claves nuevas que utilizan apksigner utilizarán el esquema de firma v3.1 de forma predeterminada para apuntar a la rotación para Android 13 y versiones posteriores.

Consulte nuestras notas de la versión completa de AOSP y la lista de cambios y funciones para desarrolladores de Android.

androide 12

Cada versión de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Estas son algunas de las principales mejoras de seguridad disponibles en Android 12:

  • Android 12 presenta la API BiometricManager.Strings , que proporciona cadenas localizadas para aplicaciones que usan BiometricPrompt para la autenticación. Estas cadenas están destinadas a reconocer el dispositivo y proporcionar más especificidad sobre qué tipo(s) de autenticación se pueden usar. Android 12 también incluye soporte para sensores de huellas dactilares debajo de la pantalla
  • Se agregó soporte para sensores de huellas dactilares debajo de la pantalla
  • Introducción del lenguaje de definición de interfaz de Android de huellas dactilares (AIDL)
  • Soporte para el nuevo Face AIDL
  • Introducción de Rust como lenguaje para el desarrollo de plataformas.
  • Se agregó la opción para que los usuarios otorguen acceso solo a su ubicación aproximada.
  • Se agregaron indicadores de privacidad en la barra de estado cuando una aplicación está usando la cámara o el micrófono.
  • Núcleo de cómputo privado (PCC) de Android
  • Se agregó una opción para desactivar el soporte 2G.

androide 11

Cada versión de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Para obtener una lista de algunas de las principales mejoras de seguridad disponibles en Android 11, consulte las Notas de la versión de Android .

androide 10

Every Android release includes dozens of security enhancements to protect users. Android 10 includes several security and privacy enhancements. See the Android 10 release notes for a complete list of changes in Android 10.

Security

BoundsSanitizer

Android 10 deploys BoundsSanitizer (BoundSan) in Bluetooth and codecs. BoundSan uses UBSan's bounds sanitizer. This mitigation is enabled on a per-module level. It helps keep critical components of Android secure and shouldn't be disabled. BoundSan is enabled in the following codecs:

  • libFLAC
  • libavcdec
  • libavcenc
  • libhevcdec
  • libmpeg2
  • libopus
  • libvpx
  • libspeexresampler
  • libvorbisidec
  • libaac
  • libxaac

Execute-only memory

By default, executable code sections for AArch64 system binaries are marked execute-only (nonreadable) as a hardening mitigation against just-in-time code reuse attacks. Code that mixes data and code together and code that purposefully inspects these sections (without first remapping the memory segments as readable) no longer functions. Apps with a target SDK of Android 10 (API level 29 or higher) are impacted if the app attempts to read code sections of execute-only memory (XOM) enabled system libraries in memory without first marking the section as readable.

Extended access

Trust agents, the underlying mechanism used by tertiary authentication mechanisms such as Smart Lock, can only extend unlock in Android 10. Trust agents can no longer unlock a locked device and can only keep a device unlocked for a maximum of four hours.

Face authentication

Face authentication allows users to unlock their device simply by looking at the front of their device. Android 10 adds support for a new face authentication stack that can securely process camera frames, preserving security and privacy during face authentication on supported hardware. Android 10 also provides an easy way for security-compliant implementations to enable app integration for transactions such as online banking or other services.

Integer Overflow Sanitization

Android 10 enables Integer Overflow Sanitization (IntSan) in software codecs. Ensure that playback performance is acceptable for any codecs that aren't supported in the device's hardware. IntSan is enabled in the following codecs:

  • libFLAC
  • libavcdec
  • libavcenc
  • libhevcdec
  • libmpeg2
  • libopus
  • libvpx
  • libspeexresampler
  • libvorbisidec

Modular system components

Android 10 modularizes some Android system components and enables them to be updated outside of the normal Android release cycle. Some modules include:

OEMCrypto

Android 10 uses OEMCrypto API version 15.

Scudo

Scudo is a dynamic user-mode memory allocator designed to be more resilient against heap-related vulnerabilities. It provides the standard C allocation and deallocation primitives, as well as the C++ primitives.

ShadowCallStack

ShadowCallStack (SCS) is an LLVM instrumentation mode that protects against return address overwrites (like stack buffer overflows) by saving a function's return address to a separately allocated ShadowCallStack instance in the function prolog of nonleaf functions and loading the return address from the ShadowCallStack instance in the function epilog.

WPA3 and Wi-Fi Enhanced Open

Android 10 adds support for the Wi-Fi Protected Access 3 (WPA3) and Wi-Fi Enhanced Open security standards to provide better privacy and robustness against known attacks.

Privacy

App access when targeting Android 9 or lower

If your app runs on Android 10 or higher but targets Android 9 (API level 28) or lower, the platform applies the following behavior:

  • If your app declares a <uses-permission> element for either ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION, the system automatically adds a <uses-permission> element for ACCESS_BACKGROUND_LOCATION during installation.
  • If your app requests either ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION, the system automatically adds ACCESS_BACKGROUND_LOCATION to the request.

Background activity restrictions

Starting in Android 10, the system places restrictions on starting activities from the background. This behavior change helps minimize interruptions for the user and keeps the user more in control of what's shown on their screen. As long as your app starts activities as a direct result of user interaction, your app most likely isn't affected by these restrictions.
To learn more about the recommended alternative to starting activities from the background, see the guide on how to alert users of time-sensitive events in your app.

Camera metadata

Android 10 changes the breadth of information that the getCameraCharacteristics() method returns by default. In particular, your app must have the CAMERA permission in order to access potentially device-specific metadata that is included in this method's return value.
To learn more about these changes, see the section about camera fields that require permission.

Clipboard data

Unless your app is the default input method editor (IME) or is the app that currently has focus, your app cannot access clipboard data on Android 10 or higher.

Device location

To support the additional control that users have over an app's access to location information, Android 10 introduces the ACCESS_BACKGROUND_LOCATION permission.
Unlike the ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION permissions, the ACCESS_BACKGROUND_LOCATION permission only affects an app's access to location when it runs in the background. An app is considered to be accessing location in the background unless one of the following conditions is satisfied:

  • An activity belonging to the app is visible.
  • The app is running a foreground service that has declared a foreground service type of location.
    To declare the foreground service type for a service in your app, set your app's targetSdkVersion or compileSdkVersion to 29 or higher. Learn more about how foreground services can continue user-initiated actions that require access to location.

External storage

By default, apps targeting Android 10 and higher are given scoped access into external storage, or scoped storage. Such apps can see the following types of files within an external storage device without needing to request any storage-related user permissions:

To learn more about scoped storage, as well as how to share, access, and modify files that are saved on external storage devices, see the guides on how to manage files in external storage and access and modify media files.

MAC address randomization

On devices that run Android 10 or higher, the system transmits randomized MAC addresses by default.
If your app handles an enterprise use case, the platform provides APIs for several operations related to MAC addresses:

  • Obtain randomized MAC address: Device owner apps and profile owner apps can retrieve the randomized MAC address assigned to a specific network by calling getRandomizedMacAddress().
  • Obtain actual, factory MAC address: Device owner apps can retrieve a device's actual hardware MAC address by calling getWifiMacAddress(). This method is useful for tracking fleets of devices.

Non-resettable device identifiers

Starting in Android 10, apps must have the READ_PRIVILEGED_PHONE_STATE privileged permission in order to access the device's non-resettable identifiers, which include both IMEI and serial number.

If your app doesn't have the permission and you try asking for information about non-resettable identifiers anyway, the platform's response varies based on target SDK version:

  • If your app targets Android 10 or higher, a SecurityException occurs.
  • If your app targets Android 9 (API level 28) or lower, the method returns null or placeholder data if the app has the READ_PHONE_STATE permission. Otherwise, a SecurityException occurs.

Physical activity recognition

Android 10 introduces the android.permission.ACTIVITY_RECOGNITION runtime permission for apps that need to detect the user's step count or classify the user's physical activity, such as walking, biking, or moving in a vehicle. This is designed to give users visibility of how device sensor data is used in Settings.
Some libraries within Google Play services, such as the Activity Recognition API and the Google Fit API, don't provide results unless the user has granted your app this permission.
The only built-in sensors on the device that require you to declare this permission are the step counter and step detector sensors.
If your app targets Android 9 (API level 28) or lower, the system auto-grants the android.permission.ACTIVITY_RECOGNITION permission to your app, as needed, if your app satisfies each of the following conditions:

  • The manifest file includes the com.google.android.gms.permission.ACTIVITY_RECOGNITION permission.
  • The manifest file doesn't include the android.permission.ACTIVITY_RECOGNITION permission.

If the system-auto grants the android.permission.ACTIVITY_RECOGNITION permission, your app retains the permission after you update your app to target Android 10. However, the user can revoke this permission at any time in system settings.

/proc/net filesystem restrictions

On devices that run Android 10 or higher, apps cannot access /proc/net, which includes information about a device's network state. Apps that need access to this information, such as VPNs, should use the NetworkStatsManager or ConnectivityManager class.

Permission groups removed from UI

As of Android 10, apps cannot look up how permissions are grouped in the UI.

Removal of contacts affinity

Starting in Android 10, the platform doesn't keep track of contacts affinity information. As a result, if your app conducts a search on the user's contacts, the results aren't ordered by frequency of interaction.
The guide about ContactsProvider contains a notice describing the specific fields and methods that are obsolete on all devices starting in Android 10.

Restricted access to screen contents

To protect users' screen contents, Android 10 prevents silent access to the device's screen contents by changing the scope of the READ_FRAME_BUFFER, CAPTURE_VIDEO_OUTPUT, and CAPTURE_SECURE_VIDEO_OUTPUT permissions. As of Android 10, these permissions are signature-access only.
Apps that need to access the device's screen contents should use the MediaProjection API, which displays a prompt asking the user to provide consent.

USB device serial number

If your app targets Android 10 or higher, your app cannot read the serial number until the user has granted your app permission to access the USB device or accessory.
To learn more about working with USB devices, see the guide on how to configure USB hosts.

Wi-Fi

Apps targeting Android 10 or higher cannot enable or disable Wi-Fi. The WifiManager.setWifiEnabled() method always returns false.
If you need to prompt users to enable and disable Wi-Fi, use a settings panel.

Restrictions on direct access to configured Wi-Fi networks

To protect user privacy, manual configuration of the list of Wi-Fi networks is restricted to system apps and device policy controllers (DPCs). A given DPC can be either the device owner or the profile owner.
If your app targets Android 10 or higher, and it isn't a system app or a DPC, then the following methods don't return useful data:

androide 9

Cada versión de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Para obtener una lista de algunas de las principales mejoras de seguridad disponibles en Android 9, consulte las Notas de la versión de Android .

androide 8

Cada versión de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Estas son algunas de las principales mejoras de seguridad disponibles en Android 8.0:

  • Cifrado Se agregó soporte para desalojar la clave en el perfil de trabajo.
  • Arranque verificado . Se agregó el arranque verificado de Android (AVB). Base de código de arranque verificada que admite la protección de reversión para su uso en cargadores de arranque agregados a AOSP. Recomiende la compatibilidad con el cargador de arranque para la protección de reversión para HLOS. Los cargadores de arranque recomendados solo pueden ser desbloqueados por el usuario que interactúa físicamente con el dispositivo.
  • pantalla de bloqueo Se agregó soporte para usar hardware resistente a manipulaciones para verificar la credencial de la pantalla de bloqueo.
  • Almacén de claves . Certificación de clave requerida para todos los dispositivos que se envían con Android 8.0+. Se agregó soporte de atestación de ID para mejorar la inscripción Zero Touch.
  • Caja de arena . Agrupó de forma más estricta muchos componentes utilizando la interfaz estándar de Project Treble entre el marco y los componentes específicos del dispositivo. Se aplicó el filtrado seccomp a todas las aplicaciones que no son de confianza para reducir la superficie de ataque del kernel. WebView ahora se ejecuta en un proceso aislado con acceso muy limitado al resto del sistema.
  • Endurecimiento del núcleo . Copia de usuario reforzada implementada , emulación PAN, solo lectura después del inicio y KASLR.
  • Endurecimiento del espacio de usuario . CFI implementado para la pila de medios. Las superposiciones de aplicaciones ya no pueden cubrir las ventanas críticas del sistema y los usuarios tienen una forma de descartarlas.
  • Actualización del sistema operativo de transmisión . Actualizaciones habilitadas en dispositivos que tienen poco espacio en disco.
  • Instalar aplicaciones desconocidas . Los usuarios deben otorgar permiso para instalar aplicaciones desde una fuente que no sea una tienda de aplicaciones propia.
  • privacidad Android ID (SSAID) tiene un valor diferente para cada aplicación y cada usuario en el dispositivo. Para aplicaciones de navegador web, Widevine Client ID devuelve un valor diferente para cada nombre de paquete de aplicación y origen web. net.hostname ahora está vacío y el cliente dhcp ya no envía un nombre de host. android.os.Build.SERIAL se reemplazó con la API Build.SERIAL que está protegida por un permiso controlado por el usuario. Aleatorización de direcciones MAC mejorada en algunos conjuntos de chips.

androide 7

Cada versión de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Estas son algunas de las principales mejoras de seguridad disponibles en Android 7.0:

  • Cifrado basado en archivos . El cifrado a nivel de archivo, en lugar de cifrar toda el área de almacenamiento como una sola unidad, aísla y protege mejor a los usuarios y perfiles individuales (como el personal y el trabajo) en un dispositivo.
  • Arranque directo . Habilitado por el cifrado basado en archivos, Direct Boot permite que ciertas aplicaciones, como el despertador y las funciones de accesibilidad, se ejecuten cuando el dispositivo está encendido pero no desbloqueado.
  • Arranque verificado . El arranque verificado ahora se aplica estrictamente para evitar que se inicien los dispositivos comprometidos; admite la corrección de errores para mejorar la confiabilidad contra la corrupción de datos no maliciosa.
  • SELinux . La configuración actualizada de SELinux y la mayor cobertura de seccomp bloquean aún más el espacio aislado de la aplicación y reducen la superficie de ataque.
  • Aleatorización del orden de carga de la biblioteca y ASLR mejorado . El aumento de la aleatoriedad hace que algunos ataques de reutilización de código sean menos fiables.
  • Endurecimiento del núcleo . Se agregó protección de memoria adicional para los núcleos más nuevos al marcar partes de la memoria del núcleo como de solo lectura, restringiendo el acceso del núcleo a las direcciones del espacio de usuario y reduciendo aún más la superficie de ataque existente.
  • Esquema de firma APK v2 . Introdujo un esquema de firma de archivo completo que mejora la velocidad de verificación y fortalece las garantías de integridad.
  • Tienda CA de confianza . Para que sea más fácil para las aplicaciones controlar el acceso a su tráfico de red seguro, las autoridades de certificación instaladas por el usuario y las instaladas a través de las API de administración de dispositivos ya no son confiables de forma predeterminada para las aplicaciones dirigidas al nivel de API 24+. Además, todos los dispositivos Android nuevos deben enviarse con la misma tienda CA de confianza.
  • Configuración de seguridad de la red . Configure la seguridad de la red y TLS a través de un archivo de configuración declarativo.

androide 6

Every Android release includes dozens of security enhancements to protect users. Here are some of the major security enhancements available in Android 6.0:

  • Runtime Permissions. Applications request permissions at runtime instead of being granted at App install time. Users can toggle permissions on and off for both M and pre-M applications.
  • Verified Boot. A set of cryptographic checks of system software are conducted prior to execution to ensure the phone is healthy from the bootloader all the way up to the operating system.
  • Hardware-Isolated Security. New Hardware Abstraction Layer (HAL) used by Fingerprint API, Lockscreen, Device Encryption, and Client Certificates to protect keys against kernel compromise and/or local physical attacks
  • Fingerprints. Devices can now be unlocked with just a touch. Developers can also take advantage of new APIs to use fingerprints to lock and unlock encryption keys.
  • SD Card Adoption. Removable media can be adopted to a device and expand available storage for app local data, photos, videos, etc., but still be protected by block-level encryption.
  • Clear Text Traffic. Developers can use a new StrictMode to make sure their application doesn't use cleartext.
  • System Hardening. Hardening of the system via policies enforced by SELinux. This offers better isolation between users, IOCTL filtering, reduce threat of exposed services, further tightening of SELinux domains, and extremely limited /proc access.
  • USB Access Control: Users must confirm to allow USB access to files, storage, or other functionality on the phone. Default is now charge only with access to storage requiring explicit approval from the user.

androide 5

5.0

Cada versión de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Estas son algunas de las principales mejoras de seguridad disponibles en Android 5.0:

  • Cifrado por defecto. En los dispositivos que se envían con L listos para usar, el cifrado de disco completo está habilitado de forma predeterminada para mejorar la protección de los datos en dispositivos perdidos o robados. Los dispositivos que se actualizan a L se pueden cifrar en Configuración > Seguridad .
  • Cifrado de disco completo mejorado. La contraseña de usuario está protegida contra ataques de fuerza bruta mediante scrypt y, cuando está disponible, la clave está vinculada al almacén de claves de hardware para evitar ataques fuera del dispositivo. Como siempre, el secreto de bloqueo de pantalla de Android y la clave de cifrado del dispositivo no se envían fuera del dispositivo ni se exponen a ninguna aplicación.
  • Sandbox de Android reforzado con SELinux . Android ahora requiere SELinux en modo de aplicación para todos los dominios. SELinux es un sistema de control de acceso obligatorio (MAC) en el kernel de Linux que se utiliza para aumentar el modelo de seguridad de control de acceso discrecional (DAC) existente. Esta nueva capa brinda protección adicional contra posibles vulnerabilidades de seguridad.
  • Bloqueo inteligente. Android ahora incluye trustlets que brindan más flexibilidad para desbloquear dispositivos. Por ejemplo, los trustlets pueden permitir que los dispositivos se desbloqueen automáticamente cuando están cerca de otro dispositivo de confianza (a través de NFC, Bluetooth) o cuando los usa alguien con una cara de confianza.
  • Multiusuario, perfil restringido y modos de invitado para teléfonos y tabletas. Android ahora ofrece múltiples usuarios en los teléfonos e incluye un modo de invitado que se puede usar para brindar acceso temporal fácil a su dispositivo sin otorgar acceso a sus datos y aplicaciones.
  • Actualizaciones a WebView sin OTA. WebView ahora se puede actualizar independientemente del marco y sin un sistema OTA. Esto permitirá una respuesta más rápida a posibles problemas de seguridad en WebView.
  • Criptografía actualizada para HTTPS y TLS/SSL. TLSv1.2 y TLSv1.1 ahora están habilitados, ahora se prefiere Forward Secrecy, AES-GCM ahora está habilitado y los conjuntos de cifrado débil (MD5, 3DES y conjuntos de cifrado de exportación) ahora están deshabilitados. Consulte https://developer.android.com/reference/javax/net/ssl/SSLSocket.html para obtener más detalles.
  • Se eliminó la compatibilidad con el enlazador que no es PIE. Android ahora requiere que todos los ejecutables enlazados dinámicamente sean compatibles con PIE (ejecutables independientes de la posición). Esto mejora la implementación de la aleatorización del diseño del espacio de direcciones (ASLR) de Android.
  • FORTIFY_SOURCE mejoras. Las siguientes funciones de libc ahora implementan protecciones FORTIFY_SOURCE: stpcpy() , stpncpy() , read() , recvfrom() , FD_CLR() , FD_SET() y FD_ISSET() . Esto brinda protección contra vulnerabilidades de corrupción de memoria que involucran esas funciones.
  • Correcciones de seguridad. Android 5.0 también incluye correcciones para vulnerabilidades específicas de Android. Se ha proporcionado información sobre estas vulnerabilidades a los miembros de Open Handset Alliance y las correcciones están disponibles en Android Open Source Project. Para mejorar la seguridad, algunos dispositivos con versiones anteriores de Android también pueden incluir estas correcciones.

Android 4 y anteriores

Cada versión de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Las siguientes son algunas de las mejoras de seguridad disponibles en Android 4.4:

  • Sandbox de Android reforzado con SELinux. Android ahora usa SELinux en modo de cumplimiento. SELinux es un sistema de control de acceso obligatorio (MAC) en el kernel de Linux que se utiliza para aumentar el modelo de seguridad basado en el control de acceso discrecional (DAC) existente. Esto proporciona protección adicional contra posibles vulnerabilidades de seguridad.
  • VPN por usuario. En dispositivos multiusuario, las VPN ahora se aplican por usuario. Esto puede permitir que un usuario enrute todo el tráfico de la red a través de una VPN sin afectar a otros usuarios en el dispositivo.
  • Compatibilidad con el proveedor de ECDSA en AndroidKeyStore. Android ahora tiene un proveedor de almacén de claves que permite el uso de algoritmos ECDSA y DSA.
  • Advertencias de monitoreo de dispositivos. Android proporciona a los usuarios una advertencia si se ha agregado algún certificado al almacén de certificados del dispositivo que podría permitir el monitoreo del tráfico de red encriptado.
  • FORTIFICAR_FUENTE. Android ahora es compatible con FORTIFY_SOURCE nivel 2 y todo el código se compila con estas protecciones. FORTIFY_SOURCE se ha mejorado para que funcione con clang.
  • Fijación de certificados. Android 4.4 detecta y evita el uso de certificados de Google fraudulentos utilizados en comunicaciones seguras SSL/TLS.
  • Correcciones de seguridad. Android 4.4 también incluye correcciones para vulnerabilidades específicas de Android. Se ha proporcionado información sobre estas vulnerabilidades a los miembros de Open Handset Alliance y las soluciones están disponibles en Android Open Source Project. Para mejorar la seguridad, algunos dispositivos con versiones anteriores de Android también pueden incluir estas correcciones.

Cada versión de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Las siguientes son algunas de las mejoras de seguridad disponibles en Android 4.3:

  • Sandbox de Android reforzado con SELinux. Esta versión fortalece el entorno limitado de Android utilizando el sistema de control de acceso obligatorio (MAC) de SELinux en el kernel de Linux. El refuerzo de SELinux es invisible para los usuarios y desarrolladores y agrega solidez al modelo de seguridad existente de Android al tiempo que mantiene la compatibilidad con las aplicaciones existentes. Para garantizar una compatibilidad continua, esta versión permite el uso de SELinux en modo permisivo. Este modo registra cualquier infracción de políticas, pero no interrumpirá las aplicaciones ni afectará el comportamiento del sistema.
  • No hay programas setuid/setgid. Se agregó soporte para capacidades del sistema de archivos a los archivos del sistema Android y se eliminaron todos los programas setuid/setguid. Esto reduce la superficie de ataque raíz y la probabilidad de posibles vulnerabilidades de seguridad.
  • Autenticación BAD. Desde Android 4.2.2, las conexiones a ADB se autentican con un par de claves RSA. Esto evita el uso no autorizado de ADB cuando el atacante tiene acceso físico a un dispositivo.
  • Restrinja Setuid de las aplicaciones de Android. La partición /system ahora está montada como nosuid para procesos generados por cigotos, lo que impide que las aplicaciones de Android ejecuten programas setuid. Esto reduce la superficie de ataque raíz y la probabilidad de posibles vulnerabilidades de seguridad.
  • Límite de capacidad. Android zygote y ADB ahora usan prctl(PR_CAPBSET_DROP) para eliminar capacidades innecesarias antes de ejecutar aplicaciones. Esto evita que las aplicaciones de Android y las aplicaciones iniciadas desde el shell adquieran capacidades privilegiadas.
  • Proveedor de AndroidKeyStore. Android ahora tiene un proveedor de almacén de claves que permite a las aplicaciones crear claves de uso exclusivo. Esto proporciona a las aplicaciones una API para crear o almacenar claves privadas que otras aplicaciones no pueden utilizar.
  • KeyChain esBoundKeyAlgoritmo. La API de llavero ahora proporciona un método (isBoundKeyType) que permite a las aplicaciones confirmar que las claves de todo el sistema están vinculadas a una raíz de confianza de hardware para el dispositivo. Esto proporciona un lugar para crear o almacenar claves privadas que no se pueden exportar fuera del dispositivo, incluso en caso de que la raíz esté comprometida.
  • NO_NEW_PRIVS. Android zygote ahora usa prctl(PR_SET_NO_NEW_PRIVS) para bloquear la adición de nuevos privilegios antes de ejecutar el código de la aplicación. Esto evita que las aplicaciones de Android realicen operaciones que puedan elevar los privilegios mediante execve. (Esto requiere la versión 3.5 o superior del kernel de Linux).
  • Mejoras en FORTIFY_SOURCE. Se habilitó FORTIFY_SOURCE en Android x86 y MIPS y se fortificaron las llamadas strchr(), strrchr(), strlen() y umask(). Esto puede detectar posibles vulnerabilidades de corrupción de memoria o constantes de cadena no terminadas.
  • Protecciones de reubicación. Se habilitaron reubicaciones de solo lectura (relro) para ejecutables vinculados estáticamente y se eliminaron todas las reubicaciones de texto en el código de Android. Esto proporciona una defensa en profundidad contra posibles vulnerabilidades de corrupción de memoria.
  • EntropyMixer mejorado. EntropyMixer ahora escribe entropía al apagar/reiniciar, además de la mezcla periódica. Esto permite retener toda la entropía generada mientras los dispositivos están encendidos y es especialmente útil para dispositivos que se reinician inmediatamente después del aprovisionamiento.
  • Correcciones de seguridad. Android 4.3 también incluye correcciones para vulnerabilidades específicas de Android. Se ha proporcionado información sobre estas vulnerabilidades a los miembros de Open Handset Alliance y las correcciones están disponibles en Android Open Source Project. Para mejorar la seguridad, algunos dispositivos con versiones anteriores de Android también pueden incluir estas correcciones.

Android provides a multi-layered security model described in the Android Security Overview. Each update to Android includes dozens of security enhancements to protect users. The following are some of the security enhancements introduced in Android 4.2:

  • Application verification - Users can choose to enable “Verify Apps" and have applications screened by an application verifier, prior to installation. App verification can alert the user if they try to install an app that might be harmful; if an application is especially bad, it can block installation.
  • More control of premium SMS - Android will provide a notification if an application attempts to send SMS to a short code that uses premium services which might cause additional charges. The user can choose whether to allow the application to send the message or block it.
  • Always-on VPN - VPN can be configured so that applications will not have access to the network until a VPN connection is established. This prevents applications from sending data across other networks.
  • Certificate Pinning - The Android core libraries now support certificate pinning. Pinned domains will receive a certificate validation failure if the certificate does not chain to a set of expected certificates. This protects against possible compromise of Certificate Authorities.
  • Improved display of Android permissions - Permissions have been organized into groups that are more easily understood by users. During review of the permissions, the user can click on the permission to see more detailed information about the permission.
  • installd hardening - The installd daemon does not run as the root user, reducing potential attack surface for root privilege escalation.
  • init script hardening - init scripts now apply O_NOFOLLOW semantics to prevent symlink related attacks.
  • FORTIFY_SOURCE - Android now implements FORTIFY_SOURCE. This is used by system libraries and applications to prevent memory corruption.
  • ContentProvider default configuration - Applications which target API level 17 will have "export" set to "false" by default for each Content Provider, reducing default attack surface for applications.
  • Cryptography - Modified the default implementations of SecureRandom and Cipher.RSA to use OpenSSL. Added SSL Socket support for TLSv1.1 and TLSv1.2 using OpenSSL 1.0.1
  • Security Fixes - Upgraded open source libraries with security fixes include WebKit, libpng, OpenSSL, and LibXML. Android 4.2 also includes fixes for Android-specific vulnerabilities. Information about these vulnerabilities has been provided to Open Handset Alliance members and fixes are available in Android Open Source Project. To improve security, some devices with earlier versions of Android may also include these fixes.

Android proporciona un modelo de seguridad de varias capas que se describe en Descripción general de seguridad de Android . Cada actualización de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Las siguientes son algunas de las mejoras de seguridad introducidas en las versiones de Android 1.5 a 4.1:

androide 1.5
  • ProPolice para evitar desbordamientos del búfer de pila (-fstack-protector)
  • safe_iop para reducir los desbordamientos de enteros
  • Extensiones a OpenBSD dlmalloc para evitar vulnerabilidades de doble free() y para evitar ataques de consolidación de fragmentos. Los ataques de consolidación de fragmentos son una forma común de explotar la corrupción del montón.
  • OpenBSD calloc para evitar desbordamientos de enteros durante la asignación de memoria
androide 2.3
  • Protecciones de vulnerabilidad de cadena de formato (-Wformat-security -Werror=format-security)
  • No eXecute (NX) basado en hardware para evitar la ejecución de código en la pila y el montón
  • Linux mmap_min_addr para mitigar la escalada de privilegios de desreferencia de puntero nulo (mejorado aún más en Android 4.1)
Android 4.0
Aleatorización del diseño del espacio de direcciones (ASLR) para aleatorizar ubicaciones clave en la memoria
Android 4.1
  • Compatibilidad con PIE (ejecutable independiente de la posición)
  • Reubicaciones de solo lectura/enlace inmediato (-Wl,-z,relro -Wl,-z,now)
  • dmesg_restrict habilitado (evite filtrar direcciones del kernel)
  • kptr_restrict habilitado (evite filtrar direcciones del kernel)