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>
<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>