Hacker News Reader

Comment by teilo | Hacker News Reader

This is a non-issue for those of us who are using Vagrant or similar development VM technologies.

Not necessarily since it's not that uncommon to expose the ports from the VM. Not saying that's a good idea, but it happens fairly often.

These exploits rely upon the ports being exposed on localhost. Even if you are not (as you should) using ssh tunneling to the VM, any exposed ports are on a separate IP address, not localhost. However, if one is forwarding ports to the host machine, that's obviously a problem.

These exploits rely upon the ports being exposed on a predictable IP. A lot of setups are going to give you very predictable IPs for the virtual machines.

Thanks to WebRTC, it's even easier - you can enumerate all local IP addresses and then you only have to scan one or two subnets.

Local VMs are definitely vulnerable to this as well.

Not if you actually work in the VM, and do not expose database ports to the host (why in hell would you do this anyway). No amount of ip scanning is going to open ports.

> why in hell would you do this anyway

Integration with IDEs.

> Integration with IDEs.

That's a fair point, but Rsync or shared folders should have you covered for this.

Actually I meant something like how Intellij has DB integration, so you could put in your host & port and connect to the DB to help you write queries etc.

192.168.33.10

If the user isn't using ssh tunneling into the vagrant vm, then this attack still works if the attacker uses the correct IP address instead of localhost.

Usually I access databases in my VMs by ssh tunneling. I have no databse server software on my computer. I thought most people work like that.

Tunneling still binds a localhost port to your database, so it'd still be vulnerable to this attack even though it's running a container or VM.

No, it doesn't. If you are running Vagrant in a bridging config, it has it's own separate IP on the network. If you are running it as a private network, it has it's own IP on a private subnet isolated to the host machine. You have to explicitly do port forwarding to make it work as you describe.

EDIT: I'm not thinking straight. Please ignore me.

> You have to explicitly do port forwarding

> Tunneling

Yes, that is what GP was describing.

Sorry. You are correct, sir.

Most skilled developers probably. The rest can't figure out why the computer next to theirs can't connect to the test database and after googling a stackoverflow anwser have it listen on 0.0.0.0 forever.

Indeed. Turn off SELinux and disable the firewall too! And just leave the password for the MySQL root user blank since it's too much trouble keeping track of them.

I am guilty of this. The real question is will I ever change this habbit?

I see percentage of us here locking things down.

The rest, and the rest of the developers out there likely won't.

This needs to be fixed at the browser level I don't see it being solved any other way that would have the net benefit of having it fixed in the browser.

Simply pinning public and local and not allowing local rebinding should have most of the issues resolved.

The few guides I've seen on setting up virtual servers as devlopment environments have all recommended setting networks as bridged instead of NAT'ed.

That is the best approach, but a lot of people change it to NAT for testing purposes, like connecting to the VM from mobile devices, and other operating systems, etc..

I know there are ways to do that as well, but this is the easiest and so it's most often the way it's done.

Absolutely not a non-issue with all of the configuration options with vagrant. I'm honestly taken aback that you would consider this a nonissue with something like vagrant.

config.vm.network :forwarded_port, guest: 8080, host: 8080 config.vm.network "public_network", :bridge => 'en0: Wi-Fi (AirPort)'

You can intentionally configure anything to be insecure, and what you describe is one such example. Most devs are either bridging or using a private network (the latter in our case).

What I just described was a bridge that maps ports on the local machine to ports on the VM.

Reply on news.ycombinator.com