A quick update about Copy Fail: the short answer is your fly.io Machines and Sprites are safe and you almost certainly don’t need to worry about it.
There is one caveat: if you’re handing the same Machine or Sprite to multiple untrusted end-users (e.g. repurposing one instance as a multi-tenant sandbox) you might have an issue, though we’re working on mitigating that as well. However, if that’s the case, you’re probably holding the platform wrong. Email us at security@fly.io and we’ll help you get sorted.
Ok, that out of the way, a quick overview of Copy Fail: it’s a Local Privilege Escalation vuln that allows an unprivileged user with a shell on a host to execute code as root. The full writeup is here but the gist is a user can write to a socket that exposes kernel-level cryptographic primitives and use that to modify the in-memory version of a setuid binary in order to execute that modified version, rather than the version on-disk.
The first thing to note here is this requires a user to have shell access on the host. Anyone who spins up a Machine or Sprite has root access out of the gate, so that’s not particularly interesting, and this is why we say it doesn’t much matter unless you are giving multiple untrusted users access to the same Machine/Sprite.
The second thing to note is this exploit can only be used for a guest-to-host pivot in a shared-kernel environment (think: containers). Machines run on a memory-safe hypervisor and do not share kernels. Sprites are containers and they do share a kernel with the underlying Machine, but that Machine is still yours and breaking out of the Sprite container to the Machine doesn’t increase your access. The kernel is shared with the Machine, not across customers: every customer’s Sprites live inside their own Machines.
This doesn’t mean we’re standing by, just that there’s no need for panic-and/or-freak-out. AF_ALG is a userspace gateway to the kernel’s crypto APIs, which is useful in some setups but not commonly reached by typical workloads. The bug is in a specific code path that has been patched, and we’ll bump our guest kernels shortly. We’re also blacklisting the affected modules on the physical hosts our hypervisors run on as belt-and-suspenders.