move more under exploit protection
This commit is contained in:
parent
95eaa79691
commit
e5a0f9ac52
@ -88,8 +88,18 @@
|
||||
<li>
|
||||
<a href="#grapheneos">GrapheneOS</a>
|
||||
<ul>
|
||||
<li><a href="#exploit-protection">Defending against exploitation of unknown
|
||||
vulnerabilities</a></li>
|
||||
<li>
|
||||
<a href="#exploit-protection">Defending against exploitation of
|
||||
unknown vulnerabilities</a>
|
||||
<ul>
|
||||
<li><a href="#attack-surface-reduction">Attack surface
|
||||
reduction</a></li>
|
||||
<li><a href="#exploit-mitigations">Exploit
|
||||
mitigations</a></li>
|
||||
<li><a href="#anti-persistence">Anti-persistence /
|
||||
detection</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#more-complete-patching">More complete patching</a></li>
|
||||
<li><a href="#sandboxed-google-play">Sandboxed Google Play</a></li>
|
||||
<li><a href="#disabling-secondary-user-app-installation">Disabling secondary
|
||||
@ -128,24 +138,6 @@
|
||||
protect users before the vulnerability is known to the vendor and has a patch
|
||||
developed and shipped.</p>
|
||||
|
||||
<p>The vast majority of vulnerabilities are well understood classes of bugs
|
||||
and exploitation can be prevented by avoiding the bugs via languages/tooling
|
||||
or preventing exploitation with strong exploit mitigations. In many cases,
|
||||
vulnerability classes can be completely wiped out while in many others they
|
||||
can at least be made meaningfully harder to exploit. Android does a lot of
|
||||
work in this area and GrapheneOS has helped to advance this in Android and the
|
||||
Linux kernel. It takes an enormous amount of resources to develop fundamental
|
||||
fixes for these problems and there's often a high performance, memory or
|
||||
compatibility cost to deploying them. Mainstream operating systems usually
|
||||
don't prioritize security over other areas. GrapheneOS is willing to go
|
||||
further and we offer toggles for users to choose the compromises they prefer
|
||||
instead of forcing it on them. In the meantime, weaker less complete exploit
|
||||
mitigations can still provide meaningful barriers against attacks as long as
|
||||
they're developed with a clear threat model. GrapheneOS is heavily invested in
|
||||
many areas of developing these protections: developing/deploying memory safe
|
||||
languages / libraries, static/dynamic analysis tooling and many kinds of
|
||||
mitigations.</p>
|
||||
|
||||
<p>Unknown (0 day) vulnerabilities are much more widely used than most realize
|
||||
to exploit users not just in targeted attacks but in broad deployments.
|
||||
Project Zero maintains
|
||||
@ -155,6 +147,50 @@
|
||||
attackers were caught exploiting users, often because the attacks are not
|
||||
targeted but rather deployed on public websites, etc.</p>
|
||||
|
||||
<p>The first line of defense is attack surface reduction. Removing unnecessary
|
||||
code or exposed attack surface eliminates many vulnerabilities completely.
|
||||
GrapheneOS avoids removing any useful functionality for end users, but we can
|
||||
still disable lots of functionality by default and require that users opt-in
|
||||
to using it to eliminate it for most of them. An example we landed upstream in
|
||||
Android is disallowing using the kernel's profiling support by default, since
|
||||
it was and still is a major source of Linux kernel vulnerabilities. Profiling
|
||||
is now only exposed to apps for developers who enable developer tools, enable
|
||||
the Android Debug Bridge (ADB) and then use profiling tools via ADB. It's also
|
||||
only enabled until the next boot. This isn't listed below since it's one of
|
||||
the features we got implemented in Android itself.</p>
|
||||
|
||||
<p>The next line of defense is preventing an attacker from exploiting a
|
||||
vulnerability, either by making it impossible, unreliable or at least
|
||||
meaningfully harder to develop. The vast majority of vulnerabilities are well
|
||||
understood classes of bugs and exploitation can be prevented by avoiding the
|
||||
bugs via languages/tooling or preventing exploitation with strong exploit
|
||||
mitigations. In many cases, vulnerability classes can be completely wiped out
|
||||
while in many others they can at least be made meaningfully harder to exploit.
|
||||
Android does a lot of work in this area and GrapheneOS has helped to advance
|
||||
this in Android and the Linux kernel. It takes an enormous amount of resources
|
||||
to develop fundamental fixes for these problems and there's often a high
|
||||
performance, memory or compatibility cost to deploying them. Mainstream
|
||||
operating systems usually don't prioritize security over other areas.
|
||||
GrapheneOS is willing to go further and we offer toggles for users to choose
|
||||
the compromises they prefer instead of forcing it on them. In the meantime,
|
||||
weaker less complete exploit mitigations can still provide meaningful barriers
|
||||
against attacks as long as they're developed with a clear threat model.
|
||||
GrapheneOS is heavily invested in many areas of developing these protections:
|
||||
developing/deploying memory safe languages / libraries, static/dynamic
|
||||
analysis tooling and many kinds of mitigations.</p>
|
||||
|
||||
<p>The final line of defense is containment through sandboxing at various
|
||||
levels: fine-grained sandboxes around a specific context like per site browser
|
||||
renderers, sandboxes around a specific component like Android's media codec
|
||||
sandbox and app / workspace sandboxes like the Android app sandbox used to
|
||||
sandbox each app which is also the basis for user/work profiles. GrapheneOS
|
||||
improves all of these sandboxes through fortifying the kernel and other base
|
||||
OS components along with improving the sandboxing policies.</p>
|
||||
|
||||
<p>Preventing an attacker from persisting their control of a component or the
|
||||
OS / firmware through verified boot and avoiding trust in persistent state
|
||||
also helps to mitigate the damage after a compromise has occurred.</p>
|
||||
|
||||
<p>Remote code execution vulnerabilities are the most serious and allow an
|
||||
attacker to gain a foothold on device or even substantial control over it
|
||||
remotely. Local code execution vulnerabilities allow breaking out of a sandbox
|
||||
@ -174,90 +210,128 @@
|
||||
code loading/generation/execution such as a JIT compiler bug or a plugin
|
||||
loading vulnerability.</p>
|
||||
|
||||
<ul>
|
||||
<li>Hardened app runtime</li>
|
||||
<li>Stronger app sandbox</li>
|
||||
<li><a href="https://github.com/GrapheneOS/platform_bionic">Hardened libc</a>
|
||||
providing defenses against the most common classes of vulnerabilities (memory
|
||||
corruption)</li>
|
||||
<li>
|
||||
Our own <a href="https://github.com/GrapheneOS/hardened_malloc">hardened
|
||||
malloc (memory allocator)</a> leveraging modern hardware capabilities
|
||||
to provide substantial defenses against the most common classes of
|
||||
vulnerabilities (heap memory corruption) along with reducing the lifetime
|
||||
of sensitive data in memory. The <a
|
||||
href="https://github.com/GrapheneOS/hardened_malloc/blob/main/README.md">hardened_malloc
|
||||
README</a> has extensive documentation on it. The hardened_malloc
|
||||
project is portable to other Linux-based operating systems and is being
|
||||
adopted by other security-focused operating systems like Whonix. Our
|
||||
allocator also heavily influenced the design of the <a
|
||||
href="https://www.openwall.com/lists/musl/2020/05/13/1">next-generation
|
||||
musl malloc implementation</a> which offers substantially better security than
|
||||
musl's previous malloc while still having minimal memory usage and code size.
|
||||
<ul>
|
||||
<li>Fully out-of-line metadata with protection from corruption, ruling
|
||||
out traditional allocator exploitation</li>
|
||||
<li>Separate memory regions for metadata, large allocations and each
|
||||
slab allocation size class with high entropy random bases and no
|
||||
address space reuse between the different regions</li>
|
||||
<li>Deterministic detection of any invalid free</li>
|
||||
<li>Zero-on-free with detection of write-after-free via checking that
|
||||
memory is still zeroed before handing it out again</li>
|
||||
<li>Delayed reuse of address space and memory allocations through the
|
||||
combination of deterministic and randomized quarantines to mitigate
|
||||
use-after-free vulnerabilities</li>
|
||||
<li>Fine-grained randomization</li>
|
||||
<li>Aggressive consistency checks</li>
|
||||
<li>Memory protected guard regions around allocations larger than 16k
|
||||
with randomization of guard region sizes for 128k and above</li>
|
||||
<li>Allocations smaller than 16k have guard regions around each of the
|
||||
slabs containing allocations (for example, 16 byte allocations are in
|
||||
4096 byte slabs with 4096 byte guard regions before and after)</li>
|
||||
<li>Random canaries with a leading zero are added to these smaller
|
||||
allocations to block C string overflows, absorb small overflows
|
||||
and detect linear overflows or other heap corruption when the
|
||||
canary value is checked (primarily on free)</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Hardened compiler toolchain</li>
|
||||
<li>
|
||||
Hardened kernel
|
||||
<ul>
|
||||
<li>Support for dynamically loaded kernel modules is disabled and
|
||||
the minimal set of modules for the device model are built into the
|
||||
kernel to substantially improve the granularity of Control Flow
|
||||
Integrity (CFI) and reduce attack surface.</li>
|
||||
<li>4-level page tables are enabled on arm64 to provide a much larger
|
||||
address space (48-bit instead of 39-bit) with significantly higher
|
||||
entropy Address Space Layout Randomization (33-bit instead of
|
||||
24-bit).</li>
|
||||
<li>Random canaries with a leading zero are added to the kernel heap
|
||||
(slub) to block C string overflows, absorb small overflows and detect
|
||||
linear overflows or other heap corruption when the canary value is
|
||||
checked (on free, copies to/from userspace, etc.).</li>
|
||||
<li>Memory is wiped (zeroed) as soon as it's released in both the
|
||||
low-level kernel page allocator and higher level kernel heap allocator
|
||||
(slub). This substantially reduces the lifetime of sensitive data in
|
||||
memory, mitigates use-after-free vulnerabilities and makes most
|
||||
uninitialized data usage vulnerabilities harmless. Without our
|
||||
changes, memory that's released retains data indefinitely until the
|
||||
memory is handed out for other uses and gets partially or fully
|
||||
overwritten by new data.</li>
|
||||
<li>Kernel stack allocations are zeroed to make most uninitialized
|
||||
data usage vulnerabilities harmless.</li>
|
||||
<li>Assorted attack surface reduction through disabling features or
|
||||
setting up infrastructure to dynamically enable/disable them only as
|
||||
needed (perf, ptrace).</li>
|
||||
<li>Assorted upstream hardening features are enabled, including many
|
||||
which we played a part in developing and landing upstream as part of
|
||||
our linux-hardened project (which we intend to revive as a more active
|
||||
project again).</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Prevention of dynamic native code execution in-memory or via the filesystem
|
||||
for the base OS without going via the package manager, etc.</li>
|
||||
<li>Filesystem access hardening</li>
|
||||
</ul>
|
||||
<section id="attack-surface-reduction">
|
||||
<h4><a href="#attack-surface-reduction">Attack surface reduction</a></h4>
|
||||
|
||||
<ul>
|
||||
<li>Greatly reduced remote, local and proximity-based attack surface by
|
||||
stripping out unnecessary code, making more features optional and disabling
|
||||
optional features by default (NFC, Bluetooth, etc.), when the screen is
|
||||
locked (connecting new USB peripherals, camera access) and optionally after a
|
||||
timeout (Bluetooth, Wi-Fi)</li>
|
||||
<li>Option to disable native debugging (ptrace) to reduce local attack surface
|
||||
(still enabled by default for compatibility)</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section id="exploit-mitigations">
|
||||
<h4><a href="#exploit-mitigations">Exploit mitigations</a></h4>
|
||||
|
||||
<ul>
|
||||
<li>Hardened app runtime</li>
|
||||
<li>Stronger app sandbox</li>
|
||||
<li><a href="https://github.com/GrapheneOS/platform_bionic">Hardened libc</a>
|
||||
providing defenses against the most common classes of vulnerabilities (memory
|
||||
corruption)</li>
|
||||
<li>
|
||||
Our own <a href="https://github.com/GrapheneOS/hardened_malloc">hardened
|
||||
malloc (memory allocator)</a> leveraging modern hardware capabilities
|
||||
to provide substantial defenses against the most common classes of
|
||||
vulnerabilities (heap memory corruption) along with reducing the lifetime
|
||||
of sensitive data in memory. The <a
|
||||
href="https://github.com/GrapheneOS/hardened_malloc/blob/main/README.md">hardened_malloc
|
||||
README</a> has extensive documentation on it. The hardened_malloc
|
||||
project is portable to other Linux-based operating systems and is being
|
||||
adopted by other security-focused operating systems like Whonix. Our
|
||||
allocator also heavily influenced the design of the <a
|
||||
href="https://www.openwall.com/lists/musl/2020/05/13/1">next-generation
|
||||
musl malloc implementation</a> which offers substantially better security than
|
||||
musl's previous malloc while still having minimal memory usage and code size.
|
||||
<ul>
|
||||
<li>Fully out-of-line metadata with protection from corruption, ruling
|
||||
out traditional allocator exploitation</li>
|
||||
<li>Separate memory regions for metadata, large allocations and each
|
||||
slab allocation size class with high entropy random bases and no
|
||||
address space reuse between the different regions</li>
|
||||
<li>Deterministic detection of any invalid free</li>
|
||||
<li>Zero-on-free with detection of write-after-free via checking that
|
||||
memory is still zeroed before handing it out again</li>
|
||||
<li>Delayed reuse of address space and memory allocations through the
|
||||
combination of deterministic and randomized quarantines to mitigate
|
||||
use-after-free vulnerabilities</li>
|
||||
<li>Fine-grained randomization</li>
|
||||
<li>Aggressive consistency checks</li>
|
||||
<li>Memory protected guard regions around allocations larger than 16k
|
||||
with randomization of guard region sizes for 128k and above</li>
|
||||
<li>Allocations smaller than 16k have guard regions around each of the
|
||||
slabs containing allocations (for example, 16 byte allocations are in
|
||||
4096 byte slabs with 4096 byte guard regions before and after)</li>
|
||||
<li>Random canaries with a leading zero are added to these smaller
|
||||
allocations to block C string overflows, absorb small overflows
|
||||
and detect linear overflows or other heap corruption when the
|
||||
canary value is checked (primarily on free)</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Hardened compiler toolchain</li>
|
||||
<li>
|
||||
Hardened kernel
|
||||
<ul>
|
||||
<li>Support for dynamically loaded kernel modules is disabled and
|
||||
the minimal set of modules for the device model are built into the
|
||||
kernel to substantially improve the granularity of Control Flow
|
||||
Integrity (CFI) and reduce attack surface.</li>
|
||||
<li>4-level page tables are enabled on arm64 to provide a much larger
|
||||
address space (48-bit instead of 39-bit) with significantly higher
|
||||
entropy Address Space Layout Randomization (33-bit instead of
|
||||
24-bit).</li>
|
||||
<li>Random canaries with a leading zero are added to the kernel heap
|
||||
(slub) to block C string overflows, absorb small overflows and detect
|
||||
linear overflows or other heap corruption when the canary value is
|
||||
checked (on free, copies to/from userspace, etc.).</li>
|
||||
<li>Memory is wiped (zeroed) as soon as it's released in both the
|
||||
low-level kernel page allocator and higher level kernel heap allocator
|
||||
(slub). This substantially reduces the lifetime of sensitive data in
|
||||
memory, mitigates use-after-free vulnerabilities and makes most
|
||||
uninitialized data usage vulnerabilities harmless. Without our
|
||||
changes, memory that's released retains data indefinitely until the
|
||||
memory is handed out for other uses and gets partially or fully
|
||||
overwritten by new data.</li>
|
||||
<li>Kernel stack allocations are zeroed to make most uninitialized
|
||||
data usage vulnerabilities harmless.</li>
|
||||
<li>Assorted attack surface reduction through disabling features or
|
||||
setting up infrastructure to dynamically enable/disable them only as
|
||||
needed (perf, ptrace).</li>
|
||||
<li>Assorted upstream hardening features are enabled, including many
|
||||
which we played a part in developing and landing upstream as part of
|
||||
our linux-hardened project (which we intend to revive as a more active
|
||||
project again).</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Prevention of dynamic native code execution in-memory or via the filesystem
|
||||
for the base OS without going via the package manager, etc.</li>
|
||||
<li>Filesystem access hardening</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<section id="anti-persistence">
|
||||
<h4><a href="#anti-persistence">Anti-persistence / detection</a></h4>
|
||||
|
||||
<ul>
|
||||
<li>Enhanced <a href="https://source.android.com/security/verifiedboot">verified boot</a>
|
||||
with better security properties and reduced attack surface</li>
|
||||
<li>Enhanced hardware-based attestation with more precise version information</li>
|
||||
<li>Hardware-based security verification and monitoring: the
|
||||
<a href="https://github.com/GrapheneOS/Auditor/releases">Auditor app</a> app and
|
||||
<a href="https://attestation.app/">attestation service</a> provide strong
|
||||
hardware-based verification of the authenticity and integrity of the
|
||||
firmware/software on the device. A strong pairing-based approach is used which
|
||||
also provides verification of the device's identity based on the hardware backed
|
||||
key generated for each pairing. Software-based checks are layered on top with
|
||||
trust securely chained from the hardware. For more details, see the
|
||||
<a href="https://attestation.app/about">about page</a>
|
||||
and <a href="https://attestation.app/tutorial">tutorial</a>.</li>
|
||||
</ul>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="more-complete-patching">
|
||||
@ -388,17 +462,7 @@
|
||||
<p>This is an incomplete list of other GrapheneOS features.</p>
|
||||
|
||||
<ul>
|
||||
<li>Enhanced <a href="https://source.android.com/security/verifiedboot">verified boot</a>
|
||||
with better security properties and reduced attack surface</li>
|
||||
<li>Enhanced hardware-based attestation with more precise version information</li>
|
||||
<li>Eliminates remaining holes for apps to access hardware-based identifiers</li>
|
||||
<li>Greatly reduced remote, local and proximity-based attack surface by
|
||||
stripping out unnecessary code, making more features optional and disabling
|
||||
optional features by default (NFC, Bluetooth, etc.), when the screen is
|
||||
locked (connecting new USB peripherals, camera access) and optionally after a
|
||||
timeout (Bluetooth, Wi-Fi)</li>
|
||||
<li>Option to disable native debugging (ptrace) to reduce local attack surface
|
||||
(still enabled by default for compatibility)</li>
|
||||
<li>Low-level improvements to the <a href="/faq#encryption">filesystem-based
|
||||
full disk encryption</a> used on modern Android</li>
|
||||
<li>Support creating up to 16 secondary user profiles (15 + guest) instead of
|
||||
@ -440,16 +504,6 @@
|
||||
sandboxed Google Play feature. In the future, it will be used to distribute
|
||||
first-party GrapheneOS builds of externally developed open source apps with
|
||||
hardening applied.</li>
|
||||
<li>Hardware-based security verification and monitoring: the
|
||||
<a href="https://github.com/GrapheneOS/Auditor/releases">Auditor app</a> app and
|
||||
<a href="https://attestation.app/">attestation service</a> provide strong
|
||||
hardware-based verification of the authenticity and integrity of the
|
||||
firmware/software on the device. A strong pairing-based approach is used which
|
||||
also provides verification of the device's identity based on the hardware backed
|
||||
key generated for each pairing. Software-based checks are layered on top with
|
||||
trust securely chained from the hardware. For more details, see the
|
||||
<a href="https://attestation.app/about">about page</a>
|
||||
and <a href="https://attestation.app/tutorial">tutorial</a>.</li>
|
||||
<li><a href="https://github.com/GrapheneOS/PdfViewer">PDF Viewer</a>: sandboxed,
|
||||
hardened PDF viewer using HiDPI rendering with pinch to zoom, text selection,
|
||||
etc.</li>
|
||||
|
Loading…
x
Reference in New Issue
Block a user