security/hakurei.app
security/hakurei.app
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity

move more under exploit protection

Browse Source
This commit is contained in:
Daniel Micay 2022-05-09 16:20:18 -04:00
parent 95eaa79691
commit e5a0f9ac52
1 changed files with 178 additions and 124 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

302
static/features.html
View File

@ -88,8 +88,18 @@
<li> <li>
<a href="#grapheneos">GrapheneOS</a> <a href="#grapheneos">GrapheneOS</a>
<ul> <ul>
<li><a href="#exploit-protection">Defending against exploitation of unknown <li>
vulnerabilities</a></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="#more-complete-patching">More complete patching</a></li>
<li><a href="#sandboxed-google-play">Sandboxed Google Play</a></li> <li><a href="#sandboxed-google-play">Sandboxed Google Play</a></li>
<li><a href="#disabling-secondary-user-app-installation">Disabling secondary <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 protect users before the vulnerability is known to the vendor and has a patch
developed and shipped.</p> 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 <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. to exploit users not just in targeted attacks but in broad deployments.
Project Zero maintains Project Zero maintains
@ -155,6 +147,50 @@
attackers were caught exploiting users, often because the attacks are not attackers were caught exploiting users, often because the attacks are not
targeted but rather deployed on public websites, etc.</p> 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 <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 attacker to gain a foothold on device or even substantial control over it
remotely. Local code execution vulnerabilities allow breaking out of a sandbox 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 code loading/generation/execution such as a JIT compiler bug or a plugin
loading vulnerability.</p> loading vulnerability.</p>
<ul> <section id="attack-surface-reduction">
<li>Hardened app runtime</li> <h4><a href="#attack-surface-reduction">Attack surface reduction</a></h4>
<li>Stronger app sandbox</li>
<li><a href="https://github.com/GrapheneOS/platform_bionic">Hardened libc</a> <ul>
providing defenses against the most common classes of vulnerabilities (memory <li>Greatly reduced remote, local and proximity-based attack surface by
corruption)</li> stripping out unnecessary code, making more features optional and disabling
<li> optional features by default (NFC, Bluetooth, etc.), when the screen is
Our own <a href="https://github.com/GrapheneOS/hardened_malloc">hardened locked (connecting new USB peripherals, camera access) and optionally after a
malloc (memory allocator)</a> leveraging modern hardware capabilities timeout (Bluetooth, Wi-Fi)</li>
to provide substantial defenses against the most common classes of <li>Option to disable native debugging (ptrace) to reduce local attack surface
vulnerabilities (heap memory corruption) along with reducing the lifetime (still enabled by default for compatibility)</li>
of sensitive data in memory. The <a </ul>
href="https://github.com/GrapheneOS/hardened_malloc/blob/main/README.md">hardened_malloc </section>
README</a> has extensive documentation on it. The hardened_malloc
project is portable to other Linux-based operating systems and is being <section id="exploit-mitigations">
adopted by other security-focused operating systems like Whonix. Our <h4><a href="#exploit-mitigations">Exploit mitigations</a></h4>
allocator also heavily influenced the design of the <a
href="https://www.openwall.com/lists/musl/2020/05/13/1">next-generation <ul>
musl malloc implementation</a> which offers substantially better security than <li>Hardened app runtime</li>
musl's previous malloc while still having minimal memory usage and code size. <li>Stronger app sandbox</li>
<ul> <li><a href="https://github.com/GrapheneOS/platform_bionic">Hardened libc</a>
<li>Fully out-of-line metadata with protection from corruption, ruling providing defenses against the most common classes of vulnerabilities (memory
out traditional allocator exploitation</li> corruption)</li>
<li>Separate memory regions for metadata, large allocations and each <li>
slab allocation size class with high entropy random bases and no Our own <a href="https://github.com/GrapheneOS/hardened_malloc">hardened
address space reuse between the different regions</li> malloc (memory allocator)</a> leveraging modern hardware capabilities
<li>Deterministic detection of any invalid free</li> to provide substantial defenses against the most common classes of
<li>Zero-on-free with detection of write-after-free via checking that vulnerabilities (heap memory corruption) along with reducing the lifetime
memory is still zeroed before handing it out again</li> of sensitive data in memory. The <a
<li>Delayed reuse of address space and memory allocations through the href="https://github.com/GrapheneOS/hardened_malloc/blob/main/README.md">hardened_malloc
combination of deterministic and randomized quarantines to mitigate README</a> has extensive documentation on it. The hardened_malloc
use-after-free vulnerabilities</li> project is portable to other Linux-based operating systems and is being
<li>Fine-grained randomization</li> adopted by other security-focused operating systems like Whonix. Our
<li>Aggressive consistency checks</li> allocator also heavily influenced the design of the <a
<li>Memory protected guard regions around allocations larger than 16k href="https://www.openwall.com/lists/musl/2020/05/13/1">next-generation
with randomization of guard region sizes for 128k and above</li> musl malloc implementation</a> which offers substantially better security than
<li>Allocations smaller than 16k have guard regions around each of the musl's previous malloc while still having minimal memory usage and code size.
slabs containing allocations (for example, 16 byte allocations are in <ul>
4096 byte slabs with 4096 byte guard regions before and after)</li> <li>Fully out-of-line metadata with protection from corruption, ruling
<li>Random canaries with a leading zero are added to these smaller out traditional allocator exploitation</li>
allocations to block C string overflows, absorb small overflows <li>Separate memory regions for metadata, large allocations and each
and detect linear overflows or other heap corruption when the slab allocation size class with high entropy random bases and no
canary value is checked (primarily on free)</li> address space reuse between the different regions</li>
</ul> <li>Deterministic detection of any invalid free</li>
</li> <li>Zero-on-free with detection of write-after-free via checking that
<li>Hardened compiler toolchain</li> memory is still zeroed before handing it out again</li>
<li> <li>Delayed reuse of address space and memory allocations through the
Hardened kernel combination of deterministic and randomized quarantines to mitigate
<ul> use-after-free vulnerabilities</li>
<li>Support for dynamically loaded kernel modules is disabled and <li>Fine-grained randomization</li>
the minimal set of modules for the device model are built into the <li>Aggressive consistency checks</li>
kernel to substantially improve the granularity of Control Flow <li>Memory protected guard regions around allocations larger than 16k
Integrity (CFI) and reduce attack surface.</li> with randomization of guard region sizes for 128k and above</li>
<li>4-level page tables are enabled on arm64 to provide a much larger <li>Allocations smaller than 16k have guard regions around each of the
address space (48-bit instead of 39-bit) with significantly higher slabs containing allocations (for example, 16 byte allocations are in
entropy Address Space Layout Randomization (33-bit instead of 4096 byte slabs with 4096 byte guard regions before and after)</li>
24-bit).</li> <li>Random canaries with a leading zero are added to these smaller
<li>Random canaries with a leading zero are added to the kernel heap allocations to block C string overflows, absorb small overflows
(slub) to block C string overflows, absorb small overflows and detect and detect linear overflows or other heap corruption when the
linear overflows or other heap corruption when the canary value is canary value is checked (primarily on free)</li>
checked (on free, copies to/from userspace, etc.).</li> </ul>
<li>Memory is wiped (zeroed) as soon as it's released in both the </li>
low-level kernel page allocator and higher level kernel heap allocator <li>Hardened compiler toolchain</li>
(slub). This substantially reduces the lifetime of sensitive data in <li>
memory, mitigates use-after-free vulnerabilities and makes most Hardened kernel
uninitialized data usage vulnerabilities harmless. Without our <ul>
changes, memory that's released retains data indefinitely until the <li>Support for dynamically loaded kernel modules is disabled and
memory is handed out for other uses and gets partially or fully the minimal set of modules for the device model are built into the
overwritten by new data.</li> kernel to substantially improve the granularity of Control Flow
<li>Kernel stack allocations are zeroed to make most uninitialized Integrity (CFI) and reduce attack surface.</li>
data usage vulnerabilities harmless.</li> <li>4-level page tables are enabled on arm64 to provide a much larger
<li>Assorted attack surface reduction through disabling features or address space (48-bit instead of 39-bit) with significantly higher
setting up infrastructure to dynamically enable/disable them only as entropy Address Space Layout Randomization (33-bit instead of
needed (perf, ptrace).</li> 24-bit).</li>
<li>Assorted upstream hardening features are enabled, including many <li>Random canaries with a leading zero are added to the kernel heap
which we played a part in developing and landing upstream as part of (slub) to block C string overflows, absorb small overflows and detect
our linux-hardened project (which we intend to revive as a more active linear overflows or other heap corruption when the canary value is
project again).</li> checked (on free, copies to/from userspace, etc.).</li>
</ul> <li>Memory is wiped (zeroed) as soon as it's released in both the
</li> low-level kernel page allocator and higher level kernel heap allocator
<li>Prevention of dynamic native code execution in-memory or via the filesystem (slub). This substantially reduces the lifetime of sensitive data in
for the base OS without going via the package manager, etc.</li> memory, mitigates use-after-free vulnerabilities and makes most
<li>Filesystem access hardening</li> uninitialized data usage vulnerabilities harmless. Without our
</ul> 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>
<section id="more-complete-patching"> <section id="more-complete-patching">
@ -388,17 +462,7 @@
<p>This is an incomplete list of other GrapheneOS features.</p> <p>This is an incomplete list of other GrapheneOS features.</p>
<ul> <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>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 <li>Low-level improvements to the <a href="/faq#encryption">filesystem-based
full disk encryption</a> used on modern Android</li> full disk encryption</a> used on modern Android</li>
<li>Support creating up to 16 secondary user profiles (15 + guest) instead of <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 sandboxed Google Play feature. In the future, it will be used to distribute
first-party GrapheneOS builds of externally developed open source apps with first-party GrapheneOS builds of externally developed open source apps with
hardening applied.</li> 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, <li><a href="https://github.com/GrapheneOS/PdfViewer">PDF Viewer</a>: sandboxed,
hardened PDF viewer using HiDPI rendering with pinch to zoom, text selection, hardened PDF viewer using HiDPI rendering with pinch to zoom, text selection,
etc.</li> etc.</li>