July 29, 2016 at 14:32Google improves Android kernel security mechanisms
It is no secret that the Android kernel is largely based on the Linux kernel and repeats its security model. As in the case of Linux and other desktop operating systems, Android provides its applications with a closed virtual address space, which allows you to efficiently distribute resources between them, as well as manage their security. Android also provides applications with DEP & ASLR security technologies, which prevents exploitation of vulnerabilities in them. The sandbox mechanism and permissions guarantee that the running application will only get access to the data and resources intended for it.
Android developers recently reportedthat work on protective measures of the components of the kernel, which operates in its address space, inaccessible to simple applications. Android security bulletins published by us this year have repeatedly indicated LPE vulnerabilities in the kernel and drivers that allowed the application to run its code in kernel mode.
According to the authors, new versions of Android will offer DEP technology in kernel mode, which will complicate the exploitation of LPE vulnerabilities and the placement of shell code there. Such a technique will be performed through segmentation, i.e., dividing the kernel memory into special sections with setting permissions for them. Sections intended for code storage will be marked as read-only and executable, and data sections will be marked with NX execution prohibition.
Another security feature is similar to the Supervisor Mode Access Prevention (SMAP) security measure used by Intel desktop microprocessors, which prevents kernel mode code from accessing the user part of the address space. Android introduces restrictive measures that isolate the kernel from direct access to such memory.
Another protective measure is aimed at preventing attacks on the memory of the kernel stack such as buffer overflow.
These protective measures relate to the Android kernel running with memory, another category of new protective measures is called Attack Surface Reduction (ASR), that is, it includes conceptual protective measures that immediately cut off the successful use of entire attack classes.
ASR by default disables the debugging feature of the device, which, previously, was available for inclusion to all users.
ASR also restricts applications from accessing IOCTL operations on devices through the ioctl () system call . Since ioctl is used to exploit certain types of vulnerabilities , ASR introduces the concept of a whitelist of IOCTL operations that the application will be allowed to use.
ASR introduces a new feature called Seccomp, which is an additional security setting for an application isolation mechanism called sandbox. Seccomp allows you to restrict the application running in Android from making certain system calls or passing certain arguments there using a special filter. It is worth noting that this function is similar to the win32k syscalls filtering function we specified , which will appear for Windows 10 users next week along with a big update for this OS.
These security features should appear in the new release of Android 7.0 (Nougat).
be secure.
Android developers recently reportedthat work on protective measures of the components of the kernel, which operates in its address space, inaccessible to simple applications. Android security bulletins published by us this year have repeatedly indicated LPE vulnerabilities in the kernel and drivers that allowed the application to run its code in kernel mode.
According to the authors, new versions of Android will offer DEP technology in kernel mode, which will complicate the exploitation of LPE vulnerabilities and the placement of shell code there. Such a technique will be performed through segmentation, i.e., dividing the kernel memory into special sections with setting permissions for them. Sections intended for code storage will be marked as read-only and executable, and data sections will be marked with NX execution prohibition.
This feature segments kernel memory into logical sections and sets restrictive page access permissions on each section. Code is marked as read only + execute. Data sections are marked as no-execute and further segmented into read-only and read-write sections.
Another security feature is similar to the Supervisor Mode Access Prevention (SMAP) security measure used by Intel desktop microprocessors, which prevents kernel mode code from accessing the user part of the address space. Android introduces restrictive measures that isolate the kernel from direct access to such memory.
This feature improves protection of the kernel by preventing it from directly accessing userspace memory. This can make a number of attacks more difficult because attackers have significantly less control over kernel memory that is executable, particularly with CONFIG_DEBUG_RODATA enabled.
Another protective measure is aimed at preventing attacks on the memory of the kernel stack such as buffer overflow.
Much like its predecessor, stack-protector, stack-protector-strong protects against stack buffer overflows, but additionally provides coverage for more array types, as the original only protected character arrays. Stack-protector-strong was implemented by Han Shan and added to the gcc 4.9 compiler.
These protective measures relate to the Android kernel running with memory, another category of new protective measures is called Attack Surface Reduction (ASR), that is, it includes conceptual protective measures that immediately cut off the successful use of entire attack classes.
ASR by default disables the debugging feature of the device, which, previously, was available for inclusion to all users.
The kernel's perf system provides infrastructure for performance measurement and can be used for analyzing both the kernel and userspace applications. Perf is a valuable tool for developers, but adds unnecessary attack surface for the vast majority of Android users. In Android Nougat, access to perf will be blocked by default.
ASR also restricts applications from accessing IOCTL operations on devices through the ioctl () system call . Since ioctl is used to exploit certain types of vulnerabilities , ASR introduces the concept of a whitelist of IOCTL operations that the application will be allowed to use.
In Android Nougat, only a small whitelist of socket ioctl commands are available to applications. For select devices, applications' access to GPU ioctls has been similarly restricted.
ASR introduces a new feature called Seccomp, which is an additional security setting for an application isolation mechanism called sandbox. Seccomp allows you to restrict the application running in Android from making certain system calls or passing certain arguments there using a special filter. It is worth noting that this function is similar to the win32k syscalls filtering function we specified , which will appear for Windows 10 users next week along with a big update for this OS.
Seccomp provides an additional sandboxing mechanism allowing a process to restrict the syscalls and syscall arguments available using a configurable filter. Restricting the availability of syscalls can dramatically cut down on the exposed attack surface of the kernel. Since seccomp was first introduced on Nexus devices in Lollipop, its availability across the Android ecosystem has steadily improved. With Android Nougat, seccomp support is a requirement for all devices. On Android Nougat we are using seccomp on the mediaextractor and mediacodec processes as part of the media hardening effort.
These security features should appear in the new release of Android 7.0 (Nougat).
be secure.
