x/net/websocket: allow configurable read size limit, and MaxHeaderBytes

[slimsag]

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.

[robpike]

Comment 2:

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

[rsc]

Comment 3:

Labels changed: added go1.3maybe.

[rsc]

Comment 4:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 5:

Labels changed: added repo-net.

[gdamore]

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.

[gdamore]

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.

[gdamore]

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.

[artyom]

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.

[ianlancetaylor]

Anybody want to send in a fix? If you are unsure about the approach, discuss on the golang-dev mailing list first.

[artyom]

@ianlancetaylor will open a mailing list thread then, ready to get my hands on this.

[gdamore]

Yay! Glad to see progress here!

On Mon, May 30, 2016 at 12:08 PM, Artyom Pervukhin <[email protected]

wrote:

@ianlancetaylor https://github.com/ianlancetaylor will open a mailing
list thread then, ready to get my hands on this.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5082 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABPDfc8ZPx0J5BpVVAeGq9hyAntN9idGks5qGzWjgaJpZM4GSWx9
.

[gopherbot]

CL https://golang.org/cl/23590 mentions this issue.