Skip to content

Latest commit

 

History

History
50 lines (40 loc) · 5.15 KB

threat-modeling.md

File metadata and controls

50 lines (40 loc) · 5.15 KB

Threat Model Analysis for bumptech/glide

Threat: Denial of Service via Decompression Bomb

  • Threat: Denial of Service via Decompression Bomb

    • Description: An attacker provides a URL to a "decompression bomb" – a small image file that expands to a huge size when decoded. This could be a highly compressed JPEG, a PNG with a large IDAT chunk, or a GIF with many frames. Glide attempts to decode the image, consuming excessive memory and potentially CPU resources. Glide's internal handling of image decoding and resizing is directly involved.
    • Impact:
      • Application Crash (OOM): The application runs out of memory (OutOfMemoryError) and crashes.
      • Device Unresponsiveness: The device becomes slow or unresponsive due to excessive memory pressure.
    • Affected Component:
      • Glide's Downsampler and related classes responsible for image decoding and resizing.
      • BitmapPool (if the allocated bitmaps exceed the pool's capacity).
    • Risk Severity: High
    • Mitigation Strategies:
      • Resource Limits (Dimensions): Strictly limit the maximum dimensions (width and height) of images that can be loaded using override(). This is the most effective mitigation, and it directly interacts with Glide's configuration.
      • Resource Limits (File Size): While Glide doesn't directly offer file size limits before decoding, you can implement a check on the Content-Length header (if available) before passing the URL to Glide. This requires custom networking logic, but it's a preventative measure before Glide processes the image.
      • Timeout: Set a reasonable timeout for image loading (using Glide's request options or the underlying network library) to prevent the application from hanging indefinitely on a slow or malicious resource.

Threat: Server-Side Request Forgery (SSRF) via Glide

  • Threat: Server-Side Request Forgery (SSRF) via Glide

    • Description: The application uses Glide to load images from URLs provided by an untrusted source. An attacker crafts a URL pointing to an internal service. Glide's networking components make the request, potentially exposing internal resources. This leverages Glide's core functionality of fetching data from URLs.
    • Impact:
      • Information Disclosure: The attacker gains access to sensitive internal data or metadata.
      • Internal Service Manipulation: The attacker might be able to interact with internal services.
      • Bypassing Network Security Controls: The attacker uses the application as a proxy.
    • Affected Component:
      • Glide's networking components (e.g., HttpUrlFetcher, OkHttpUrlLoader, or custom ModelLoader implementations). These are core parts of Glide's functionality.
    • Risk Severity: High (especially in cloud environments)
    • Mitigation Strategies:
      • Strict URL Whitelisting: Implement a very strict whitelist of allowed image sources. Only load images from trusted domains. Do not allow user-supplied URLs directly. This directly controls what Glide is allowed to fetch.
      • Input Validation (URL Parsing): If user input must be used, rigorously validate and sanitize it, checking each URL component. Reject URLs pointing to internal IPs or hostnames. This is a preventative measure before the URL reaches Glide.
      • Disable Redirects (if appropriate): If redirects aren't needed, disable them using a custom ModelLoader or by configuring the underlying network library (which Glide uses). This limits Glide's ability to be tricked into accessing unintended resources.
      • Network Security Configuration (Android): Use Android's Network Security Configuration. While not directly Glide-specific, it's a crucial defense-in-depth measure that limits the network access of the entire application, including Glide.

Threat: Vulnerability in Glide Library Itself

  • Threat: Vulnerability in Glide Library Itself

    • Description: A security vulnerability is discovered in the Glide library code itself (e.g., in a custom Transformation, ModelLoader, or other component). This is a direct threat to the library's own code.
    • Impact: Varies depending on the nature of the vulnerability, but could include RCE, DoS, information disclosure, or other impacts.
    • Affected Component: The specific Glide component containing the vulnerability.
    • Risk Severity: Varies (could be Critical or High)
    • Mitigation Strategies:
      • Keep Glide Updated: Regularly update Glide to the latest version. This is the most important mitigation, directly addressing vulnerabilities within Glide itself.
      • Monitor Security Advisories: Monitor security advisories related to Glide. Be prepared to update quickly.
      • Use Dependency Analysis Tools: Use tools like OWASP Dependency-Check or Snyk to identify known vulnerabilities in Glide.