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

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.

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.

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

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.

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

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

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

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

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.