Skip to content

Latest commit

 

History

History
151 lines (132 loc) · 11.6 KB

threat-modeling.md

File metadata and controls

151 lines (132 loc) · 11.6 KB

Threat Model Analysis for envoyproxy/envoy

Threat: Malicious xDS Configuration Injection

  • Threat: Malicious xDS Configuration Injection
    • Description: An attacker compromises the xDS server (control plane) or the communication channel between Envoy and the xDS server. They inject a malicious configuration that redirects traffic, disables security features, or exposes internal services. This could involve modifying Listeners, Clusters, Routes, or Endpoints.
    • Impact:
      • Complete traffic hijacking.
      • Exposure of sensitive internal services.
      • Denial of service.
      • Data exfiltration.
    • Affected Envoy Component: xDS API (Listener, Cluster, RouteConfiguration, Endpoint, Secret Discovery Service (SDS)), Configuration parsing logic.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • mTLS: Enforce mutual TLS (mTLS) between Envoy and the xDS server.
      • Configuration Validation: Implement strict schema validation and semantic checks on all configurations received from the xDS server.
      • Digital Signatures: Use digital signatures to verify the integrity and authenticity of configurations.
      • Access Control: Implement strong authentication and authorization for the xDS server.
      • Auditing: Log all configuration changes and access attempts to the xDS server.
      • Secure Configuration Source: Use a secure, trusted source for configurations (e.g., HashiCorp Vault, AWS Secrets Manager).

Threat: Rogue Envoy Instance Joining Mesh

  • Threat: Rogue Envoy Instance Joining Mesh
    • Description: An attacker introduces a malicious Envoy proxy instance into the service mesh. This rogue instance can intercept, modify, or drop traffic.
    • Impact:
      • Man-in-the-middle (MITM) attacks.
      • Data breaches.
      • Service disruption.
    • Affected Envoy Component: Service Discovery, Mesh Communication (inter-Envoy communication), potentially xDS if the rogue instance attempts to register.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • mTLS: Enforce mTLS for all inter-Envoy communication within the mesh. This ensures only authorized Envoy instances can communicate.
      • SPIFFE/SPIRE: Use SPIFFE/SPIRE or a similar system to provide strong, verifiable identities to Envoy instances.
      • Network Segmentation: Use network policies to restrict communication between Envoy instances to only authorized paths.
      • Monitoring: Monitor for unexpected Envoy instances joining the mesh and alert on anomalies.

Threat: Admin Interface Exposure

  • Threat: Admin Interface Exposure
    • Description: The Envoy admin interface (typically on port 9901) is exposed to unauthorized access, allowing an attacker to view configuration, statistics, and potentially modify runtime settings.
    • Impact:
      • Information disclosure (configuration, metrics).
      • Potential for denial of service by manipulating runtime settings.
      • Gaining insights for further attacks.
    • Affected Envoy Component: Admin interface (/listeners, /clusters, /stats, etc.).
    • Risk Severity: High
    • Mitigation Strategies:
      • Disable in Production: Disable the admin interface in production environments unless absolutely necessary.
      • Network Restrictions: Restrict access to the admin interface to trusted networks and IP addresses using network policies or firewall rules.
      • Authentication: Implement strong authentication (e.g., OAuth2, basic auth with strong passwords) for the admin interface.
      • Least Privilege: Run Envoy with the least necessary privileges to limit the impact of a compromised admin interface.

Threat: Malicious Filter Injection

  • Threat: Malicious Filter Injection
    • Description: An attacker injects a malicious filter into the Envoy filter chain. This could be done through a compromised control plane, a vulnerability in a custom filter, or by exploiting dynamic filter loading. The malicious filter can modify requests/responses, steal data, or cause denial of service.
    • Impact:
      • Data exfiltration.
      • Request/response modification.
      • Bypass of security controls.
      • Denial of service.
    • Affected Envoy Component: Filter Chain, Filter Manager, potentially dynamic filter loading mechanisms (if used).
    • Risk Severity: High
    • Mitigation Strategies:
      • Static Compilation: Statically compile custom filters whenever possible to reduce the attack surface.
      • Secure Build Pipeline: Use a secure build and deployment pipeline for custom filters, including code review and vulnerability scanning.
      • Filter Validation: Implement strict validation of filter configurations, including schema validation and whitelisting of allowed filters.
      • Limit Dynamic Loading: Minimize or avoid the use of dynamic filter loading in production environments.
      • Sandboxing: If dynamic loading is necessary, consider using sandboxing techniques (e.g., WebAssembly) to isolate filters.

