presentations/stagex/incyber.md

533 lines
18 KiB
Markdown
Raw Normal View History

2024-10-28 22:50:38 +00:00
---
_class: lead
paginate: true
backgroundColor: #fff
---
<style>
/* Changed in Marp 4.0.0. Re-center. */
section.lead {
display: flex;
}
div.two-columns {
column-count: 2;
}
</style>
# Expanding (Dis)Trust
How can we prove that our software has not been tampered during build time?
* Binary - software that's in a format computers can work with
* Compiler - builds software into binaries
* Hashing - takes a data set and produces a fixed length string
<!--
* This talk is a "yet another" supply chain security talk, but likely unlike
most you have seen so far
* This is a question relevant to everyone who ships software. At some point in
our supply chains, we rely on compilers, and software libraries which are part
of operating systems we use, different language ecosystems etc.
* What if there are issues in the source code of the app, third party libraries,
OS packages, cli tools or additional software that your app requires to be
built or run
* How do we do this today? We don't really have great tools to do this. There is
monitoring, we can do static analysis etc., but these are not a direct way of
ensuring our software wasn't tampered, but rather monitor the environment.
-->
---
# Anton Livaja
Co-Founder & Security Engineer at Distrust (https://distrust.co)
* Firm specializing in high assurance security consulting and engineering.
* Mission: to improve the security, privacy and freedom of as many people as
possible through working on fundamental security problems and creating open
source solutions.
* Clients: electrical grid operators, healthcare providers, fin-tech companies
and more.
<!--
* We specialize in supply chain security, operating system engineering, infrastructure hardening, and applied cryptography
* Introduce some problems teams maybe weren't even thinking about
-->
---
# Ken Thompson's Reflections on Trusting Trust
> **[The moral is obvious. You can't trust code that you did not totally create
yourself**. (Especially code from companies that employ people like me.) No
amount of source-level verification or scrutiny will protect you from using
untrusted code...]
<!--
* TODO: who is Ken Thompson is a computer scientist from Bell Labs, read a
Air Force paper where he got this idea
* Even if you review your source code and verify it's secure, that's not enough,
as the compiler can still modify code
* This is an unexplored attack surface area I will do my best to contextualize
it and give you a good intuition about it
* I won't open the can of worms on whether it's better to use open source
software in the context of security, but I'm firmly in the camp of don't trust,
verify
-->
---
![](http://www.gne.com.sg/wp-content/uploads/2017/11/SolarWinds-logo.png)
<!--
* One of the most significant breaches in recent history - Orion software platform - a monitoring tool to help orgs manage their infra including networks, servers, applications, dbs etc.
* While not directly the result of compiler compromise, it is directly related to the issue at hand. Rather than a compiler, in this case it was the environment that caused the issue
* Build system injected malicious code
* Happened because we don't have a simple method to ensure that software is tamper evident
* 1000s of enterprise and government customers had their systems completely exposed
* This company is one of the GO TO companies for cybersecurity solutions
* The other thing that happened is that the APT stole cybertooling and weaponized
it and used to improve their evasive abilities
* This means that IP, government secrets etc could have been leaked
* I never saw a proper response and retro on how to prevent this from happening
again
-->
---
# What's the Answer?
* Integrity hashes are already widely used
* Determinism / Reproducibility
* > Method of building software which ensures that the resulting binary for
a piece of software is always bit-for-bit identical.
* When something is bit-for-bit identical each time it is _deterministic_
* Once something is _deterministic_, it can be _reproduced_
<!--
* We use integrity hashes to ensure that the software is not modified between the
download source (CDN etc.) and end user
* You may be thinking that it's likely that most software is already deterministic
by default - but it's not. This is because of things like time stamps, linking order,
compilation flags, environment variables etc.
* This becomes very powerful when we start to reproduce the same software in
multiple different environments, and by different agents. Different hardware,
different OS, different person etc.
* So determinism is the method that allows us to easily and quickly check if
something new has been added to a binary
* To make it clear, there are integrity hashes currently available for software,
but they are nearly never deterministic, which means they only defend you from
compromise of the last leg of the trip, from the CDN/server to the end user, but
anything upstream is still susceptible to tampering, and there is no way to
reproduce the software to verify the hash matches, you can only check that the
binary you downloaded matches the hash they posted online and signed.
* How do we apply this to our tech stack?
-->
---
# How Deep Do We Have to Go?
* Software Application
* First Party Code
* Third Party Code
* Build and Runtime Environment
* Operating System + Packages
* Additional CLI / Tools
* Compiler
<!--
* We need everything to be deterministic - this is not how software is currently
built
* And yes this is not simple to do... so let's talk about how we can achieve this
-->
---
# Adequate Solution
* Allows us to make the whole tree deterministic
* Can be easily reproduced (deterministically)
* Drop in replacement for the current approach
---
# Bootstrapping our Way Up
![right:0% left:0%](https://mermaid.ink/svg/pako:eNotjrsOgzAMRX8l8gw_kKFSga2dypgwWImBSHkpJANC_HtTiif73CP5HqCCJuCwJIwre3-kZ3Weog8uGktpYm37YJ14UfJkp3_cXbAX475lcmygSF6TV4a22-gvYxDPGK1RmE3wEzTgKDk0uv47fp6EvJIjCbyummYsNkuQ_qwqlhzG3SvgORVqIIWyrMBntFu9StSYaTBYe7ubnl_6WELh)
<!-- TODO: add graph of going from compiler up to OS + deps and then to application -->
---
# Who Compiles the Compiler?
* Mostly downloaded as a binary
* Even if the compiler is built from source, usually another compiler is used to do so
* This means there is no clear providence to how we went from nothing to having a usable compiler
<!--
* Maintainers of open source software are the people that often are the ones building
this software, and even in large organizations like Microsoft and Apple, they are
not using determinism to verify their software is secure
* For the most part the approach to addressing this has been to
use two different compilers to build the code, and while unlikely it is possible for both compilers to be compromised in the same manner
* We can also rely on reverse engineering but it's not a reliable and practical method
-->
---
# Bootstrapping Compilers
* Consists of "stages", and hundreds of steps of starting from a human auditable (256 byte) compiler written in hex0 and building up all the way up to a modern compiler
* Bootstrapping programming languages
<!--
* If you bootstrap, you have a compiler you can verify and trust
* Now you may be wondering okay this is great, but if a compiler like this wasn't used to build all the other software isn't that a problem...? Yes, it is, we are for the most part unaware of this risk, or didn't have a way to practically deal with it. More on the solution of that problem a few slides from now.
-->
---
# We Have a Compiler, Now What?
* Build all of the different dependencies we need:
* `linux kernel`
* `bash`
* `openssl`
* `git`
* Yes... I mean *everything* in your build environment
---
# Status Check-In
* So far we have:
* A fully deterministic compiler
* Used that compiler to build all our dependencies
* Last thing remaining: your application
<!-- Now this seems like a lot... and it is, so we went ahead and built
an open source solution that tries to address the problem -->
---
# Deterministic and Minimal Linux distribution
<!-- Speaker notes
* We tried to get the existing distributions to implement the necessary upgrades
to gain the security properties we are after but they wouldn't, so we were
forced to build our own Linux distribution.
Most Linux distributions are built for *compatibility* rather than *security*.
This results in a dramatic increase of attack surface area of an operating
system. StageX is designed to allow the creation of application specific
environments with a minimal footprint to eliminate attack surface area. Each
component of the toolchain installs only what it needs, and only packages what
it builds, resulting in a decreased attack surface.
StageX is the first Linux multisig distribution, is one of two fully
bootstrapped Linux distributions, is 100% reproducible and deterministic,
and can build complicated software with as few dependencies exposed as
possible.
-->
<hr />
<!--
TODO: include image describing traditional package building, by installing
_every_ dependency in a single OS, with a comparison of stagex only having mini
Containerfiles with just what each project needs. If done so, this graph can be
moved to a separate slide.
-->
| Distribution | Signatures | Libc | Bootstrapped | Reproducible | Rust deps |
|--------------|------------|-------|--------------|--------------|----------:|
| Stagex | 2+ Human | Musl | Yes | Yes | 4 |
| Debian | 1 Human | Glibc | No | Partial | 231 |
| Arch | 1 Human | Glibc | No | Partial | 127 |
| Fedora | 1 Bot | Glibc | No | No | 167 |
| Alpine | None | Musl | No | No | 41 |
<!-- NOTE: "Rust deps" is the amount of dependencies required to build a Rust
hello world -->
<!---
-- Unable to confirm the following:
| Guix | 1 Human | Glibc | Yes | Yes | 4 |
| Nix | 1 Bot | Glibc | Partial | Mostly | 4 |
--->
<!-- Add a link to a script that confirms/reproduces the dependency count for
building Rust hello world -->
---
# Full source bootstrapped from Stage 0
From a 256-byte compiler written in hex0, StageX bootstraps all the compiler
tools necessary to build the distribution, 100% deterministically.
- Stage 0: Getting a basic C compiler on x86
- Stage 1: Building GCC for x86
- Stage 2: Upgrading GCC for x86_64
- Stage 3: Building up-to-date toolchains
- Stage X: Shipping the software you know and love
---
# A Rust Example
```dockerfile
FROM stagex/pallet-rust@sha256:b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c AS build
ADD . /src
WORKDIR /src
ARG TARGET x86_64-unknown-linux-musl
RUN cargo build --release --target ${TARGET}
FROM scratch
COPY --from=build /app/target/${TARGET}/release/hello /usr/bin/hello
CMD ["/usr/bin/hello"]
```
<!--
* We could include other dependencies, let's say nettle, or gmp easily
* This may look very similar to what you may do with alpine linux, but the difference is that with alpine you are trusting single points of failure since none of the alpine packages are multi reproduced and signed - this
is why we made stagex - they also do not use bootstrapped compilers.
-->
<!-- TODO: make pallets a thing, test this. Include RUSTFLAGS to make static in
the pallet -->
---
# All packages in StageX are:
* Built using hash-locked sources
* Confirmed reproducible by multiple developers
* Signed by multiple release maintainers
<!-- Speaker notes
To ensure StageX remains a secure toolchain, there's some additional
maintenance that is performed compared to most distributions. This includes:
* Built using hash-locked sources. This ensures every developer gets the exact same copy of the code for each container, so no middleman could inject
malware, which helps with:
* Reproducing projects, ensuring they're built deterministically. This confirms
that no single developer, nor their machine, have been compromised. Once each
package is confirmed, they are...
* Signed by the release maintainers. These maintainers each build a copy of the
package locally and sign the containers with an OCI-compliant signature using
well-known OpenPGP keys.
---
-->
![bg right:35% 80%](https://mermaid.ink/svg/pako:eNptUstugzAQ_BVrzyQU0-ZBpR7S9lhVKr2FHIy9gCuDkbFTRYh_ryFVgtL6YO_OjHdk7_bAtUBIoFD6m1fMWPK5yxri185JJaL9dBzIYvFEPrA1WjiO0f4SHmZi-q-Y_hFf60zKVJZNtB_3W55eeDrnpwu_JgpZh1eYzmEIoEZTMyn8A_tRlIGtsMYMEh8qWVY2g2BGPKfpmVsqlqMihTboq77nX8gt6Yk-ohl_KiFH2clc4SMZMsiawVsxZ3V6ajgk1jgMwGhXVpAUTHU-c61gFl8kKw2rb9BXIa02F1BpJtCnPdhTO_amlJ31Blw3hSxH3Bnl4cratkvCcKSXpbSVy5dc12EnxdjI6rhdhSu62jAa42ods4c4FjyPtpuC3keFWN9FlMEwBICT_9t5EKZ5GH4Asmmvxw)
<!--
flowchart TB
Build1[Build] --\> Reproduce1[Reproduce]
Build2[Build] --\> Reproduce2[Reproduce]
Reproduce1 --\> Sign1[Sign]
Reproduce2 --\> Sign2[Sign]
Sign1 --\> Release
Sign2 --\> Release
{
"theme": "light",
"themeCSS": ".label foreignObject { overflow: visible; }"
}
-->
<!-- TODO: talk about bootstrapping, incl. corrupt compilers in distro
toolchain -->
<!-- https://distrowatch.com/images/other/distro-family-tree.png -->
---
# Multi-Signed OCI Images
Multiple maintainers can each sign individual images, with the container
runtime enforcing _multiple_ signatures by maintainers to ensure no individual
maintainer could have tampered with an image.
<!-- Speaker notes
StageX uses the Open Container Initiative standard for images to support the
use of multiple container runtimes. Because OCI images can be signed using
OpenPGP keys, this allows the association of built images to trusted
maintainers, which can enable developers to build their software using StageX,
without having to build the entire StageX toolchain for themselves.
Creating a network of trust builds a relationship between developers and
maintainers, allowing developers to choose maintainers that implement key
management policies that match their standards. For example, Distrust signing
keys are always stored on smart cards or airgapped machines, avoiding key
exfiltration attacks and limiting key exposure to trusted computation
environments.
---
-->
[![](https://mermaid.ink/svg/pako:eNpdklFrgzAQx79KuGdbV91s62DQpmNPZbDube4hJqdmRFNi7Cjid1-sa7EGAvn_f3c5LpcWuBYIMWRK__KCGUs-d0lF3NpvvvZMVtZtNGTzTWazF_Km_-F2DLcTSMeQTuBmkJReb5poOtFD_EdT27uEkUFvBnhQoimZFK6ltscJ2AJLTCB2RyXzwibgjQA9HAY2VyxFRTJtUObVe_qD3JKW6BOa_m1icpK1TBU-ky6BpOpcKdZYfThXHGJrGvTA6CYvIM6Yqp1qjoJZ3EmWG1ZeQwbzVUirzS1SaSbQyRbs-dgPI5eXVriuMpn3fmOUswtrj3Xs-z2e59IWTTrnuvRrKfrJFad15EdBtGJBiNEyZE9hKHi6WK-y4HGRieXDImDQdR7gpf5-mPzlA3R_HuyhBw)](https://mermaid.ink/svg/pako:eNpdklFrgzAQx79KuGdbV91s62DQpmNPZbDube4hJqdmRFNi7Cjid1-sa7EGAvn_f3c5LpcWuBYIMWRK__KCGUs-d0lF3NpvvvZMVtZtNGTzTWazF_Km_-F2DLcTSMeQTuBmkJReb5poOtFD_EdT27uEkUFvBnhQoimZFK6ltscJ2AJLTCB2RyXzwibgjQA9HAY2VyxFRTJtUObVe_qD3JKW6BOa_m1icpK1TBU-ky6BpOpcKdZYfThXHGJrGvTA6CYvIM6Yqp1qjoJZ3EmWG1ZeQwbzVUirzS1SaSbQyRbs-dgPI5eXVriuMpn3fmOUswtrj3Xs-z2e59IWTTrnuvRrKfrJFad15EdBtGJBiNEyZE9hKHi6WK-y4HGRieXDImDQdR7gpf5-mPzlA3R_HuyhBw)
<!--
flowchart TD
MA[Maintainer A] --\> Go
MB[Maintainer B] --\> Go
MC[Maintainer C] --\> Go
MA --\> GCC
MB --\> GCC
MC --\> GCC
MA --\> Rust
MB --\> Rust
MC --\> Rust
{
"theme": "light",
"themeCSS": ".label foreignObject { overflow: visible; }"
}
-->
---
# Common toolchain dependencies
StageX comes with developer-loved tooling and languages, such as:
- `curl`
- `git`
- `bash`
- `openssl`
---
# Pallets
StageX will soon offer prebuilt containers including all the packages necessary to run
some of our most used software, such as:
- `rust`
- `go`
- `nodejs`
- `nginx`
- `redis`
- `postgres`
---
# Key Takeaways
StageX...
* Your software, at every point in the bootstrapped toolchain, can all be built
deterministically.
* Packages the software you're already using, but in a more secure manner.
* Is a drop in replacement, and has container support
<!--
Other distributions run their own package manager inside of containers
We use containers as our package manager
100% container native, no attack surface
By using StageX, you have the software you already use, with the assurance it
was built in a secure manner.
Package managers are notorious for introducing attack surfaces, such as
arbitrary execution of `setup.py` or post-download scripts, and by using Docker
as our package manager, we avoid all forms of spontaneous execution.
All StageX software is built deterministically, meaning you can be sure all
components listed in your Software Bill Of Materials hasn't been tampered with.
Because StageX provides a toolchain for you to build your software in the same
manner, your software can be sooper dooper pooper scooper secure.
-->
---
# What's Next?
* Adding SBOM
* Packaging more software
* Fully automating software updates
* Additional container runtimes like Podman and Kaniko
* Additional chip architecture support such as ARM and RISC-V
---
# How You Can Help
* Provide feedback
* Support with development efforts
* Become a sponsor
---
# Other Projects
This is only one part of the "Distrust Stack"
* [`keyfork`](https://git.distrust.co/public/keyfork): toolchain for generating and managing a wide range of cryptographic keys
* [`bootproof`](https://git.distrust.co/public/bootproof): tpm2 remote attestation
* [`reprOS`](https://codeberg.org/stagex/repros): OS designed for secure reproduction
* [`sigRev`](): open standard for signed code reviews
<!--
* This is why we are called Distrust we don't want you to have to trust anyone
* As Benjamin Franklin once said distrust and caution are the parents of security
-->
---
# Links
**Email**: anton@distrust.co / sales@distrust.co
**Matrix Chat**: #stagex:matrix.org
**Git Repo**: https://codeberg.org/stagex/stagex
Big thank you to sponsors who have supported the development of this project:
**Turnkey, Distrust, Mysten Labs**
Thank you to InCyber for hosting this fantastic event!