[nanomsg] Re: issue with "received" message size
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 10 Mar 2014 20:51:39 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Garrett,
Yes. I've implemented MAXMSGSIZE socket option back in ZeroMQ, but
it's still lacking in nanomsg. The semantics are: If the advertised
incoming message is larger than MAXMSGSIZE, message is not read and
the connection (for connection-based transports) is closed immediately.
I've also wanted to implement a limit on connections handled by a
single nanomsg socket, but I've never got so far.
Martin
On 10/03/14 17:17, Garrett D'Amore wrote:
> I’ve noticed that the message sizes supported by nanomsg are
> expressed as a 64-bit integer, and I’m thinking with NN_MSG is
> passed to nn_recvmsg(), it could expose the caller to tragic DoS if
> the peer is not trusted. In particular, it seems that a peer could
> ask a system to effectively allocate Terabytes of data for a
> message, without actually holding the message itself.
>
> Actually, reading the code, it seems that even if the caller
> supplies the message size to nn_recvmsg(), the underlying transport
> in stcp.c winds up allocating a message body based on the size
> expressed in the received header. So a sender could ask a peer to
> allocate gigabytes, terabytes, or petabytes(!) of RAM to hold a
> message, that it never actually has to send. This makes a denial
> of service attack also trivial; most systems do not hold up well
> under gigantic memory allocation requests.
>
> This seems tragically bad, potentially. I’d really like to see
> instead that there was a way to limit message allocation size, to
> guard servers from bad peer implementations. What I’m thinking is
> an upper bound on message size, that could be tunable via a socket
> option. (And there could be an option to disable the check, e.g.
> set the limit to 0. But this would be not recommended in
> situations where all participants are not trusted.) A default sane
> limit would probably be around 1M. While a big largish, unless a
> client can arrange to connect and hold open thousands of
> connections to the server, the effective damage is probably
> limited.
>
> A better solution would be to calculate the maximum connection rate
> the server can manage multiplied by the “timeout” for idle
> connections, and divide that into the maximum memory pool we would
> be willing to risk. If process is allowed to grow to say 1GB, and
> can open 1000 connections per second, and the timeout is 10
> seconds, then 100KB is the “safe” limit to guard against a network
> assault.
>
> My guess is most upper layer protocols have smaller message sizes —
> e.g. 64K or smaller — and so they could tune this value down to
> further harden their limit.
>
> The other thing that could be done, is to keep track of
> outstanding connections and utilization, and refuse to accept()
> connections once the total utilized buffer space exceeded a
> configured limit.
>
> It would be even more useful if we had the ability, during
> connection establishment, to exchange maximum message size
> information (perhaps using some of those reserved bits), or even
> exchange “error” state. E.g. I’d like to be able to send to my peer
> that its request to send a message of 10GB is denied because the
> message is too big, or at least during connection establishment be
> able to state things like “Sorry your protocol isn’t supported” or
> “Sorry, I haven’t resources available right now, come back later.”
>
> These things could be useful in providing better error reporting
> back to the user (perhaps via logs or real-time error messages) of
> an agent trying to perform the connection.
>
> -- Garrett D'Amore Sent with Airmail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTHhfLAAoJENTpVjxCNN9Y1tAH/1rlXPcxknxS0mBnr9TiUQjJ
PMNHaT3a3sxo2Lb+Q92DuTrUGiaZy6mg6r1YuVzvYQNeq/ZSSkb9JaTakmlgQhBW
bdxb+I8wIcE29KzxUqmq5AtA1efWRWbMbkXLJw0FY25d3aI5JLfSZz8GUvQgY0XD
tDqpaZ9p4ZZtXTukXw9Vk8MFFkCB/2ig0ZhINYicD+dkwdeOLgISedkD2SYreLRt
11mOcZOLxPY0VcCy5bafZSRG76j8CVWXpM/CZIi3/+pkEzYm9R95ZM5Vh829QWhr
gm9xQOEbwPjiX4h2e1pxyeio9HVP3VDRY4O/OgyQYrO+kGo9CCVF9FelKhoswn8=
=coxc
-----END PGP SIGNATURE-----
Other related posts:
