XSA-468: multiple Windows PV driver vulnerabilities - update now!

dinhngtu

@conitrade-as @DustinB Thanks, reported the template issue to XO team.

conitrade-as

Here is another interesting fact: After installing the new tools (v.9.4.1) my static routes in Windows were all gone. Definitively a good way to loose connectivity to your domain controller. And that's why you have good monitoring and store things in Ansible et al. ...

DustinB

@conitrade-as said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

Here is another interesting fact: After installing the new tools (v.9.4.1) my static routes in Windows were all gone. Definitively a good way to loose connectivity to your domain controller. And that's why you have good monitoring and store things in Ansible et al. ...

Statically assign, but keep your DHCP server with reservations to address these types of issues

manilx

@DustinB Did run usr/bin/create-guest-templates but tepmlates are gone here also.

DustinB

@manilx said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

@DustinB Did run usr/bin/create-guest-templates but tepmlates are gone here also.

I did not, I'm in the middle of an AV/EDR migration and this way added to the list of things to touch while I was on the systems.

To me the templates are a minor inconvenience as we aren't constantly adding VMs.

conitrade-as

@DustinB Not IP assignments, I am talking about static routes. See e.g. https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netroute

DustinB

@conitrade-as said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

@DustinB Not IP assignments, I am talking about static routes. See e.g. https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netroute

Okay.... what...

pdonias

Hi! Regarding the templates issue, we're working on a fix on branch ~~pierre-fix-xsa468-test~~ master. Would anyone having the issue be available to test it?

conitrade-as

@pdonias Sure thing. I can test it in my test environment.

conitrade-as

Just did a couple more tests. Here are my findings:

Upgrading the tools from v9.3.3 to v9.4.1 does preserve the routing table.
Upgrading the tools from v9.2.1 to v9.4.1 does not preserve the routing table.

Here are a couple of powershell commands used for testing:

Get-NetRoute -PolicyStore PersistentStore
Get-NetAdapter
New-NetRoute -DestinationPrefix "10.10.0.0/24" -InterfaceIndex <ifIndex> -NextHop 10.10.0.254

dinhngtu

@conitrade-as This is a known issue when upgrading from XS WinPV 9.3.0 and below: https://support.citrix.com/s/article/CTX235403-updates-to-xenserver-vm-tools-for-windows-for-xenserver-and-citrix-hypervisor

conitrade-as

@dinhngtu Thanks for the pointer. Yes, it seems that the root cause also makes routes disappear. Howerver, that the routing information is gone is sadly not mentioned explicitly. May be something to add to your docs as well.

Caution when updating tools: Verify interface IP configuration and routing entries.

stormi

@Forza said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

Hi,

It is not clear to me if the old XCP-ng PV drivers (8.2.2.200-RC1) are affected or not. How should we proceed if they are?

Do others share this feeling and have this question after re-reading the whole announcement?

DustinB

@stormi said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

Do others share this feeling and have this question after re-reading the whole announcement?

No it's pretty clear, update the drivers on everything as all versions are susceptible.

flakpyro

@dinhngtu

One thing i've noticed since upgrading to tools version 9.4.1 is that the version installed will display properly in XOA up until the VM is migrated. After a migration it changed to just "Management agent detected" with no version shown. Not sure if this is an XO issue or an issue with the tools itself?

stormi

@flakpyro There's also a chance this is a XAPI issue. CC @andriy.sultanov

dinhngtu

@flakpyro What do you get from this command?

xe vm-param-get uuid=<uuid> param-name=PV-drivers-version

@stormi It sounds like the issue we encountered in CI with the management agent not restoring version numbers after migration.

flakpyro

@dinhngtu here is the output from one of the VMs recently migrated:

xe vm-param-get uuid=261634d9-b67c-1048-b028-2e33abea6329 param-name=PV-drivers-version
micro: -1; xennet: XenServer 9.1.7.65 ; xeniface: XenServer 9.1.12.94 ; xenvif: XenServer 9.1.13.107 ; xenvbd: XenServer 9.1.9.82 ; xenbus: XenServer 9.1.11.115

archw

@flakpyro
I've found a similar issue with all VMs I update. After I update and reboot, it stays at "Management agent detected" with no version shown.

Once I reboot a second time, it stays at "Management agent detected" with "Management agent 9.4.1-160 detected"

conitrade-as

@archw I can confirm. That is exactly the behaviour I see with my Windows VMs.