All nrepl tickets closed, now managed at https://github.com/nrepl/nrepl

Comment made by: rlb

I'm not sure what the library solution would look like, but fundamentally I think nrepl and the related ecosystem should be secure by default. If the JVM supported filesystem sockets, then a straightforward solution for platforms providing them would be a user-owned rw------- socket, but unfortunately that's not an option.

Regarding the current arrangement, I don't know of any precedent for providing passwordless shell access to user accounts as a default, and if if a tool like ssh or telnet were to do it, I'd be equally alarmed.

As it stands now, I think this command will probably destroy all the home directories of users running nrepl via lein or cider, on a machine where you can access localhost:

And if that's not sufficiently unnerving, all that's required to make it remotely exploitable is an appropriate bug in some other program running on the system, like a mail server, irc server, or perhaps a browser: http://seclists.org/oss-sec/2016/q4/100

In that case, Guile was affected by a similar issue, and while I think that particular exploit might not be able to target nrepl right now (as it can only send an http request, and the headers will probably choke nrepl before it reaches the dangerous body), it's not reasonable to assume that there will never be some other bug[1] in the browser or elsewhere that allows sending arbitrary bytes to a localhost port.

Coupled with the tendency for people to use sudo with a non-zero timeout, it might also provide a full system compromise to a patient, determined attacker.

Oh, and for what it's worth, I'm not at all attached to the particular solution suggested, but I do think this is a problem that should be solved.

[1] Or feature - I suspect people wouldn't normally assume that providing the ability to send bytes to a port on localhost might carry such a risk.

When I was first creating nREPL, I heard many serious suggestions to have built-in security apparatuses (including authentication and evaluation soapboxes, among other things). All of them aimed to use the middleware mechanism (as it looks like you do here), which of course is a very open mechanism for extending nREPL servers in use in leiningen and other contexts.

The essential question is: why shouldn't these patches form the basis for a separate nREPL library? In that context, you'll be able to experiment and accommodate feedback much faster than if the same initial bits were landed here.