Bug 702754 (CVE-2011-1773)

+++ This bug was initially created as a clone of Bug #665347 +++

It also occurs with virt-v2v-0.6.3-4.el5.

+++ This bug was initially created as a clone of Bug #665345 +++

Created attachment 470410 [details]
log from LIBGUESTFS_TRACE=1

Description of problem:
Libvirt supports guests to have VNC encrypt when accessing guest via VNC. But after conversion, users won't be asked to enter VNC password. 

BTW: It works on migrating guest (#virsh migrate...) 

Version-Release number of selected component (if applicable):
virt-v2v-0.6.2-4.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1.  LIBGUESTFS_TRACE=1 virt-v2v -ic xen+ssh://<ip> -op <pool> rhel5u6-32b-pv-vnc-passwd --network default 2>&1 >passwd.log

2. Start and run the converted guest

  
Actual results:
VNC encrypt will miss

Expected results:
VNC encrypt still exists, so when accessing guest via VNC users will be asked to enter password

Additional info:
xml of source image
#virsh edit rhel5u6-32b-pv-vnc-passwd
<domain type='xen'>
  <name>rhel5u6-32b-pv-vnc-passwd</name>
  <uuid>25347599-cd18-987a-7a32-a8158e35c94f</uuid>
  <memory>524288</memory>
  <currentMemory>524288</currentMemory>
  <vcpu>1</vcpu>
  <bootloader>/usr/bin/pygrub</bootloader>
  <os>
    <type arch='x86_64' machine='xenpv'>linux</type>
  </os>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <disk type='file' device='disk'>
      <driver name='tap' type='aio'/>
      <source file='/var/lib/xen/images/rhel5u6-32b-pv-vnc-passwd.img'/>
      <target dev='xvda' bus='xen'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:16:36:3e:eb:1b'/>
      <source bridge='xenbr0'/>
      <script path='vif-bridge'/>
    </interface>
    <console type='pty'>
      <target port='0'/>
    </console>
    <input type='mouse' bus='xen'/>
    <graphics type='vnc' port='-1' autoport='yes' keymap='en-us' passwd='redhat'/>
  </devices>
</domain>

It is not possible to fix this without a change to the libvirt perl bindings. I've filed appropriate bugs (bug 705791 and bug 705792) against perl-Sys-Virt in RHEL 5 and RHEL 6. Time constraints make it highly unlikely this bug will be fixed for RHEL 5.7.

Some more information: This bug only affects conversions when a guest is being converted to run on a RHEL/libvirt target hypervisor. RHEV does not allow a VNC password to be specified, so this bug is not applicable there.

During conversion to RHEL/libvirt, virt-v2v currently entirely ignores the guest's existing display configuration, and replaces it with:

<graphics type='vnc' port='-1' listen='127.0.0.1'/>

That is, the converted guest will always use VNC on the localhost interface with an automatically allocated port number. The scope of the loss of the VNC password is therefore limited to:

1. Conversions where the target is libvirt/RHEL (not RHEV) and
2. The target hypervisor allows unprivileged logins for users who are not also administrators.

I think in practise this scope is extremely small and could be handled with a release note until the perl bindings can be updated.

This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:1615 https://rhn.redhat.com/errata/RHSA-2011-1615.html