I'm basing the following comments on just having gone through the code paths before this comparison takes place so confirmation from someone more familiar with this flow would be nice.
But from what I'm seeing there is no user input that makes it into the token generation, depending on how networking access is structured for the nova metadata service. This token comparison is based on CONF.service_neutron_metadata_proxy being set which means the deployer is expecting the Neutron namespace proxy to be setup. The namespace proxy does a lookup based on the ip address of the instance making a query to it, and populates the X-Instance-ID header based on that result and then forwards to the Nova metadata service. I would hope that the metadata service would not be directly accessible from instances.
If the metadata service is accessible from instances and CONF.service_neutron_metadata_proxy is set to True then this would be theoretically vulnerable to a timing attack. The result of which would be gaining access to information about another instance. It should be noted that this bug includes Neutron as well since it performs the signing so any change would have to be coordinated across both services.
I'm basing the following comments on just having gone through the code paths before this comparison takes place so confirmation from someone more familiar with this flow would be nice.
But from what I'm seeing there is no user input that makes it into the token generation, depending on how networking access is structured for the nova metadata service. This token comparison is based on CONF.service_ neutron_ metadata_ proxy being set which means the deployer is expecting the Neutron namespace proxy to be setup. The namespace proxy does a lookup based on the ip address of the instance making a query to it, and populates the X-Instance-ID header based on that result and then forwards to the Nova metadata service. I would hope that the metadata service would not be directly accessible from instances.
If the metadata service is accessible from instances and CONF.service_ neutron_ metadata_ proxy is set to True then this would be theoretically vulnerable to a timing attack. The result of which would be gaining access to information about another instance. It should be noted that this bug includes Neutron as well since it performs the signing so any change would have to be coordinated across both services.