Skip to content

Latest commit

 

History

History
88 lines (69 loc) · 8.64 KB

threat-modeling.md

File metadata and controls

88 lines (69 loc) · 8.64 KB

Threat Model Analysis for reactivex/rxjava

Threat: Uncontrolled Observable Emission Flood (DoS)

  • Threat: Uncontrolled Observable Emission Flood (DoS)

    • Description: An attacker triggers an event source connected to an RxJava Observable. The attacker sends a massive number of events or data faster than downstream components can process, overwhelming the system due to a lack of backpressure handling within the RxJava pipeline.
    • Impact: Denial of Service (DoS). The application becomes unresponsive or crashes due to resource exhaustion (memory, CPU, threads, network connections). Other legitimate users are unable to use the application.
    • Affected RxJava Component: Observable creation (e.g., Observable.create(), Observable.fromPublisher(), event listener integrations), operators lacking backpressure support (e.g., missing onBackpressureXXX operators). The core issue is the misuse or absence of RxJava's backpressure mechanisms.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Implement backpressure handling: Use operators like onBackpressureBuffer, onBackpressureDrop, onBackpressureLatest, or throttleLatest to control the flow of data within the RxJava stream.
      • Use Flowable instead of Observable when backpressure is required. Flowable is designed for backpressure.
      • Limit the rate of event generation at the source if controllable and part of the RxJava integration (e.g., a custom Observable source).
      • Implement input validation and sanitization within the RxJava pipeline to prevent malicious input from triggering excessive emissions.
      • Monitor resource usage and set alerts for unusual activity.

Threat: Subscription Leak (Resource Exhaustion)

  • Threat: Subscription Leak (Resource Exhaustion)

    • Description: A logic error within the RxJava subscription management prevents Disposable.dispose() from being called on an RxJava subscription. The subscription remains active, consuming resources even though it's no longer needed. Repeated occurrences lead to resource exhaustion.
    • Impact: Gradual resource exhaustion (memory leaks, thread leaks), leading to performance degradation and eventual application instability or crashes.
    • Affected RxJava Component: Subscription / Disposable management. Any component that creates subscriptions (e.g., subscribe(), subscribeWith()) and fails to manage their lifecycle correctly.
    • Risk Severity: High
    • Mitigation Strategies:
      • Always call dispose() on Disposable objects when the subscription is no longer needed.
      • Use CompositeDisposable to manage multiple subscriptions and dispose of them together.
      • Use lifecycle-aware components (if applicable) to automatically manage subscriptions based on component lifecycle events, ensuring correct integration with RxJava.
      • Use operators like takeUntil, takeWhile, or using to automatically dispose of subscriptions based on specific conditions.
      • Use static analysis tools or code reviews to identify potential subscription leaks specifically within RxJava usage.

Threat: Unbounded Thread Pool Exhaustion (DoS)

  • Threat: Unbounded Thread Pool Exhaustion (DoS)

    • Description: An attacker triggers many concurrent operations scheduled on RxJava's default Schedulers.computation() or Schedulers.io() without any limits imposed by the RxJava pipeline. This creates an excessive number of threads, consuming system resources and causing a denial of service.
    • Impact: Denial of Service (DoS) due to thread exhaustion. The application becomes unresponsive or crashes.
    • Affected RxJava Component: Schedulers.computation(), Schedulers.io(), operators that use these schedulers implicitly (e.g., subscribeOn, observeOn), and failure to use custom, bounded Schedulers.
    • Risk Severity: High
    • Mitigation Strategies:
      • Use bounded thread pools: Create custom schedulers with limited thread pools using Schedulers.from(Executors.newFixedThreadPool(n)).
      • Carefully control the concurrency level using operators like flatMap with a maxConcurrency parameter within the RxJava chain.
      • Implement timeouts and retries with appropriate backoff strategies within the RxJava pipeline to prevent indefinite resource consumption.
      • Monitor thread usage and set alerts for excessive thread creation.

Threat: Race Condition in Shared Mutable State (within RxJava Streams)

  • Threat: Race Condition in Shared Mutable State (within RxJava Streams)

    • Description: Multiple RxJava streams (or different parts of the same stream) access and modify shared mutable data without proper synchronization mechanisms provided by or used in conjunction with RxJava. The attacker manipulates the timing of events to cause inconsistent data.
    • Impact: Data corruption, inconsistent application state, potentially leading to security vulnerabilities or incorrect business logic execution.
    • Affected RxJava Component: Any operator that accesses or modifies shared mutable state, especially when used with observeOn or subscribeOn to switch threads. Custom operators are particularly susceptible if they don't handle concurrency correctly.
    • Risk Severity: High
    • Mitigation Strategies:
      • Prefer immutable data structures whenever possible within the RxJava pipeline.
      • Use appropriate synchronization mechanisms: synchronized blocks, AtomicReference, ConcurrentHashMap, or other thread-safe data structures when interacting with shared state from within RxJava operators.
      • Carefully review the thread safety of any custom operators.
      • Use tools that can detect race conditions during testing.

Threat: Unhandled Exception Leading to Crash (within RxJava)

  • Threat: Unhandled Exception Leading to Crash (within RxJava)

    • Description: An operation within an RxJava stream throws an exception. The stream lacks an onError handler, causing the exception to propagate and potentially crash the application.
    • Impact: Application crash, denial of service.
    • Affected RxJava Component: subscribe() method (without an onError handler), any operator that can throw an exception and is not handled within the RxJava pipeline.
    • Risk Severity: High
    • Mitigation Strategies:
      • Always provide an onError handler in every subscribe() call.
      • Use operators like onErrorReturn, onErrorResumeNext, or retry to handle errors within the stream itself.
      • Implement a global error handler using RxJavaPlugins.setErrorHandler to catch any unhandled exceptions that escape the RxJava streams.
      • Use try-catch blocks within operators and propagate exceptions using onError.

Threat: Deadlock due to Blocking Operations (within RxJava)

  • Threat: Deadlock due to Blocking Operations (within RxJava)

    • Description: Improper use of blocking operations (like blockingSubscribe, blockingFirst) or incorrect synchronization within an RxJava stream leads to a deadlock. This is often exacerbated by limited thread pools.
    • Impact: Application hangs or becomes unresponsive, leading to a denial of service.
    • Affected RxJava Component: blockingSubscribe, blockingFirst, blockingIterable, blockingLatest, blockingMostRecent, blockingNext, any custom operator that uses blocking operations or incorrect synchronization within the RxJava context.
    • Risk Severity: High
    • Mitigation Strategies:
      • Avoid using blocking operations within RxJava streams whenever possible. Use asynchronous alternatives provided by RxJava.
      • If blocking operations are unavoidable, execute them on a dedicated, bounded thread pool managed in conjunction with the RxJava pipeline.
      • Use timeouts with blocking operations to prevent indefinite blocking.
      • Carefully analyze the dependencies between Observable streams to identify and eliminate potential circular dependencies that could lead to deadlocks within the RxJava logic.