(Adding Louis to cc per his request) Quoting Kenton Varda (2021-11-23 14:50:20) > On Tue, Nov 23, 2021 at 12:41 PM Ian Denhardt <[1]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.
What are apps *supposed* to do here? It isn't clear to me where else the backpressure is supposed to come from? Most apps are using sandstorm-http-bridge anyway, so they're just acting like normal http servers -- which generally write out data to the response stream as fast as the socket will take it. Skimming sendRequest() in the bridge's source, it looks like it just copies that data directly into the response stream. So I am confused as to what a "well written" app would do? > 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. I suppose that's a reasonable perspective; you're right that it's a different beast (Mark Miller wrote https://agoric.com/blog/all/taxonomy-of-security-issues/ which is really useful for thinking about this stuff. In his terminology we are talking about availibility rather than integrity). Every approach I've been able to think of for dealing with availability attacks gracefully in the capnp implementation itself does seem very fragile. Perhaps we could treat the flow limit as a soft limit, not bound the space taken up by returns and table entries, but track it, and provide a way to notify the user if it goes past a harder limit, at which point they can drop the connection if they want. If we were doing this at the process level I'd be inclined to just lean on the kernel's resource management, but I'd like to a least find a way to confine these issues to a single connection. Anyway, thanks for your input. -Ian -- 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/163770466055.10656.12069341791801755860%40localhost.localdomain.
