CIDR's of the form 12.34.56.78/0 should be an error

[Stephen Crawley]

The problem is that some users do not understand how CIDRs work, and incorrectly use /0 when they are trying to specify a single IP or a subnet in an Access Rule. Unfortunately 12.34.56.78/0 means the same thing as 0.0.0.0/0.

The proposed fix is to insist that /0 only be used with 0.0.0.0/0 and the IPv6 equivalent ::/0 when entering or updating Access Rule CIDRs in via the dashboard.

I am labeling this as a security vulnerability since it leads to naive users creating instances with ports open to the world when they didn't intend to do that.

[Jeremy Stanley (fungi)]

Since this definitely will benefit from a broader discussion and there's no benefit to keeping the report private, I've switched it to public security for now.

I feel like this doesn't actually describe a vulnerability which would get fixes backported to old releases, but rather a security hardening opportunity for upcoming releases. Regardless, it's worth getting additional input from whichever folks are going to be designing the solution to this.

[Jeremy Stanley (fungi)]

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.

[Tristan Cacqueray (tristan-cacqueray)]

According to the VMT's taxonomy ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ) this seems like a class D.

[Akihiro Motoki (amotoki)]

Hi Stephen, is there any guideline on forms for CIDR?

I see several ways we can go:

(a) Only accept a network address (which means host parts of CIDR should be zero) (e.g. 10.56.133.0/24 is okay but 10.56.133.1/24 is bad.)
(b) Check 0.0.0.0 is specified only when a netmask is 0
(c) Keep the current behavior as-is (as users who maintain security group should have minimum knowledge on CIDR)

If we improved the implementation, I prefer to (a). (b) is not a generic approach. One minor concern on (a) is that an error message would be "A specified CIDR is not a network address" or some and a naive user you mentioned cannot understand what the error message means :p

In addition, if we change the validation of CIDR, which forms should be improved?
I would like to have more concrete list of such forms.

I think this is a wish-list (or low priority) security improvement.

[Stephen Crawley (s-crawley)]

On Thu, 2019-07-25 at 03:42 +0000, Akihiro Motoki wrote:
> Hi Stephen, is there any guideline on forms for CIDR?

I have looked, and I can't find one so far. The notion is defined in
https://tools.ietf.org/html/rfc4632 ... but there is no mention of this
issue there.

> I see several ways we can go:
>
> (a) Only accept a network address (which means host parts of CIDR
> should be zero) (e.g. 10.56.133.0/24 is okay but 10.56.133.1/24 is
> bad.)
> (b) Check 0.0.0.0 is specified only when a netmask is 0
> (c) Keep the current behavior as-is (as users who maintain security
> group should have minimum knowledge on CIDR)

Ideally c) should be true, but we (Nectar) delegate this responsibility
to end users who frequently do not have the required knowledge. It is
not a tractable problem. So this is not an realistic option.

> If we improved the implementation, I prefer to (a).

Agreed.

> (b) is not a generic
> approach. One minor concern on (a) is that an error message would be
> "Ahttps://tools.ietf.org/html/rfc4632
> specified CIDR is not a network address" or some and a naive user you
> mentioned cannot understand what the error message means :p
>
> In addition, if we change the validation of CIDR, which forms should
> be improved?
> I would like to have more concrete list of such forms.

I will get back to you on the above. It is unclear to me if this has
security implications for the other uses of CIDRs in Horizon (apart
from access rules.)

> I think this is a wish-list (or low priority) security improvement.

I will try to work up a change.

-- Steve

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/716806

[Jeremy Stanley (fungi)]

Per Tristan's suggestion, the VMT will treat this as a security hardening opportunity, no advisory needed.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Brian Haley (<email address hidden>) on branch: master
Review: https://review.opendev.org/716806
Reason: This was fixed in a different way, see bug for details

[Brian Haley (brian-haley)]

Looks like this was fixed by a change in neutron to use a "normalized" CIDR in the securityi group backends, https://bugs.launchpad.net/neutron/+bug/1869129 has more details.

So I think we can mark the neutron portion here fixed.