-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/http/server.go:Serve creates unlimited goroutines #6012
Labels
Milestone
Comments
Comment 1 by disposaboy@dby.me: That's not a solution. It's just adding another problem. i.e. now it's easier to DOS your server |
If this is a problem for you, a solution is to write your own implementation of net.Listener that caps the number of connections it accepts at one time, and then pass it to the http server, so that the server never needs to talk to more than N connections at once. Of course, as comment #1 says, now you have a new problem. Status changed to WorkingAsIntended. |
One can just easily add a proxy in front, say haproxy, to limit the number of connections, that's not the point. The problem is that the default implementation is open to a resource exaustion attack (the C++ example in https://www.owasp.org/index.php/Resource_exhaustion loosely maps to this). While limiting the number of active connections can make it simpler to DOS by exausting available connections, not limiting the available connections could cause resource starvation at the OS level, which could have bigger consequences. I actually filed this bug because people are looking at the implementation and making assumptions that it is fine to do so in general 'because the Go http libraries do this as well': mozilla-services/heka#359 (comment) So at minimum it might make sense to put a bold warning around the documentation that there is a potential issue with exposing the default http server naked to the internet without writing a custom net.Listener implementation that caps the number of connections. |
I'm not the one who decides what is preferable or not. Being open to resource exaustion can grant you an entry in CVE (see some examples here http://cwe.mitre.org/data/definitions/400.html), while having limits to resource consumption was never to my knowledge a CVE-worthy issue. |
> You are trading one DoS attack for another. This CL seems to present a different perspective on such issues: [golang-dev] code review 12541052: runtime: impose stack size limit (issue #12541052) """ The goal is to stop only those programs that would keep going and run the machine out of memory, but before they do that. 1 GB seems implausibly large, and it can be adjusted. """ https://golang.org/cl/12541052/ |
The difference is that a runaway stack normally indicates a program error, so crashing the program is a reasonable response. In fact, if you really do have a runaway stack, the program will already crash. CL 12541052 just changes the point at which it will crash: changes it to a point where it is likely to tie up all your system resources. Creating more and more goroutines does not normally indicate a program error. It indicates that your server is carrying a heavier load. There is no clear point where the runtime should say "this program is in error and should crash." Adding more goroutines is unlikely to exhaust the program's resources. It's other things that will do that. And simply limiting the number of goroutines won't let your server handle a heavy load any better. Or so it seems to me. |
Sidnei's suggestion wasn't to limit the number of goroutines in general, but to offer an easy way to impose a limit on the number of http requests handled concurrently, which seems similar in essence to what you describe. It's also very easy to trigger stack growth externally (pretty much all marshallers are recursive). |
Here's a CL that adds a LimitListener to the go.net repository. The test demonstrates how to start an HTTP server that serves a bounded number of concurrent requests. https://golang.org/cl/12727043 |
This issue was updated by revision golang/net@beab8eb. R=golang-dev, dsymonds, rsc CC=golang-dev https://golang.org/cl/12727043 |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by sidnei.da.silva:
The text was updated successfully, but these errors were encountered: