5 ms·
This is a non-issue for those of us who are using Vagrant or similar development VM technologies.
by teilo 10y ago
This is a non-issue for those of us who are using Vagrant or similar development VM technologies.
- michaelmior 10y agoNot 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.
- abricot 10y agoThe few guides I've seen on setting up virtual servers as devlopment environments have all recommended setting networks as bridged instead of NAT'ed.
- sbarre 10y agoThat 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.
- spdionis 10y agoUsually 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.
- cmdrfred 10y agoMost 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.
- jlgaddis 10y agoIndeed. 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.
- lugg 10y agoI 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.
- apendleton 10y agoTunneling 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.
- teilo 10y agoNo, 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.
- teilo 10y agoThese 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.
- Dylan16807 10y agoThese 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.
- lima 10y agoThanks 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.
- uniclaude 10y agoNot 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.
- NDizzle 10y agoAbsolutely 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)'
- teilo 10y agoYou 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).
- NDizzle 10y agoWhat I just described was a bridge that maps ports on the local machine to ports on the VM.