DoS vector w/ Infinite Go Routines

[Ethen]

Risk Vector

Currently, the /v0/invariant endpoint can be exploited by an attacker to create infinite go routines on an application instance of Pessimism. While deduplication policies do exist within the ETL implementation, an attacker could meticulously request invariant deployments where deduplication would not occur for some time (eg. backfill from L1 genesis block). Eventually the machine running the Pessimism app would exhaust computation resources (ie. cpu, ram) to the point where the app could no longer function.

Mitigation(s)

• Introduce concurrency rate limiting within the Pessimism application logic (ie. MAX_GO_ROUTINES) OR
• Introduce a max number of active pipelines that can exist at once (ie. MAX_PIPELINES)

[nadir-akhtar-coinbase]

Another mitigation includes adding auth and per-user limits (even though I imagine we probably wouldn’t take this route this early, right?)

So with that context, I imagine we'd want to probably do both mitigations. That way neither becomes a method by which the app is susceptible to overload.

[Ethen]

@nadir-akhtar-coinbase Yes that could be a mitigation, however I'd imagine that any user based abstractions would be independent/upstream of the current service; i.e, in another potential service entirely given that PII would be at play.

As of right now, go routines are only created in the construction of a pipeline, so constraining pipeline counts may be the better approach starting out. Otherwise, we'd have to add concurrency rate limiting logic and wrapper functionality for spinning up and terminating routines.

However, if we were to say introduce dynamic based parallelism to other parts of the application (e.g, risk engine) then go routine limiting may become a factor.