You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes, you're right. If the client specifies that it sends 4GB of the message, and it sends 3.9GB and maintains the connection open, the server must allocate that memory expecting the client sends the remaining 0.1GB of the message.
Once #54 has been merged, that maximum could be specified by a parameter for the FramedTcp listener. Nevertheless, I think adding a maximum only adds more work for the attacker, but it's still vulnerable. The attacker only needs to create more connections leaving incomplete messages.
I think a better solution to protect against this attack is to close the server FramedTcp connection if the endpoint is not sending more fragments when it is in the middle of building a framed message. This "timeout" could also be configured by #54 when the listener is created, even you could mix both, a maximum and a timeout.
If not possible, it may lead to Deny of Service with malicious clients.
The text was updated successfully, but these errors were encountered: