[Qemu-devel] Possible security enhancement for QEMU

[Qemu-devel] Possible security enhancement for QEMU

[Attila-Mihaly Balazs]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

Dear all,

Some enterprising people scanned the whole range of IPv4 addresses for open
VNC servers [1] and my casual browsing seems to indicate that a lot of them
are QEMU VMs. I suspect that this is because just doing "-vnc :1" will
listen on/bind to "0.0.0.0" (ie. on all the interfaces).

My suggestion for improvement would be:
- change the behaviour of "-vnc :port" such that it listens on "127.0.0.1"
when the IP isn't specified
- if host is "0.0.0.0" (perhaps also include any routable IPv4 addresses -
and non-link-local IPv6 addresses) and no authentication method is
specified error out with a message like "It is recommended that you DO NOT
expose the VNC server directly to the public internet. If you are sure of
what you are doing, please specify an authentication method for the VNC
server. See the documentation for more details"

I'm happy to supply patches if people agree on the desired approach.

Happy Holidays!
Attila Balazs

[1] https://news.ycombinator.com/item?id=8810366

[-- Attachment #2: Type: text/html, Size: 1277 bytes --]

Re: [Qemu-devel] Possible security enhancement for QEMU

[Peter Maydell]

On 29 December 2014 at 19:09, Attila-Mihaly Balazs <dify.ltd@gmail.com> wrote:
> My suggestion for improvement would be:
> - change the behaviour of "-vnc :port" such that it listens on "127.0.0.1"
> when the IP isn't specified
> - if host is "0.0.0.0" (perhaps also include any routable IPv4 addresses -
> and non-link-local IPv6 addresses) and no authentication method is specified
> error out with a message like "It is recommended that you DO NOT expose the
> VNC server directly to the public internet. If you are sure of what you are
> doing, please specify an authentication method for the VNC server. See the
> documentation for more details"

Seems reasonable to me. Some questions:
 * do we need an option for "yes, I know what I'm doing and do not
   want any authentication" ?
 * how many of these VMs are configured for wide-open VNC by libvirt or
   similar management tool rather than by the user directly running QEMU?

thanks
-- PMM

Re: [Qemu-devel] Possible security enhancement for QEMU

[Daniel P. Berrange]

On Mon, Dec 29, 2014 at 09:26:45PM +0000, Peter Maydell wrote:
> On 29 December 2014 at 19:09, Attila-Mihaly Balazs <dify.ltd@gmail.com> wrote:
> > My suggestion for improvement would be:
> > - change the behaviour of "-vnc :port" such that it listens on "127.0.0.1"
> > when the IP isn't specified
> > - if host is "0.0.0.0" (perhaps also include any routable IPv4 addresses -
> > and non-link-local IPv6 addresses) and no authentication method is specified
> > error out with a message like "It is recommended that you DO NOT expose the
> > VNC server directly to the public internet. If you are sure of what you are
> > doing, please specify an authentication method for the VNC server. See the
> > documentation for more details"

Configuring 0.0.0.0 and no auth is a valid setup *provided* the virtualization
host itself is on a secured network. In fact this is the normal setup for an
OpenStack deployment, since the virt host/VNC server is not intended to ever
be directly exposed to the internet. Instead the user accesses the VNC server
via an authenticated VNC proxy tunnelled over HTTPs. So printing out such an
error message or refusing to launch would be wrong - QEMU doesn't know the
context of how it is being used.

> Seems reasonable to me. Some questions:
>  * do we need an option for "yes, I know what I'm doing and do not
>    want any authentication" ?
>  * how many of these VMs are configured for wide-open VNC by libvirt or
>    similar management tool rather than by the user directly running QEMU?

Libvirt will always set the listen address to 127.0.0.1 if not otherwise
specified, and so not rely on QEMU's (insecure) default.  So if any VMs
managed by libvirt are using a public IP address, this was requested
explicitly by the admin or the mgmt app using libvrt.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] Possible security enhancement for QEMU

[Peter Maydell]

On 5 January 2015 at 18:13, Daniel P. Berrange <berrange@redhat.com> wrote:
> Configuring 0.0.0.0 and no auth is a valid setup *provided* the virtualization
> host itself is on a secured network. In fact this is the normal setup for an
> OpenStack deployment, since the virt host/VNC server is not intended to ever
> be directly exposed to the internet. Instead the user accesses the VNC server
> via an authenticated VNC proxy tunnelled over HTTPs. So printing out such an
> error message or refusing to launch would be wrong - QEMU doesn't know the
> context of how it is being used.

Well, the question is what the default should be, and whether you should
have to take explicit action to enable a possibly-insecure configuration.
At the moment you don't, and this seems to have resulted in a lot of
people presumably unintentionally leaving themselves wide open to
access from the internet.

So it comes down to "are we willing to one-time break currently working
configs for people with openstack type deployments who will now need to
put no-auth-is-ok in their command line switches, in order to protect
new users against shooting themselves in the foot without realising it?".
You could argue it either way...

>> Seems reasonable to me. Some questions:
>>  * do we need an option for "yes, I know what I'm doing and do not
>>    want any authentication" ?
>>  * how many of these VMs are configured for wide-open VNC by libvirt or
>>    similar management tool rather than by the user directly running QEMU?
>
> Libvirt will always set the listen address to 127.0.0.1 if not otherwise
> specified, and so not rely on QEMU's (insecure) default.  So if any VMs
> managed by libvirt are using a public IP address, this was requested
> explicitly by the admin or the mgmt app using libvrt.

That's good to hear.

-- PMM