On Tue, Nov 23, 2021 at 12:41 PM Ian Denhardt <i...@zenhack.net> wrote:
> Wouldn't releasing it on return allow the caller to cause runaway memory > usage by just never sending the finish? the return entry needs to be kept > around in case calls are pipelined on it, and itself might take up some > space (arguably it should count against the limit too...). > In all honesty, this isn't a very good defense against resource exhaustion attacks either way. The problem that motivated it was actually badly-written apps that would stream a whole large HTTP response body without paying attention to backpressure. Technically the callee doesn't need to keep the whole response struct in memory, only any returned capabilities and their paths. The current implementation does keep the whole struct though. My general opinion about resource exhaustion is that it's not so much a security issue as an abuse issue. These attacks create a temporary nuisance / disruption, but no permanent damage. It's probably impossible to anticipate every attack. But, since the attacks don't actually get anything for the attacker, they are much more rare than you might think, and it's usually fine to respond reactively by revoking capabilities, banning users, blocking IPs, etc. If the problem recurs then you start investing new safeguards against the specific scenario. -Kenton -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAJouXQkNQVASw4QisbtnOvywO5330tWd9muzMpDx31i26piyCQ%40mail.gmail.com.
