[adilalperenciftci]

Part of #3303 (the CA-flag hole; the rest of RFC 5280 path validation listed there stays open).

Root cause

std/cryptography/tls13_cert's chain_verify_path walked intermediate certificates checking only subject/issuer DN matching and the signature, never basicConstraints.cA or keyUsage.keyCertSign. A leaf certificate a trusted CA issued could therefore act as an intermediate and sign a certificate for any host.

Solution

1. LeafCert records is_ca, has_key_usage and key_cert_sign.
2. Extension parsing decodes basicConstraints (2.5.29.19) and keyUsage (2.5.29.15); one read_extn_value helper skips the optional critical flag for these and for subjectAltName.
3. find_issuer_unused accepts an issuer only when is_ca == 1 and, if keyUsage is present, keyCertSign == 1.
4. tests/integration/crypto_tls13_cert has openssl-made chains whose names and signatures are all valid and whose signer is a cA=FALSE certificate (rejected), a CA without keyCertSign (rejected), or a CA with no keyUsage extension (accepted). Removing the check fails the first two.
5. A security changelog fragment in new_changelogs/.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

[paul-hammant]

Thanks - looking

[paul-hammant]

@nicolas-maman your unpushed work for #3310 and #3311 almost certainly edits the same chain_verify_path, so you could well have a merge conflict.

[paul-hammant]

Waiting on Nic's input, Adil - thanks for making this contrib.

You look to be quite the security researcher :)

[nicolas-maman]

@adilalperenciftci let me check your work, sorry I missed this. Thank you for your contribution!

[nicolas-maman]

Looks good, thank you once again.

[paul-hammant]

Hi @adilalperenciftci, what interests you about Aether may we ask?

[adilalperenciftci]

Hi @adilalperenciftci, what interests you about Aether may we ask?

hi, i came across aether while looking into actor-based languages. the actor model without a vm or gc got me intrested, so i started going through the repo and open issues. i saw #3303 and picked up the missing ca/key usage checks. i enjoy working on security code, especially tls/x509 validation, so it seemed like a good place to contribute.

[paul-hammant]

@adilalperenciftci thanks for this, and welcome. As you no doubt saw, I pushed a follow-up commit onto your branch: your leaf-as-intermediate test was rejecting the chain before the cA check ran, so I replaced it with openssl-made chains whose only defect is the signer's extensions, and added a changelog fragment. It merged and shipped in 0.856.0. The rest of #3303 (pathLenConstraint, EKU, critical extensions, name constraints, backtracking) is still open if you want more.

We're doing security research in the Aether repos too, and since your background is runtime security and PKI, some of it may interest you.

Containment in the language itself

• hide and seal except: a lexical block can decline to see names from the scopes around it, so a capability has to be passed in rather than reached for. It's checked at compile time.
• Containment and sandboxing: a builder-style grant list (fs paths, net hosts, env, exec, fork) enforced at run time, an LD_PRELOAD layer (libaether_sandbox) that checks libc calls against the same list, spawn_sandboxed for child processes, denial logging and a queryable audit log (std.audit). Per-function effect tags (@pure, @no_fs, @no_net, @no_os) are checked across the call graph. It also lists its own known gaps, starting with extern calls getting round the sandbox.
• --emit=lib: a shared library built from Aether can't use fs, net or os unless the build opts in with --with=fs,net,os, so an application that embeds it gets nothing by default.
• Aether compared with Capsicum, with std.capsicum and std.casper for the FreeBSD kernel side.
• Writing security-sensitive code: rules for the crypto and TLS code, each from a real defect in this tree. std.cryptography: tls13 chain verification checks only names and signatures (a CA's leaf can sign any host) #3303 fits its theme: the code passed its tests and still had the hole.

Running other languages' code under the same grant list

contrib/host/ embeds Lua, Python, Perl, Ruby, Tcl and JS in-process, and runs Java, Go and Aether-in-Aether as separate processes. Each is called as <lang>.run_sandboxed(perms, code). The same grants and the same LD_PRELOAD layer gate the guest interpreter's libc calls (the Python one, for example). Escaping from a guest interpreter is exactly the kind of thing we'd like more eyes on.

Up a level: infrastructure as an Aether composition

aeo is an orchestrator written in Aether. One composition brings up and tears down a dependency-ordered tree of FreeBSD jails, bhyve VMs, Linux containers (podman/docker/LXC), KVM VMs and bubblewrap sandboxes. Its confinement is one grammar (limit{} for resource caps; constrain{} for fd grants and egress/ingress policy) rendered to rctl/Capsicum/pf on FreeBSD and to cgroups/seccomp/network policy on Linux. It also verifies image digests before boot (attest(...)) and keeps a tamper-evident audit trail. Its threat model says what it does and doesn't claim, and aeo status reports supported: no / applied: no where it can't enforce a property that was asked for, rather than pretending it did.

Issues or PRs against any of these are welcome. A bypass of a boundary we claim is the most useful kind. But also any ideas you have for an IaC tech that should scale from hobbyist to in-house cloud soltions for corporates

[adilalperenciftci]

Thanks Paul. Since #3340 has merged and Nicolas is continuing #3334, I will avoid overlapping with that work and focus on independent Python host sandbox permission-lifecycle verification tests.