diff options
Diffstat (limited to 'static')
| -rw-r--r-- | static/features.html | 302 |
1 files 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> |