Skip to content

Latest commit

 

History

History
46 lines (39 loc) · 5.22 KB

File metadata and controls

46 lines (39 loc) · 5.22 KB

Attack Surface Analysis for facebook/folly

  • Description: Vulnerabilities in Folly's string and buffer management implementations (fbstring and IOBuf) could lead to buffer overflows, use-after-free errors, or other memory corruption issues.
  • How Folly Contributes: fbstring and IOBuf are complex, performance-optimized implementations that handle memory management. Bugs within these Folly components are the direct source of risk.
  • Example: An attacker sends a specially crafted string that, when processed by a function using fbstring::append, triggers a buffer overflow due to an integer overflow in size calculation within Folly's code.
  • Impact: Arbitrary code execution, allowing the attacker to take complete control of the application.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Fuzzing: Extensively fuzz test all code paths that handle user input and interact with fbstring and IOBuf. Use tools like AFL++, libFuzzer, or Honggfuzz.
    • Static Analysis: Employ static analysis tools (e.g., Clang Static Analyzer, Coverity) to identify potential memory safety issues.
    • Dynamic Analysis: Run the application under memory safety tools like AddressSanitizer (ASan), MemorySanitizer (MSan), and Valgrind during development and testing.
    • Input Validation: Sanitize and validate all input before it reaches fbstring or IOBuf operations. Enforce length limits and character restrictions. (While input validation is crucial, it doesn't eliminate the risk of bugs within Folly).
    • Code Reviews: Thoroughly review code that uses fbstring and IOBuf, paying close attention to memory allocation, resizing, and boundary conditions.
    • Stay Updated: Keep Folly up-to-date to benefit from security patches.
  • Description: Vulnerabilities within folly::dynamic's parsing or type handling could lead to type confusion, unexpected type conversions, and potentially exploitable logic errors, even with seemingly valid input.
  • How Folly Contributes: The risk stems from potential bugs within Folly's implementation of folly::dynamic, not just from application misuse.
  • Example: An attacker provides a carefully crafted, but syntactically valid, JSON payload that exploits a subtle bug in folly::dynamic's type conversion logic, leading to an unexpected type being used in a later operation.
  • Impact: Code injection, denial-of-service, data corruption, or other application-specific vulnerabilities, depending on how the misused data is handled.
  • Risk Severity: High
  • Mitigation Strategies:
    • Schema Validation: Use a schema validation library. While this primarily mitigates application-level misuse, it can also help constrain input to avoid triggering obscure Folly bugs.
    • Input Sanitization: Sanitize input before parsing. This is less effective against vulnerabilities within Folly, but still good practice.
    • Fuzzing: Fuzz test folly::dynamic's parsing and processing logic extensively. This is crucial for finding bugs within Folly itself.
    • Stay Updated: Keep Folly up-to-date.
    • Consider Alternatives: If extremely high security is required for JSON processing, consider using a dedicated JSON library with a strong security focus and a smaller attack surface than folly::dynamic.
  • Description: Vulnerabilities within Folly's networking components (e.g., folly::AsyncSocket, folly::IOBuf used in networking) could lead to denial-of-service, buffer overflows, or other network-related attacks.
  • How Folly Contributes: The risk arises from potential bugs in Folly's networking implementation itself.
  • Example: A crafted network packet exploits a buffer overflow in folly::IOBuf as used within folly::AsyncSocket during parsing of network data.
  • Impact: Denial-of-service, arbitrary code execution (in the case of buffer overflows), information disclosure.
  • Risk Severity: High (can be Critical)
  • Mitigation Strategies:
    • Input Validation: Validate network data. While this helps, it doesn't eliminate the risk of bugs within Folly.
    • Rate Limiting: Implement rate limiting. This mitigates DoS, but not vulnerabilities within Folly.
    • Timeouts: Use appropriate timeouts.
    • Secure Protocols: Use TLS/SSL. This protects against eavesdropping/tampering, but not against vulnerabilities within Folly's handling of the protocol.
    • Fuzzing: Extensively fuzz test the network input handling code, specifically targeting folly::AsyncSocket and related components. This is crucial for finding Folly-specific bugs.
    • Stay Updated: Keep Folly up-to-date.