Security Blog
The latest news and insights from Google on security and safety on the Internet
Protecting Android with more Linux kernel defenses
27 juillet 2016
Posted by Jeff Vander Stoep, Android Security team
[Cross-posted from the
Android Developers Blog
]
Android relies heavily on the Linux kernel for enforcement of its security model. To better protect the kernel, we’ve enabled a number of mechanisms within Android. At a high level these protections are grouped into two categories—memory protections and attack surface reduction.
Memory Protections
One of the major security features provided by the kernel is memory protection for userspace processes in the form of address space separation. Unlike userspace processes, the kernel’s various tasks live within one address space and a vulnerability anywhere in the kernel can potentially impact unrelated portions of the system’s memory. Kernel memory protections are designed to maintain the integrity of the kernel in spite of vulnerabilities.
Mark Memory As Read-Only/No-Execute
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. This feature is enabled with config option CONFIG_DEBUG_RODATA. It was put together by Kees Cook and is based on a subset of
Grsecurity’s
KERNEXEC feature by Brad Spengler and Qualcomm’s CONFIG_STRICT_MEMORY_RWX feature by Larry Bassel and Laura Abbott. CONFIG_DEBUG_RODATA landed in the upstream kernel for arm/arm64 and has been backported to Android’s 3.18+ arm/
arm64
common kernel.
Restrict Kernel Access to User Space
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. Similar features were already in existence, the earliest being Grsecurity’s UDEREF. This feature is enabled with config option CONFIG_CPU_SW_DOMAIN_PAN and was implemented by Russell King for ARMv7 and backported to
Android’s 4.1
kernel by Kees Cook.
Improve Protection Against Stack Buffer Overflows
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
.
Attack Surface Reduction
Attack surface reduction attempts to expose fewer entry points to the kernel without breaking legitimate functionality. Reducing attack surface can include removing code, removing access to entry points, or selectively exposing features.
Remove Default Access to Debug Features
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. Developers may still access perf by enabling developer settings and using adb to set a property: “adb shell setprop security.perf_harden 0”.
The patchset for blocking access to perf may be broken down into kernel and userspace sections. The
kernel patch
is by
Ben Hutchings
and is derived from Grsecurity’s CONFIG_GRKERNSEC_PERF_HARDEN by Brad Spengler. The userspace changes were
contributed by Daniel Micay
. Thanks to
Wish Wu
and others for responsibly disclosing security vulnerabilities in perf.
Restrict App Access to IOCTL Commands
Much of Android security model is described and enforced by SELinux. The ioctl() syscall represented a major gap in the granularity of enforcement via SELinux.
Ioctl command whitelisting with SELinux
was added as a means to provide per-command control over the ioctl syscall by SELinux.
Most of the kernel vulnerabilities reported on Android occur in drivers and are reached using the ioctl syscall, for example
CVE-2016-0820
. Some ioctl commands are needed by third-party applications, however most are not and access can be restricted without breaking legitimate functionality. 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.
Require SECCOMP-BPF
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
.
Ongoing Efforts
There are other projects underway aimed at protecting the kernel:
The
Kernel Self Protection Project
is developing runtime and compiler defenses for the upstream kernel.
Further sandbox tightening and attack surface reduction with SELinux is ongoing in AOSP.
Minijail
provides a convenient mechanism for applying many containment and sandboxing features offered by the kernel, including seccomp filters and namespaces.
Projects like
kasan
and
kcov
help fuzzers discover the root cause of crashes and to intelligently construct test cases that increase code coverage—ultimately resulting in a more efficient bug hunting process.
Due to these efforts and others, we expect the security of the kernel to continue improving. As always, we appreciate feedback on our work and welcome suggestions for how we can improve Android. Contact us at
security@android.com
.
Aucun commentaire :
Publier un commentaire
Libellés
#sharethemicincyber
#supplychain #security #opensource
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome enterprise
chrome security
connected devices
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
hacking
interoperability
iot security
kubernetes
linux kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
security rewards program
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
VDP
vulnerabilities
workshop
Archive
2024
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2023
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2022
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2021
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2020
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2019
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2018
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2017
déc.
nov.
oct.
sept.
juill.
juin
mai
avr.
mars
févr.
janv.
2016
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2015
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
janv.
2014
déc.
nov.
oct.
sept.
août
juill.
juin
avr.
mars
févr.
janv.
2013
déc.
nov.
oct.
août
juin
mai
avr.
mars
févr.
janv.
2012
déc.
sept.
août
juin
mai
avr.
mars
févr.
janv.
2011
déc.
nov.
oct.
sept.
août
juill.
juin
mai
avr.
mars
févr.
2010
nov.
oct.
sept.
août
juill.
mai
avr.
mars
2009
nov.
oct.
août
juill.
juin
mars
2008
déc.
nov.
oct.
août
juill.
mai
févr.
2007
nov.
oct.
sept.
juill.
juin
mai
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow
Aucun commentaire :
Publier un commentaire