x/net/websocket: allow configurable read size limit, and MaxHeaderBytes #5082
Comments
mikioh
changed the title
mikioh
changed the title
rsc
changed the title
|
This actually is a tragic failing. It means that Go websockets cannot be used safely in an unprotected network, since malefactor can simply request a giant message to DoS your service. |
|
Bump. This is a SECURITY FAILURE. Its a trivial remote DoS for websocket, meaning that you should not use native Golang websockets pretty much anywhere. |
|
In fact, this is probably the only reason that I have to use 3rd party Gorilla websocket instead of native golang one. Which angers me as the Gorilla folks have busted compatibility for Go versions < 1.5 recently. |
|
One option to limit incoming payload size can be introduction of optional "max.received message payload size" field to websocket.Codec struct, which, if non-zero, should be treated by Codec.Receive method as indication to wrap frame io.Reader into something similar to io.LimitedReader (that also has to report ErrUnexpectedEOF to recognize incomplete reads) right before the call to ioutil.ReadAll, which is a culprit here. |
|
Anybody want to send in a fix? If you are unsure about the approach, discuss on the golang-dev mailing list first. |
|
@ianlancetaylor will open a mailing list thread then, ready to get my hands on this. |
|
Yay! Glad to see progress here! On Mon, May 30, 2016 at 12:08 PM, Artyom Pervukhin <notifications@github.com
|
|
CL https://golang.org/cl/23590 mentions this issue. |
Codec's Receive method calls io.ReadAll of the whole frame payload, which can be abused by user sending large payloads in order to exhaust server memory. Introduce limit on received payload size defined by Conn.MaxPayloadBytes. If payload size of the message read with Codec.Receive exceeds limit, ErrFrameTooLarge error is returned; the connection can still be recovered if required: the next call to Receive would at first discard leftovers of previous oversized message before processing the next one. Fixes golang/go#5082. Change-Id: Ib04acd7038474fee39a1719324daaec1c0c496b1 Reviewed-on: https://go-review.googlesource.com/23590 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
What steps will reproduce the problem? Currently go.net/websocket provides no way to limit how much data an websocket server reads, if an client sends very large amounts of data (messages, frames) the websocket server will allocate that memory, and will continue to do so, until the server runs out of memory or the client crashes. [In someone else's tests] it has been observed that there is also no header limit provided (for the same issue). (See discussion: https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/2Tge6U8-QYI) What is the expected output? go.net/websocket should provide an way to set an maximum read size and maximum header read size, to avoid attacks from potentially malicious clients.The text was updated successfully, but these errors were encountered: