The Nova api permits any possible hostname, including for example "../.." or "; --" or "hostname.openstack.org"

Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential
solutions.

This doesn't seem like a directly exploitable vulnerability report, but rather a recommendation for a new security-related feature. Nevertheless, we'll keep it private until Nova folks can confirm that assumption.

As for instance names with "." in them, I personally make use of this and am not convinced it should normally be forbidden. In many settings it can be very convenient to give your server instances the same names as their FQDNs. In fact I have a number of instances in public clouds with something.openstack.org names just like your example, because I help run openstack.org's services and those are their actual canonical entries in DNS too, so it makes sense to keep them the same.

So this is what we do today, we use the sanitised instance.hostname:
https://github.com/openstack/nova/blob/da155cb495979726943806630eff1bed146b8605/nova/compute/api.py#L1817

You can see the sanitise logic here:
https://github.com/openstack/nova/blob/da155cb495979726943806630eff1bed146b8605/nova/utils.py#L351

I think we assume neutron does a double check here:
https://github.com/openstack/nova/blob/da155cb495979726943806630eff1bed146b8605/nova/network/neutron.py#L1624

It’s worth noting the api re-write added some validation here:
https://github.com/openstack/nova/blob/da155cb495979726943806630eff1bed146b8605/nova/api/openstack/compute/schemas/servers.py#L155
https://github.com/openstack/nova/blob/da155cb495979726943806630eff1bed146b8605/nova/api/validation/parameter_types.py#L268

Generally configuration options that alter API behaviour are rejected due to interoperability concerns. We already do some basic validation. This isn’t the simplest thing to do, but we are trying to be safe while keep backwards compatibility as the approach has evolved over the years.

It’s unclear to me what the likely problem is here, but hopefully the above will help others check my thinking on the topic.

To address @fungi's comment: I'm not specifically proposing that .'s be removed from hostnames by default, only that individual deployments be given the option to reject such hostnames if they are problematic in that specific deploy.

Regarding the exploitability of e.g. "../..": I'm confident that OpenStack itself sanitizes inputs in most places and is not very vulnerable to a 'Bobby Tables' issue. My concern is that in MY cloud, any given hostname is likely to processed by countless other scripts and programs, many of them written by volunteers or students. Allowing a malicious user to create a landmine hostname is asking for trouble.

Regarding 'interoperability concerns' -- that's may be good reason to avoid cloud-specific config options like this. In that case, perhaps this kind of input rejection should be added to Horizon rather than to Nova where it's unlikely to interfere with any multi-cloud automation.

Because this report only describes well-known behaviors of the software, I've switched it to public now. The OpenStack Vulnerability Management Team is not tracking this any longer since it does not seem to represent any vulnerability or hardening opportunity (hence the "invalid" advisory status), class E per our report taxonomy: https://security.openstack.org/vmt-process.html#incident-report-taxonomy

A John noted above config drive API behavior is no-no from interoperability perspective.

The name of a server is intentionally kept as free text.

If there is specific problems about how nova generates hostname from the server name (e.g. [1]) then please describe the specific problem and / or propose a patch tightening the hostname sanitizing code.

[1] https://github.com/openstack/nova/blob/da155cb495979726943806630eff1bed146b8605/nova/utils.py#L351

Marking this as INVALID. Please set it back to NEW if you disagree.