Xen devel - Mar 2007 - RE: [Xen-staging] [xen-unstable] hvm: Remove access to QEMU monitor inVNC server

> hvm: Remove access to QEMU monitor in VNC server
> 
> This fixes a RHEL5 errata and CVE-2007-0998.
> 
> The monitor is still accessible in debug builds of ioemu (debug=y).
> 
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This change is quite weird since it doesn''t disable monitor access when
using SDL.

Also, the additional virtual consoles can be used for giving access to
things without security implications, like serial ports.

I think a much better fix for the security issue would be to change the
default monitor output not to be a virtual console.

    christian
> ---
>  tools/ioemu/Makefile.target |    4 ++++
>  tools/ioemu/vnc.c           |   13 +++++++++++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff -r a9a39cc52e74 -r 3375391fb0c9 tools/ioemu/Makefile.target
> --- a/tools/ioemu/Makefile.target	Tue Mar 27 16:19:25 2007 +0100
> +++ b/tools/ioemu/Makefile.target	Tue Mar 27 16:23:52 2007 +0100
> @@ -193,6 +193,10 @@ LIBS+=-lsocket -lnsl -lresolv
>  LIBS+=-lsocket -lnsl -lresolv
>  endif
>  
> +ifeq ($(debug),y)
> +CFLAGS += -DQEMU_VNC_MONITOR_EXPORT
> +endif
> +
>  # profiling code
>  ifdef TARGET_GPROF
>  LDFLAGS+=-p
> diff -r a9a39cc52e74 -r 3375391fb0c9 tools/ioemu/vnc.c
> --- a/tools/ioemu/vnc.c	Tue Mar 27 16:19:25 2007 +0100
> +++ b/tools/ioemu/vnc.c	Tue Mar 27 16:23:52 2007 +0100
> @@ -113,8 +113,10 @@ struct VncState
>      int visible_w;
>      int visible_h;
>  
> +#ifdef QEMU_VNC_MONITOR_EXPORT
>      int ctl_keys;               /* Ctrl+Alt starts calibration */
>      int shift_keys;             /* Shift / CapsLock keys */
> +#endif
>      int numlock;
>  };
>  
> @@ -895,6 +897,7 @@ static void do_key_event(VncState *vs, i
>  	    kbd_put_keycode(keycode & 0x7f);
>  	else
>  	    kbd_put_keycode(keycode | 0x80);
> +#ifdef QEMU_VNC_MONITOR_EXPORT
>      } else if (down) {
>  	int qemu_keysym = 0;
>  
> @@ -922,8 +925,10 @@ static void do_key_event(VncState *vs, i
>  	}
>  	if (qemu_keysym != 0)
>  	    kbd_put_keysym(qemu_keysym);
> -    }
> -
> +#endif
> +    }
> +
> +#ifdef QEMU_VNC_MONITOR_EXPORT
>      if (down) {
>  	switch (sym) {
>  	case XK_Control_L:
> @@ -976,6 +981,10 @@ static void do_key_event(VncState *vs, i
>  	    break;
>  	}
>      }
> +#else
> +    if (!down && sym == XK_Num_Lock)
> +        vs->numlock = !vs->numlock;
> +#endif
>  }
>  
>  static void key_event(VncState *vs, int down, uint32_t sym)
> 
> _______________________________________________
> Xen-staging mailing list
> Xen-staging@lists.xensource.com
> http://lists.xensource.com/xen-staging
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Mar 27, 2007 at 02:06:42PM -0700, Christian Limpach
wrote:
> > hvm: Remove access to QEMU monitor in VNC server
> > 
> > This fixes a RHEL5 errata and CVE-2007-0998.
> > 
> > The monitor is still accessible in debug builds of ioemu (debug=y).
> > 
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> 
> This change is quite weird since it doesn''t disable monitor access
when
> using SDL.
Well SDL isn''t exposed to the network directly - to access the monitor
via the SDL console, you''d need to first access the X server desktop in
question. Unprivileged local users, or remote user can''t typically get 
access to X desktop of the person who started the VM, so its not neccessary
to disable it.
> Also, the additional virtual consoles can be used for giving access to
> things without security implications, like serial ports.
The console enables the users to map the virtual serial port onto a physical
device. Not a huge issue, but still basically a privilege escalation because
it lets users access hardware they''d not otherwise be able to.
> I think a much better fix for the security issue would be to change the
> default monitor output not to be a virtual console.
Yes, long term I expect that if we want to avoid Xen forking still further
from QEMU then we''ll need XenD itself to own the monitor channel,
because
the monitor is becoming the official way to reconfig stuff on the fly. So
if XenD redirected the monitor to a STDIN/SDOUT then it could safely have
complete control over it & not expose it to the user. This is the approach
we already take in libvirt for managing QEMU & KVM guests & it works
quite
well. I didn''t do that myself because its much more work & I was
prioritizing
the security fix. 

NB, this fix is slightly different from what we actually put in RHEL. The
RHEL version removed the code completely - this version allows it to be
toggled at build time because Keir wanted to keep access for developers
who are doing debugging of HVM guests.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christian Limpach wrote:
>> hvm: Remove access to QEMU monitor in VNC server
>>
>> This fixes a RHEL5 errata and CVE-2007-0998.
>>
>> The monitor is still accessible in debug builds of ioemu (debug=y).
>>
>> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> 
> This change is quite weird since it doesn''t disable monitor access
when
> using SDL.
> 
> Also, the additional virtual consoles can be used for giving access to
> things without security implications, like serial ports.
> 
> I think a much better fix for the security issue would be to change the
> default monitor output not to be a virtual console.
QEMU 0.9.0 supports redirecting the monitor to a unix socket and 
supports reconnecting to the monitor (so that the banner is shown each 
time).

When using these options, you can actually execute monitor commands from 
the command line by doing something like:

echo help | socat stdin unix:/path/to/socket

With these patches (or by moving qemu-dm up to 0.9.0), someone could add 
an xm monitor command that let you execute commands via xm.

That, IMHO, would be the best possible solution.

Regards,

Anthony Liguori
>     christian
> 
>> ---
>>  tools/ioemu/Makefile.target |    4 ++++
>>  tools/ioemu/vnc.c           |   13 +++++++++++--
>>  2 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff -r a9a39cc52e74 -r 3375391fb0c9 tools/ioemu/Makefile.target
>> --- a/tools/ioemu/Makefile.target	Tue Mar 27 16:19:25 2007 +0100
>> +++ b/tools/ioemu/Makefile.target	Tue Mar 27 16:23:52 2007 +0100
>> @@ -193,6 +193,10 @@ LIBS+=-lsocket -lnsl -lresolv
>>  LIBS+=-lsocket -lnsl -lresolv
>>  endif
>>  
>> +ifeq ($(debug),y)
>> +CFLAGS += -DQEMU_VNC_MONITOR_EXPORT
>> +endif
>> +
>>  # profiling code
>>  ifdef TARGET_GPROF
>>  LDFLAGS+=-p
>> diff -r a9a39cc52e74 -r 3375391fb0c9 tools/ioemu/vnc.c
>> --- a/tools/ioemu/vnc.c	Tue Mar 27 16:19:25 2007 +0100
>> +++ b/tools/ioemu/vnc.c	Tue Mar 27 16:23:52 2007 +0100
>> @@ -113,8 +113,10 @@ struct VncState
>>      int visible_w;
>>      int visible_h;
>>  
>> +#ifdef QEMU_VNC_MONITOR_EXPORT
>>      int ctl_keys;               /* Ctrl+Alt starts calibration */
>>      int shift_keys;             /* Shift / CapsLock keys */
>> +#endif
>>      int numlock;
>>  };
>>  
>> @@ -895,6 +897,7 @@ static void do_key_event(VncState *vs, i
>>  	    kbd_put_keycode(keycode & 0x7f);
>>  	else
>>  	    kbd_put_keycode(keycode | 0x80);
>> +#ifdef QEMU_VNC_MONITOR_EXPORT
>>      } else if (down) {
>>  	int qemu_keysym = 0;
>>  
>> @@ -922,8 +925,10 @@ static void do_key_event(VncState *vs, i
>>  	}
>>  	if (qemu_keysym != 0)
>>  	    kbd_put_keysym(qemu_keysym);
>> -    }
>> -
>> +#endif
>> +    }
>> +
>> +#ifdef QEMU_VNC_MONITOR_EXPORT
>>      if (down) {
>>  	switch (sym) {
>>  	case XK_Control_L:
>> @@ -976,6 +981,10 @@ static void do_key_event(VncState *vs, i
>>  	    break;
>>  	}
>>      }
>> +#else
>> +    if (!down && sym == XK_Num_Lock)
>> +        vs->numlock = !vs->numlock;
>> +#endif
>>  }
>>  
>>  static void key_event(VncState *vs, int down, uint32_t sym)
>>
>> _______________________________________________
>> Xen-staging mailing list
>> Xen-staging@lists.xensource.com
>> http://lists.xensource.com/xen-staging
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> From: Daniel P. Berrange [mailto:berrange@redhat.com] 
> 
> Well SDL isn''t exposed to the network directly - to access the
monitor
> via the SDL console, you''d need to first access the X server 
> desktop in
> question. Unprivileged local users, or remote user can''t 
> typically get 
> access to X desktop of the person who started the VM, so its 
> not neccessary
> to disable it.
What about the unprivileged local user using the X desktop?
> The console enables the users to map the virtual serial port 
> onto a physical
> device. Not a huge issue, but still basically a privilege 
> escalation because
> it lets users access hardware they''d not otherwise be able to.
?? You get access to the guests serial port through a virtual console in
VNC/SDL, how is that a privilege escalation?

Don''t you think that having the monitor (and the serial port) not
exposed by default through VNC/SDL is a sufficient and more flexibel fix
for the security issue? 

    Christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> QEMU 0.9.0 supports redirecting the monitor to a unix socket and 
> supports reconnecting to the monitor (so that the banner is 
> shown each 
> time).
> 
> When using these options, you can actually execute monitor 
> commands from 
> the command line by doing something like:
> 
> echo help | socat stdin unix:/path/to/socket
> 
> With these patches (or by moving qemu-dm up to 0.9.0), 
> someone could add 
> an xm monitor command that let you execute commands via xm.
> 
> That, IMHO, would be the best possible solution.
I''ve found that redirecting the monitor using "-monitor pty"
works quite
well since you get access to it using xm console.  That might have been
broken recently though by the changes to how pty information is written
to xenstore.

I think it would be better to extend xm console to support additional
pty''s instead of adding a single purpose xm monitor command.

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christian Limpach wrote:
>> QEMU 0.9.0 supports redirecting the monitor to a unix socket and 
>> supports reconnecting to the monitor (so that the banner is 
>> shown each 
>> time).
>>
>> When using these options, you can actually execute monitor 
>> commands from 
>> the command line by doing something like:
>>
>> echo help | socat stdin unix:/path/to/socket
>>
>> With these patches (or by moving qemu-dm up to 0.9.0), 
>> someone could add 
>> an xm monitor command that let you execute commands via xm.
>>
>> That, IMHO, would be the best possible solution.
>>     
>
> I''ve found that redirecting the monitor using "-monitor
pty" works quite
> well since you get access to it using xm console.  That might have been
> broken recently though by the changes to how pty information is written
> to xenstore.
>   
Except if you disconnect from the pty, QEMU is prone to ending up in an 
infinite loop of read() == 0.
> I think it would be better to extend xm console to support additional
> pty''s instead of adding a single purpose xm monitor command.
>   
xm console could also be extended to work with domain sockets which do 
not suffer from this problem.

Regards,

Anthony Liguori
>     christian
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Mar 27, 2007 at 02:32:00PM -0700, Christian Limpach
wrote:
> > From: Daniel P. Berrange [mailto:berrange@redhat.com] 
> > 
> > Well SDL isn''t exposed to the network directly - to access
the monitor
> > via the SDL console, you''d need to first access the X server 
> > desktop in
> > question. Unprivileged local users, or remote user can''t 
> > typically get 
> > access to X desktop of the person who started the VM, so its 
> > not neccessary
> > to disable it.
> 
> What about the unprivileged local user using the X desktop?
The $DISPLAY that a guest connects to has to be specified by the person
creating the guest in the first place. So the Dom0 admin would be making
a concious decision to give that local user access to the guest display
via their desktop - in this scenario the local user & admin are almost
certainly one & the same person, so its not really a huge issue. Although
I guess there could be times when you wished to delegate the SDL display
access without the monitor. So really Anthony''s suggestion is a good
long
term approach to deal with the issue of monitor access.
> > The console enables the users to map the virtual serial port 
> > onto a physical
> > device. Not a huge issue, but still basically a privilege 
> > escalation because
> > it lets users access hardware they''d not otherwise be able
to.
> 
> ?? You get access to the guests serial port through a virtual console in
> VNC/SDL, how is that a privilege escalation?
I didn''t mean privilege escalation - I meant they have unauthorized
access
to privileged hardware - local users do not typically have permissions to 
access the devices /dev/ttyS* unless they''re root. The monitor allows
them
this access without being root.
> Don''t you think that having the monitor (and the serial port) not
> exposed by default through VNC/SDL is a sufficient and more flexibel fix
> for the security issue? 
Yes I do - as I said, XenD should take complete control of the monitor 
itself rather than allowing user access via the console. My patch was
merely the quickest fix to address the issue. Anthony''s suggestion is
a good one to follow as a permanent solution, because it allows the 
privileged Dom0 admin to still pass commands through to the monitor.
Still needs someone to take the time to write such an approach though...

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> From: Daniel P. Berrange [mailto:berrange@redhat.com] 
>
> The $DISPLAY that a guest connects to has to be specified by 
> the person
> creating the guest in the first place. So the Dom0 admin 
> would be making
> a concious decision to give that local user access to the 
> guest display
> via their desktop - in this scenario the local user & admin are almost
> certainly one & the same person, so its not really a huge 
> issue. Although
> I guess there could be times when you wished to delegate the 
> SDL display
> access without the monitor. So really Anthony''s suggestion is 
> a good long
> term approach to deal with the issue of monitor access.
I still think that giving the local user access to the guest display is
a bit different than giving the local user access to the monitor which
lets the local user gain root privileges on the host.

One could apply your logic to the VNC scenario just as well -- the admin
must have made the conscious decision to give the remote user access to
the guest display, so why shouldn''t the remote user get the same chance
of compromising the local host ;-)
> > ?? You get access to the guests serial port through a 
> virtual console in
> > VNC/SDL, how is that a privilege escalation?
> 
> I didn''t mean privilege escalation - I meant they have 
> unauthorized access 
> to privileged hardware - local users do not typically have 
> permissions to 
> access the devices /dev/ttyS* unless they''re root. The 
> monitor allows them 
> this access without being root.
Stop!  You seem to be confusing some things here.  I think we all agree
that giving access to the monitor is a security issue.  But there''s
nothing wrong with the default qemu serial config which exposes the
_guest''s_ first serial port on a virtual console.  This never gets
anywhere close to the host serial devices.
> > Don''t you think that having the monitor (and the serial port)
not
> > exposed by default through VNC/SDL is a sufficient and more 
> flexibel fix
> > for the security issue? 
> 
> Yes I do - as I said, XenD should take complete control of 
> the monitor 
> itself rather than allowing user access via the console. My patch was
> merely the quickest fix to address the issue. Anthony''s suggestion
is
> a good one to follow as a permanent solution, because it allows the 
> privileged Dom0 admin to still pass commands through to the monitor.
> Still needs someone to take the time to write such an 
> approach though...
Glad you agree, although it''s a bit in a weird way by going off on a
tangent ;-)

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Mar 27, 2007 at 03:40:35PM -0700, Christian Limpach
wrote:
> > From: Daniel P. Berrange [mailto:berrange@redhat.com] 
> >
> > The $DISPLAY that a guest connects to has to be specified by 
> > the person
> > creating the guest in the first place. So the Dom0 admin 
> > would be making
> > a concious decision to give that local user access to the 
> > guest display
> > via their desktop - in this scenario the local user & admin are
almost
> > certainly one & the same person, so its not really a huge 
> > issue. Although
> > I guess there could be times when you wished to delegate the 
> > SDL display
> > access without the monitor. So really Anthony''s suggestion is
> > a good long
> > term approach to deal with the issue of monitor access.
> 
> I still think that giving the local user access to the guest display is
> a bit different than giving the local user access to the monitor which
> lets the local user gain root privileges on the host.
> 
> One could apply your logic to the VNC scenario just as well -- the admin
> must have made the conscious decision to give the remote user access to
> the guest display, so why shouldn''t the remote user get the same
chance
> of compromising the local host ;-)
> 
> > > ?? You get access to the guests serial port through a 
> > virtual console in
> > > VNC/SDL, how is that a privilege escalation?
> > 
> > I didn''t mean privilege escalation - I meant they have 
> > unauthorized access 
> > to privileged hardware - local users do not typically have 
> > permissions to 
> > access the devices /dev/ttyS* unless they''re root. The 
> > monitor allows them 
> > this access without being root.
> 
> Stop!  You seem to be confusing some things here.  I think we all agree
> that giving access to the monitor is a security issue.  But
there''s
> nothing wrong with the default qemu serial config which exposes the
> _guest''s_ first serial port on a virtual console.  This never gets
> anywhere close to the host serial devices.
Ahhhh, I see what you mean - you''re referring to the ability to map the
backend of the guest virtual serial port into a VC of the guest!

I was talking about the ability to remap the backend of a guest serial
port at runtime, eg ability to do ''change serial /dev/ttyS0''
in the monitor

So we''re talking about completely different things :-)

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel