Hostname not allowed for inspect

[abryzak]

• Node.js Version: 8.12.0
• OS: CentOS 7
• Scope (install, code, runtime, meta, other?): Runtime
• Module (and version) (if relevant): inspector

I'm running multiple Node instances in a virtual machine and would like to have them available for debugging by the host at any time. To achieve this, I start each of them with --inspect=0.0.0.0: where port is different for each instance.

I've also set up a hosts file entry to point to the VM for easier access in a browser and to support a local dev CA I have, but I found when trying to debug using the host name it fails, whereas IP address works. I found this commit which added the check for hostname being an IP address or empty, but wasn't sure why it was added as the commit comment doesn't really indicate the reason.

nodejs/node@583d5af

Is there a way to allow hostname access?

[gireeshpunathil]

It was a security fix. I am not sure what level of details should be disclosed here, so pinging @bnoordhuis and @ofrobots for a one liner.

[yinzara]

I understand the security implications for allowing hostnames for debugging, however the restriction that only "localhost" I believe is too restrictive. If Node inspect also allowed any ".local" address, that would guarantee that there would never be an internet routable name that could be used but will still allow for debugging local virtual machines.

Is there the possibility that a PR implementing this would be accepted?

[gireeshpunathil]

@nodejs/v8-inspector

[yinzara]

Any update on this?

[eugeneo]

This was a part of the fix for https://nodejs.org/de/blog/vulnerability/march-2018-security-releases/#node-js-inspector-dns-rebinding-vulnerability-cve-2018-7160

The recommended approach for remote debugging scenarios is use of SSL tunnels - see https://nodejs.org/de/docs/guides/debugging-getting-started/#enabling-remote-debugging-scenarios

[yinzara]

I totally understand the DNS rebind issue. If they are comfortable allowing "localhost", would also allowing a ".local" address be just as cautious? Since ".local" addresses are not routable via public DNS servers would it still be vulnerable to the suggested attack?

What about providing a command line or configuration option to allow certain address suffixes or matching a regular expression? or to disable the hostname validation? This would at least allow us to enable this inside of our development environments.

I only suggest this because with the move to container based architectures, being able to debug a component inside a VM style cluster is increasingly prevalent and preventing this makes it more difficult to support Node as the preferred container language.

[eugeneo]

The goal is to explicitly discourage remote debugging in favor of SSH tunnels. E.g. I’ve seen people on Stack Overflow suggesting running Node with —inspect=0.0.0.0 on public-facing clouds.

[yinzara]

If someone ran Node with --inspect=0.0.0.0 on a public cloud, allowing a ".local" address to connect would not have any additional security implications that I can see. Remote debugging using SSH tunnels requires additional knowledge and setup and is not possible in many configurations. With Kubernetes, I would literally have to deploy an additional SSH component in the cluster every time I wanted to debug a component. This greatly complicates development environment setup. This is specifically a case where "security concerns" that are extremely rare make developing applications more difficult for everyday use. All I want to do is debug an application running in a cluster locally on my PC. Why would the community embrace requiring developers to have more knowledge and a more complex development setup to do this simple thing? This is a truly short sighted view. How would adding an option that allows this be a concern?

[eugeneo]

My concern specifically with the ".local" prefix is that it makes the logic bit more complex and every increase of logic seems to result in a new exploit these days :)

[yinzara]

I think preventing adding any features to Node or inspector because of a fear that complexity may add exploits is a dangerous attitude that will limit the growth of the tool :-) I've added a PR to relax this restriction as described above to allow for ".local" addresses. If anyone can come up with an exploit that makes this any more dangerous than permitting "localhost" addresses, I'll recant.

[eugeneo]

It is not entirely clear that remote debugging should be in the Node core at all - and there were some people suggesting disabling it at all. Local debugging with SSH tunnels or dedicated proxies (with at least some security) can bridge this gap.

I do not feel like I am qualified to review your PR, I don't understand how .local domain works and if this can be exploited in any way.

[yinzara]

I would say that's an even more terrible idea. Originally inspector was a separate project and it was merged to the core because it's required by nearly every developer trying to write software. Every modern language I can think of supports remote debugging in some way. I'm perplexed by the attitude that Node should not. Just because there is a method to debug remotely through SSH tunneling, doesn't mean that's an acceptable restriction in the language. It's very likely that adds enough hurdles to development that one may choose a different language all together that's simpler to work with. Container based development is now become the defacto standard for deployment. Adding restrictions that make Node more complex or difficult to develop for that type of environment because of fear of exploits that aren't even possible may cause a shift away from it.

Just because Node sees this as remote debugging, doesn't mean it's actually remote. That's the point of the .local addresses. As local is an officially reserved special-use domain name RFC 6762 of February 2013 host names with this top level label are not resolvable in the global Domain Name System.

[n8tz]

Any news on this ?
I have multiple dockers based projects, each one with multiple dockerized Node process & local hostnames like "stuff.localhost" ( for local dev );
If i'm not misunderstand, this mean we must ssh+forward &/| assign local ports to debug them all the time? No other way ? That's not suitable at all ! :/
We have more important things to do than messing with problems like "which ports go to which debugger process"...

[yinzara]

See
nodejs/node#31071

This is to allow a new "--inspect-allow-host" option that will let you specify the hostnames you can use to connect to the debug port. You can specify it more than once to allow multiple hostnames.

It's not complete but I'm looking forward to it.