Skip to content
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

nrepl listens to remote connections from all interfaces by default #56

Closed
erno opened this issue Oct 17, 2018 · 6 comments
Closed

nrepl listens to remote connections from all interfaces by default #56

erno opened this issue Oct 17, 2018 · 6 comments
Labels
Good First Issue Simple tasks that would be a good choice for newcomers Help Wanted Security

Comments

@erno
Copy link

erno commented Oct 17, 2018

At clojure-emacs/cider#2482 it was said that nrepl by default binds to "::", the IPv6 equivalent of 0.0.0.0, which is a security problem absent authentication since anyone from the internet can connect and execute code. Indeed the current code at https://github.com/nrepl/nREPL/blob/2dda589d5d8b1f8e299d532a303371cc3654d5ce/src/clojure/nrepl/server.clj#L108 seems to work this way.

@bbatsov
Copy link
Contributor

bbatsov commented Oct 17, 2018

The open question from the CIDER issue remains - what should be the default? Seems if we bind to localhost we can't have both ipv4 and ipv6 clients connect to the server and this causes issues for some users. I'm open to suggestions.

@bbatsov bbatsov added Security Help Wanted Good First Issue Simple tasks that would be a good choice for newcomers labels Oct 17, 2018
@erno
Copy link
Author

erno commented Oct 18, 2018

I think this is a fundamental limitation of the socket api. You need to have the code changed to handle multiple concurrent listening sockets if you want to listen to both IPv4 localhost and IPv6 localhost. Just sticking to IPv4 localhost is fine until then. You can spell it as 127.0.0.1 if the concern is that someone may have "::1" as the "localhost" entry in their /etc/hosts.

@bbatsov
Copy link
Contributor

bbatsov commented Oct 18, 2018

@SevereOverfl0w @arrdem Any thoughts on this?

@bbatsov
Copy link
Contributor

bbatsov commented Oct 18, 2018

@erno
Copy link
Author

erno commented Oct 19, 2018

Yes, like the Java docs note (mirroring the C socket API), the "::" address is a special case in that it can accept both v4 and v6 connections. For historical context: this was an early compatibility hack in the IPv6 socket API design so that typical socket server apps could support dual-stack operation (as simultaenous v6 + v4 compatbility was called) with minium changes, continuin with a single listening socket.

@bbatsov
Copy link
Contributor

bbatsov commented Oct 20, 2018

Got it. Well, it makes sense to me to change this back to localhost (or 127.0.0.1) and just improve the docs.

Ideally we can switch our server model to feature two sockets if someone is willing to work on this. //cc @hanshuebner

bbatsov added a commit that referenced this issue Oct 30, 2018
This avoid a dependency on the order of the localhost records in
/etc/hosts. Normally first there's a record for 127.0.0.1 (ipv4
loopback address) and then there's a record for ::1 (ipv6 loopback
address), so normally you'd end up using the ipv4 address, but that's
not guaranteed.

I'd rather us have a stable and explicit default.
bbatsov added a commit that referenced this issue Nov 2, 2018
This avoid a dependency on the order of the localhost records in
/etc/hosts. Normally first there's a record for 127.0.0.1 (ipv4
loopback address) and then there's a record for ::1 (ipv6 loopback
address), so normally you'd end up using the ipv4 address, but that's
not guaranteed.

I'd rather us have a stable and explicit default.
bbatsov added a commit that referenced this issue Nov 2, 2018
This avoid a dependency on the order of the localhost records in
/etc/hosts. Normally first there's a record for 127.0.0.1 (ipv4
loopback address) and then there's a record for ::1 (ipv6 loopback
address), so normally you'd end up using the ipv4 address, but that's
not guaranteed.

I'd rather us have a stable and explicit default.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Good First Issue Simple tasks that would be a good choice for newcomers Help Wanted Security
Projects
None yet
Development

No branches or pull requests

2 participants