yahoo-eng-team team mailing list archive

[Jeremy Stanley <1888722@xxxxxxxxxxxxxxxxxx>]

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

** Description changed:

- This issue is being treated as a potential security risk under
- embargo. Please do not make any public mention of embargoed
- (private) security vulnerabilities before their coordinated
- publication by the OpenStack Vulnerability Management Team in the
- form of an official OpenStack Security Advisory. This includes
- discussion of the bug or associated fixes in public forums such as
- mailing lists, code review systems and bug trackers. Please also
- avoid private disclosure to other individuals not already approved
- for access to this information, and provide this same reminder to
- those who are made aware of the issue prior to publication. All
- discussion should remain confined to this private bug report, and
- any proposed fixes should be added to the bug as attachments. This
- embargo shall not extend past 2020-10-21 and will be made
- public by or on that date even if no fix is identified.
- 
  I have a long-standing bug in my internal bug tracker expressing concern
  that the following server names are valid:
  
  foo"]; --
  ../..
  
  I note that there are also a couple of existing bugs (1581977 and
  1655563) describing a bad interaction with the Neutron integration api
  for hosts with a '.' in the name.
  
  I propose a new config option:
  
  [api]
  permitted_servername_regex
  
  That would allow people using neutron integration to disallow dots in
  names, and I would rest easier knowing that I'd also ruled out slashes,
  ampersands and semicolons.

** Information type changed from Private Security to Public

** Changed in: ossa
       Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1888722

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

Status in OpenStack Compute (nova):
  New
Status in OpenStack Security Advisory:
  Invalid

Bug description:
  I have a long-standing bug in my internal bug tracker expressing
  concern that the following server names are valid:

  foo"]; --
  ../..

  I note that there are also a couple of existing bugs (1581977 and
  1655563) describing a bad interaction with the Neutron integration api
  for hosts with a '.' in the name.

  I propose a new config option:

  [api]
  permitted_servername_regex

  That would allow people using neutron integration to disallow dots in
  names, and I would rest easier knowing that I'd also ruled out
  slashes, ampersands and semicolons.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1888722/+subscriptions