Congrats on the release, installed and testing! Exciting indeed.
As the subject says, I think the REST interface should require authentication and yes I read:
This feature is experimental and should not be used in production systems. In addition, there are several specific noteworthy deployment considerations:
- The vmrest service will run as the user who started it. ‘sudo vmrest’ would make the root user run the service, for example.
- The service does not provide authentication. Access to the network path where the API resides should be restricted if security is a concern at this time.
- HTTP requests are not encrypted.
Telling the user to firewall his machine sadly isn't sufficient.
Let me tell you what I did.
I created a new VM, played with it. Worked great, looks cool in the new GUI.
Then started the rest interface via ./vmrest and pointed a browser to my test host from another machine in the network.
Listing VMs? Works great too.
Hmm.. what's that? Deleting VMs?
First time I tried it told me the VM was locked, but on the second time it was a success.
So that means one can remotely delete VMs!
Let that sink in for a while.
You install a tool that enables the REST interface on your behalf. Most people won't know that it was started and not all tools written have security in mind.
Then a malicious actor scans your network, finds the standard port, points a browser to it and lists your VMs.
While that is scary already.
There's NO additional credentials required to delete a VM!
OK for a beta, but please PLEASE add some extra authentication requirement before final release.
| Vimalin : Automated backups for VMware Fusion and VMware Workstation Professional
| More info at https://www.vimalin.com
| Twitter @wilva
| VMware Wiki at http://www.vi-toolkit.com