From e5a0f9ac52fae3591796d75f72805e6ff97b9a76 Mon Sep 17 00:00:00 2001
From: Daniel Micay <danielmicay@gmail.com>
Date: Mon, 9 May 2022 16:20:18 -0400
Subject: [PATCH] move more under exploit protection

---
 static/features.html | 302 +++++++++++++++++++++++++------------------
 1 file changed, 178 insertions(+), 124 deletions(-)

diff --git a/static/features.html b/static/features.html
index 83203262..dcf89ef2 100644
--- a/static/features.html
+++ b/static/features.html
@@ -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>