figmaOct 23, 2023

Server-side sandboxing: Virtual machines | Figma Blog (opens in new tab)

Virtual machines provide strong workload isolation by separating guest systems from the host and from one another through a hypervisor. However, VMs are not a complete security solution: hypervisor vulnerabilities can enable escapes, while compromised workloads may still abuse network access or credentials. Figma therefore treats VMs as one layer in a broader defense-in-depth sandboxing strategy. ## The VM Security Model - A VM acts like an independent computer with its own CPU, memory, disk, and operating system. - The hypervisor manages multiple VMs on a physical host and enforces separation between: - The host and guest VMs - Individual guest VMs - The primary escape risk is a **VM escape**, in which malicious code breaks through the guest boundary and accesses the host or other guests. - Hypervisors provide a useful security boundary, but they have a large and complex attack surface because they mediate operating-system and hardware operations. - Cloud providers such as AWS and Microsoft Azure rely heavily on hypervisor-based VM isolation, meaning most cloud workloads inherently depend on this boundary unless they use bare-metal instances. ## VM Permissions and Blast Radius - Preventing VM escapes is only one part of the security model. - A compromised workload may still: - Make network calls to exfiltrate data - Invoke other services - Abuse credentials assigned to the VM - VM capabilities must therefore be restricted to limit the damage caused by a compromised job. - Security depends not only on the hypervisor, but also on carefully controlling the guest’s permissions, network access, and available resources. ## Engineering Trade-offs - VMs generally offer stronger isolation than lighter-weight mechanisms such as containers and seccomp. - Their disadvantages include greater operational complexity, resource overhead, and dependence on the security of the hypervisor. - Building or deeply analyzing a specialized hypervisor requires substantial expertise because of its broad attack surface. - In many cloud environments, relying on VMs is unavoidable, so teams should focus on reducing guest privileges and layering additional controls around the VM. A VM should be treated as a strong isolation boundary, not an all-purpose security guarantee. The safest design combines hypervisor isolation with restricted permissions, controlled networking, and other defenses that minimize the impact of a compromised workload.

seccompcloud-securityvirtual-machinesserver-side-sandboxing+3

figmaOct 23, 2023

Server-side Sandboxing: An Introduction | Figma Blog (opens in new tab)

Server-side sandboxing helps contain the damage caused by vulnerabilities in software that processes untrusted user input. This is especially important for image processing, parsing, compression, and thumbnailing libraries often written in memory-unsafe languages, as demonstrated by ImageTragick. Figma argues that sandboxing complements—rather than replaces—secure coding by limiting a compromised workload’s access to data, services, and infrastructure. ## Why Server-Side Sandboxing Matters - Modern SaaS applications must process user-generated content using complex libraries. - Many of these libraries are written in C or C++, which are vulnerable to memory-corruption bugs. - ImageTragick showed how a vulnerability in ImageMagick could enable remote code execution when processing user-supplied images. - Preventing every vulnerability through rewrites, memory-safe languages, or program analysis is expensive and imperfect. - Sandboxing provides defense in depth by containing failures when vulnerabilities are exploited. ## Figma’s Server-Side Risk - Figma uses server-side components such as RenderServer, a C++ version of the editor, along with third-party libraries for graphical data. - Malicious input processed directly inside production infrastructure could allow an attacker to: - Access data belonging to other jobs - Make requests to internal production services - Move laterally through the environment - Compromise additional systems - Sandboxing reduces the external interfaces and resources available to potentially compromised workloads. ## Common Sandboxing Approaches - The article introduces three major sandboxing primitives: - **Virtual machines (VMs):** Isolate workloads through a hypervisor and separate guest operating systems. - **Containers:** Isolate workloads using operating-system-level mechanisms and container engines. - **Seccomp:** Restricts the system calls a program is permitted to make. - Each approach involves trade-offs in security properties, operational complexity, performance, and suitability for different workloads. - The article’s broader goal is to help teams compare these options and select an appropriate combination of isolation techniques. ## Choosing an Appropriate Strategy - Sandboxing technologies have historically been expensive, immature, or difficult to operate at scale. - Recent improvements have made virtualization, containment, and workload isolation more practical for a wider range of security teams. - Teams should evaluate sandboxing based on their workload’s risk, required interfaces, resource needs, and acceptable operational trade-offs. Teams should treat sandboxing as a practical layer of defense around risky processing workloads, rather than relying solely on preventing vulnerabilities.

seccompwebassemblyc++application-security+3

figmaOct 23, 2023

Server-side sandboxing: Containers and seccomp | Figma Blog (opens in new tab)

Containers and seccomp provide lightweight alternatives to virtual machines for isolating untrusted server-side workloads. Containers rely on OS-level features such as namespaces, cgroups, privilege dropping, and mandatory access controls, while seccomp restricts which system calls a process can invoke. Figma’s conclusion is that containers are not secure by default: effective sandboxing depends on the runtime, kernel, configuration, and broader infrastructure design. ## Container Isolation and Its Attack Surface - Container escapes depend on three main components: - The container runtime implementation - Operating-system primitives and interfaces exposed to the runtime - Runtime configuration - On Linux, Docker commonly uses the `runC` runtime alongside: - Namespaces and cgroups - Privilege dropping - Seccomp - SELinux or AppArmor - Vulnerabilities in the kernel or runtime, as well as configuration mistakes, can allow malicious workloads to modify host files or execute host-level code. - Unlike many VM solutions, containers place more responsibility on operators to configure isolation correctly. ## Risks from Compromised Containers - Simply running untrusted code inside a container does not guarantee safety. - Container settings should be strengthened to prevent host takeover. - The surrounding architecture should limit what a compromised container can access. - A safer design may use containers with: - No mounted network devices - No credentials - No access to unrelated data - Containers can be placed in an isolated network, with orchestration systems passing inputs and collecting outputs through controlled channels. ## Seccomp as an Additional Boundary - Seccomp, or “secure computing mode,” restricts the system calls available to a process. - This can reduce the kernel attack surface available to malicious code running inside a container. - Seccomp works alongside container mechanisms rather than replacing them; isolation depends on combining syscall restrictions with carefully configured namespaces, privileges, access controls, and infrastructure. ## Figma’s Evaluation Criteria Figma assesses sandboxing technologies using two questions: - Can a malicious workload escape its container and affect the host? - If it cannot escape, can it misuse the container’s permissions to reach other systems or cause harm? The practical recommendation is to treat containers as configurable security primitives, not automatically secure sandboxes. Use restrictive seccomp and container configurations, minimize credentials and connectivity, and design the surrounding system so that a compromised workload has limited impact.

seccompdockercgroupscontainer-sandboxing+4