Threat: Regular Expression Denial of Service (ReDoS) in Filters

  • Threat: Regular Expression Denial of Service (ReDoS) in Filters
    • Description: An attacker crafts a malicious request that exploits a poorly written regular expression in an Envoy filter (e.g., HTTP header matching, routing rules). This causes excessive CPU consumption, leading to denial of service.
    • Impact:
      • Denial of service.
      • Resource exhaustion.
    • Affected Envoy Component: Any filter using regular expressions (e.g., envoy.filters.http.router, envoy.filters.http.header_to_metadata, custom filters).
    • Risk Severity: High
    • Mitigation Strategies:
      • Regular Expression Review: Carefully review all regular expressions used in Envoy configurations and custom filters for potential ReDoS vulnerabilities.
      • Regular Expression Testing: Use tools to test regular expressions against known ReDoS attack patterns.
      • Limit Complexity: Avoid using overly complex or nested regular expressions.
      • Timeouts: Implement timeouts for regular expression matching.
      • Safe Regex Libraries: Use regular expression libraries that are known to be resistant to ReDoS attacks (e.g., RE2).

Threat: Buffer Overflow in Custom Filters or Extensions

  • Threat: Buffer Overflow in Custom Filters or Extensions
    • Description: A vulnerability in a custom filter or extension (e.g., written in C++) allows an attacker to trigger a buffer overflow, potentially leading to code execution or denial of service.
    • Impact:
      • Remote code execution.
      • Denial of service.
      • Privilege escalation.
    • Affected Envoy Component: Custom filters or extensions, particularly those written in languages susceptible to memory safety issues (C/C++).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Memory-Safe Languages: Use memory-safe languages (e.g., Rust, Go) for custom filters and extensions whenever possible.
      • Code Review: Conduct thorough code reviews of custom filters and extensions, focusing on memory safety.
      • Fuzzing: Use fuzzing techniques to test custom filters and extensions for vulnerabilities.
      • Static Analysis: Use static analysis tools to identify potential buffer overflows and other memory safety issues.
      • Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP): Ensure these operating system security features are enabled.

Threat: HTTP/2 Header Smuggling

  • Threat: HTTP/2 Header Smuggling
    • Description: An attacker exploits discrepancies in how Envoy and the upstream server handle HTTP/2 headers, allowing them to inject malicious headers or bypass security controls. While the upstream server is involved, the vulnerability exists because of how Envoy handles and forwards these headers.
    • Impact:
      • Request smuggling.
      • Bypass of security filters.
      • Potential for data exfiltration or command injection.
    • Affected Envoy Component: HTTP/2 codec (envoy.http_connection_manager), upstream connection handling.
    • Risk Severity: High
    • Mitigation Strategies:
      • Upstream Server Compatibility: Ensure the upstream server is fully compliant with the HTTP/2 specification and handles headers correctly.
      • Header Validation: Implement strict validation of HTTP/2 headers in Envoy, including header name and value sanitization.
      • Envoy Updates: Keep Envoy up-to-date to benefit from the latest security fixes and improvements in the HTTP/2 codec.
      • Web Application Firewall (WAF): Use a WAF in front of Envoy to provide an additional layer of protection against HTTP/2 smuggling attacks. (Note: WAF is an additional layer, not a direct Envoy mitigation).

Threat: TLS Downgrade Attack

  • Threat: TLS Downgrade Attack
    • Description: An attacker intercepts the initial connection and forces Envoy to use a weaker TLS protocol or cipher suite, making the connection vulnerable to eavesdropping.
    • Impact:
      • Man-in-the-middle (MITM) attacks.
      • Data breaches.
    • Affected Envoy Component: TLS configuration (envoy.transport_sockets.tls), Listener.
    • Risk Severity: High
    • Mitigation Strategies:
      • Disable Weak Protocols and Ciphers: Configure Envoy to only support strong TLS protocols (TLS 1.3, TLS 1.2) and cipher suites.
      • HSTS (HTTP Strict Transport Security): Use HSTS to instruct browsers to always connect to the server using HTTPS.
      • Certificate Pinning: Consider certificate pinning for critical services to prevent MITM attacks using forged certificates.

Threat: Sensitive Data Leakage in Logs

  • Threat: Sensitive Data Leakage in Logs
    • Description: Envoy logs contain sensitive information (e.g., API keys, passwords, PII) due to misconfiguration, verbose logging, or logging of request/response bodies.
    • Impact:
      • Data breaches.
      • Compliance violations.
      • Reputational damage.
    • Affected Envoy Component: Access logging configuration, custom filters that log data.
    • Risk Severity: High
    • Mitigation Strategies:
      • Log Redaction: Implement log redaction techniques to mask sensitive data before it is written to logs.
      • Logging Levels: Carefully configure logging levels to avoid unnecessary verbosity.
      • Avoid Logging Sensitive Data: Avoid logging sensitive headers, request/response bodies, or other data that could contain PII or credentials.
      • Data Loss Prevention (DLP): Use DLP tools to monitor logs for sensitive data and alert on potential leaks.
      • Structured Logging: Use a structured logging format (e.g., JSON) to make it easier to parse and filter logs.