Lots of tests listen on 0.0.0.0 #381
Labels
bug
Something isn't working
Comments
|
Would listening on |
|
Yes - here's an example CL submitting a patch: grafana/loki#10411 Some machines map "localhost" to a different IP than 127.0.0.1 but it's sufficient for most machines to dial this host. |
|
Basically - I'm happy to fix these just wanted some guidance that this is something you'd be interested in reviewing and merging. |
|
Yep, please do open a PR 👍 |
kevinburkesegment
added a commit
to kevinburkesegment/dskit
that referenced
this issue
Oct 9, 2023
Previously, if you passed "localhost" as the bind address for a TCPTransport, we would attempt to parse this as an IP address, fail, and then begin listening on 0.0.0.0. This is a security issue since 0.0.0.0 binds to all interfaces, including public ones, while "localhost" is a shortcut for an IP address that is typically is only accessible from the local machine, not the wider Internet. Fix this by returning an error if you attempt to pass a BindAddr to TCPTransport that is not actually an IP address. Also, fix the tests to resolve "localhost" to an IP address before proceeding - typically, but not always, this is 127.0.0.1, which is why we try to parse the loopback address instead of hardcoding it. I can confirm that on a Mac, with this patch applied I no longer get dialog boxes warning me that the tests are attempting to listen on 0.0.0.0. Updates grafana#381.
kevinburkesegment
added a commit
to kevinburkesegment/dskit
that referenced
this issue
Oct 9, 2023
Previously, if you passed "localhost" as the bind address for a TCPTransport, we would attempt to parse this as an IP address, fail, and then begin listening on 0.0.0.0. This is a security issue since 0.0.0.0 binds to all interfaces, including public ones, while "localhost" is a shortcut for an IP address that is typically is only accessible from the local machine, not the wider Internet. Fix this by returning an error if you attempt to pass a BindAddr to TCPTransport that is not actually an IP address. Also, fix the tests to resolve "localhost" to an IP address before proceeding - typically, but not always, this is 127.0.0.1, which is why we try to parse the loopback address instead of hardcoding it. I can confirm that on a Mac, with this patch applied I no longer get dialog boxes warning me that the tests are attempting to listen on 0.0.0.0. Updates grafana#381.
kevinburkesegment
added a commit
to kevinburkesegment/dskit
that referenced
this issue
Oct 9, 2023
Previously, if you passed "localhost" as the bind address for a TCPTransport, we would attempt to parse this as an IP address, fail, and then begin listening on 0.0.0.0. This is a security issue since 0.0.0.0 binds to all interfaces, including public ones, while "localhost" is a shortcut for an IP address that is typically is only accessible from the local machine, not the wider Internet. Fix this by returning an error if you attempt to pass a BindAddr to TCPTransport that is not actually an IP address. Also, fix the tests to resolve "localhost" to an IP address before proceeding - typically, but not always, this is 127.0.0.1, which is why we try to parse the loopback address instead of hardcoding it. I can confirm that on a Mac, with this patch applied I no longer get dialog boxes warning me that the tests are attempting to listen on 0.0.0.0. Updates grafana#381.
kevinburkesegment
added a commit
to kevinburkesegment/dskit
that referenced
this issue
Oct 10, 2023
Previously, if you passed "localhost" as the bind address for a TCPTransport, we would attempt to parse this as an IP address, fail, and then begin listening on 0.0.0.0. This is a security issue since 0.0.0.0 binds to all interfaces, including public ones, while "localhost" is a shortcut for an IP address that is typically is only accessible from the local machine, not the wider Internet. Fix this by returning an error if you attempt to pass a BindAddr to TCPTransport that is not actually an IP address. Also, fix the tests to resolve "localhost" to an IP address before proceeding - typically, but not always, this is 127.0.0.1, which is why we try to parse the loopback address instead of hardcoding it. I can confirm that on a Mac, with this patch applied I no longer get dialog boxes warning me that the tests are attempting to listen on 0.0.0.0. Updates grafana#381.
kevinburkesegment
added a commit
to kevinburkesegment/dskit
that referenced
this issue
Oct 10, 2023
Previously, if you passed "localhost" as the bind address for a TCPTransport, we would attempt to parse this as an IP address, fail, and then begin listening on 0.0.0.0. This is a security issue since 0.0.0.0 binds to all interfaces, including public ones, while "localhost" is a shortcut for an IP address that is typically is only accessible from the local machine, not the wider Internet. Fix this by returning an error if you attempt to pass a BindAddr to TCPTransport that is not actually an IP address. Also, fix the tests to resolve "localhost" to an IP address before proceeding - typically, but not always, this is 127.0.0.1, which is why we try to parse the loopback address instead of hardcoding it. I can confirm that on a Mac, with this patch applied I no longer get dialog boxes warning me that the tests are attempting to listen on 0.0.0.0. Updates grafana#381.
charleskorn
added a commit
that referenced
this issue
Oct 12, 2023
* kv/memberlist: fix incorrect TCP transport host parsing Previously, if you passed "localhost" as the bind address for a TCPTransport, we would attempt to parse this as an IP address, fail, and then begin listening on 0.0.0.0. This is a security issue since 0.0.0.0 binds to all interfaces, including public ones, while "localhost" is a shortcut for an IP address that is typically is only accessible from the local machine, not the wider Internet. Fix this by returning an error if you attempt to pass a BindAddr to TCPTransport that is not actually an IP address. Also, fix the tests to resolve "localhost" to an IP address before proceeding - typically, but not always, this is 127.0.0.1, which is why we try to parse the loopback address instead of hardcoding it. I can confirm that on a Mac, with this patch applied I no longer get dialog boxes warning me that the tests are attempting to listen on 0.0.0.0. Updates #381. * kv/memberlist: add test for IP address rejection * Update CHANGELOG.md Co-authored-by: Charles Korn <charleskorn@users.noreply.github.com> * fix more tests * rework sync.Once usage * use require instead of manual tests * require.EqualError * require.Error no longer necessary --------- Co-authored-by: Charles Korn <charleskorn@users.noreply.github.com>
ying-jeanne
pushed a commit
that referenced
this issue
Nov 2, 2023
* kv/memberlist: fix incorrect TCP transport host parsing Previously, if you passed "localhost" as the bind address for a TCPTransport, we would attempt to parse this as an IP address, fail, and then begin listening on 0.0.0.0. This is a security issue since 0.0.0.0 binds to all interfaces, including public ones, while "localhost" is a shortcut for an IP address that is typically is only accessible from the local machine, not the wider Internet. Fix this by returning an error if you attempt to pass a BindAddr to TCPTransport that is not actually an IP address. Also, fix the tests to resolve "localhost" to an IP address before proceeding - typically, but not always, this is 127.0.0.1, which is why we try to parse the loopback address instead of hardcoding it. I can confirm that on a Mac, with this patch applied I no longer get dialog boxes warning me that the tests are attempting to listen on 0.0.0.0. Updates #381. * kv/memberlist: add test for IP address rejection * Update CHANGELOG.md Co-authored-by: Charles Korn <charleskorn@users.noreply.github.com> * fix more tests * rework sync.Once usage * use require instead of manual tests * require.EqualError * require.Error no longer necessary --------- Co-authored-by: Charles Korn <charleskorn@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Many of the tests in the test suite attempt to bind to a random port on 0.0.0.0, which means anything can make a connection to the server, including external devices.
On Mac, this is very annoying because each invocation triggers a dialog box asking to allow connections to the test binary. I counted about ten or so of these dialog boxes in one run of the test suite.
To track down this issue, edit
$GOROOT/src/net/dial.go, and add the following patch toListenConfig.Listen:// See func Listen for a description of the network and address // parameters. func (lc *ListenConfig) Listen(ctx context.Context, network, address string) (Listener, error) { + if address == ":0" { + fmt.Println("ListenConfig.Listen", network, address) + debug.PrintStack() + } addrs, err := DefaultResolver.resolveAddrList(ctx, "listen", network, address, nil)Then rerun the tests. This will likely show you which test file is responsible for opening a socket to 0.0.0.0.
The text was updated successfully, but these errors were encountered: