server-side-sandboxing

2 posts

figma

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.

figma

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.