[OSSA 2014-031] policy admin_only rules not enforced when changing value to default (CVE-2014-6414)

Setting as private security as soon as Eugene made me aware of the bug.
This might allow users to reset arbitrary attributes to default values - which could be a security threat.

It has been in the open for about 50 minutes. I don't know if the security private flag still makes sense. But I don't know if there's a policy around that.

@Salvatore Well the policy is Once public, Forever public... Thus I'll mark this bug as Public security.

This bug is concerning, do we know how many release are impacted ?

What attributes are we talking about ? Is there an API to change configuration within Neutron ?

wip patch: https://review.openstack.org/#/c/114531/

This is a behaviour which has always been in the system.
I am looking at the patch to understand the exact scope.

I have verified that users still won't be allowed to un-share networks or make ext networks internals, which would cause immediate disruption in a cloud - this won't happen because the user will not own the object in the first place.

For instance this can allow users to restore SNAT on routers where the provider has disabled it (not a big deal - networking should just stop working in that case)
Another example is that a user can un-distribute a distributed router - again no big deal but this would however make the router not functional.

Even if it's not the end of the world, it's good to keep this bug as public security as deployers might be running customized policy.json files, and therefore might experience unexpected and possibly security-threatening behaviours.

Fix https://review.openstack.org/#/c/114531/ is ready for review.

Draft impact description:

Title: Administrator only network attributes may be reset to defaults by non-privileged users
Reporter: Elena Ezhova (Mirantis)
Products: Neutron
Versions: up to 2014.2

Description:
Elena Ezhova from Mirantis reported a vulnerability in Neutron. By updating a network attribute with a default value a non-privileged user may reset admin-only network attributes. This may lead to unexpected behavior with security implications for operators with a custom policy.json, or in some cases network outages resulting in denial of service. All deployments using neutron networking are affected by this flaw.

Title: Administrator only -> "Admin-only"
Desc: "some cases" -> "some extreme cases" (as we don't even know of such a case iiuc)
Versions: I think both havana and icehouse are affected, so this should mention 2014.1 up to... and 2013.2.x up to...

Otherwise looks good

Title: Admin-only network attributes may be reset to defaults by non-privileged users
Reporter: Elena Ezhova (Mirantis)
Products: Neutron
Versions: up to 2013.2.4 and 2014.1 versions up to 2014.1.2

Description:
Elena Ezhova from Mirantis reported a vulnerability in Neutron. By updating a network attribute with a default value a non-privileged user may reset admin-only network attributes. This may lead to unexpected behavior with security implications for operators with a custom policy.json, or in some extreme cases network outages resulting in denial of service. All deployments using neutron networking are affected by this flaw.

Mitre has assigned CVE-2014-6414 for this issue. (Unable to link currently)

+1 Impact desc

Grant's impact description from comment #10 looks fine to me, though with Havana reaching EOL it way need the versions line adjusted to just be "up to 2014.1.2"

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/123849

Reviewed: https://review.openstack.org/114531
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=74d10939903984d5f06c1749a8707fa3257e44ff
Submitter: Jenkins
Branch: master

commit 74d10939903984d5f06c1749a8707fa3257e44ff
Author: Elena Ezhova <email address hidden>
Date: Tue Aug 19 15:54:36 2014 +0400

    Forbid regular users to reset admin-only attrs to default values

    A regular user can reset an admin-only attribute to its default
    value due to the fact that a corresponding policy rule is
    enforced only in the case when an attribute is present in the
    target AND has a non-default value.

    Added a new attribute "attributes_to_update" which contains a list
    of all to-be updated attributes to the body of the target that is
    passed to policy.enforce.

    Changed a check for whether an attribute is explicitly set.
    Now, in the case of update, the function should not pay attention
    to a default value of an attribute, but check whether it was
    explicitly marked as being updated.

    Added unit-tests.

    Closes-Bug: #1357379
    Related-Bug: #1338880
    Change-Id: I6537bb1da5ef0d6899bc71e4e949f2c760c103c2

Fix proposed to branch: stable/havana
Review: https://review.openstack.org/123952

As far as I understand https://wiki.openstack.org/wiki/StableBranch#Releases, Havana will reach EOL on October, 16. Does it mean that backporting the fix to stable/havana does not make sense?

Change abandoned by Elena Ezhova (<email address hidden>) on branch: stable/havana
Review: https://review.openstack.org/123952
Reason: Abandon change due to the stopped support of stable/havana.

Elena, that document actually says "OpenStack Havana stable release will reach EOL at Juno (N+2) milestone-3" which according to https://wiki.openstack.org/wiki/Juno_Release_Schedule (and subsequent reality) was several weeks ago. It was effectively extended to a week from this past Tuesday when the final 2013.2.4 stable point release was announced to account for any possible release-related accidents, but I'm planning to delete the branch as early as this coming Tuesday, September 30.

Reviewed: https://review.openstack.org/123849
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=dd4b77ff53479389a5af8b45fd95ee2987562f29
Submitter: Jenkins
Branch: stable/icehouse

commit dd4b77ff53479389a5af8b45fd95ee2987562f29
Author: Elena Ezhova <email address hidden>
Date: Tue Aug 19 15:54:36 2014 +0400

    Forbid regular users to reset admin-only attrs to default values

    A regular user can reset an admin-only attribute to its default
    value due to the fact that a corresponding policy rule is
    enforced only in the case when an attribute is present in the
    target AND has a non-default value.

    Added a new attribute "attributes_to_update" which contains a list
    of all to-be updated attributes to the body of the target that is
    passed to policy.enforce.

    Changed a check for whether an attribute is explicitly set.
    Now, in the case of update, the function should not pay attention
    to a default value of an attribute, but check whether it was
    explicitly marked as being updated.

    Added unit-tests.

    Conflicts:
     neutron/common/constants.py

    Closes-Bug: #1357379
    Related-Bug: #1338880
    Change-Id: I6537bb1da5ef0d6899bc71e4e949f2c760c103c2
    (cherry picked from commit 74d10939903984d5f06c1749a8707fa3257e44ff)

Jeremy, thank you for a clarification.

OSSA-2014-031 Announced today:

http://www.openwall.com/lists/oss-security/2014/09/29/12

Fix proposed to branch: feature/lbaasv2
Review: https://review.openstack.org/130864

Reviewed: https://review.openstack.org/130864
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c089154a94e5872efc95eab33d3d0c9de8619fe4
Submitter: Jenkins
Branch: feature/lbaasv2

commit 62588957fbeccfb4f80eaa72bef2b86b6f08dcf8
Author: Kevin Benton <email address hidden>
Date: Wed Oct 22 13:04:03 2014 -0700

    Big Switch: Switch to TLSv1 in server manager

    Switch to TLSv1 for the connections to the backend
    controllers. The default SSLv3 is no longer considered
    secure.

    TLSv1 was chosen over .1 or .2 because the .1 and .2 weren't
    added until python 2.7.9 so TLSv1 is the only compatible option
    for py26.

    Closes-Bug: #1384487
    Change-Id: I68bd72fc4d90a102003d9ce48c47a4a6a3dd6e03

commit 17204e8f02fdad046dabdb8b31397289d72c877b
Author: OpenStack Proposal Bot <email address hidden>
Date: Wed Oct 22 06:20:15 2014 +0000

    Imported Translations from Transifex

    For more information about this automatic import see:
    https://wiki.openstack.org/wiki/Translations/Infrastructure

    Change-Id: I58db0476c810aa901463b07c42182eef0adb5114

commit d712663b99520e6d26269b0ca193527603178742
Author: Carl Baldwin <email address hidden>
Date: Mon Oct 20 21:48:42 2014 +0000

    Move disabling of metadata and ipv6_ra to _destroy_router_namespace

    I noticed that disable_ipv6_ra is called from the wrong place and that
    in some cases it was called with a bogus router_id because the code
    made an incorrect assumption about the context. In other case, it was
    never called because _destroy_router_namespace was being called
    directly. This patch moves the disabling of metadata and ipv6_ra in
    to _destroy_router_namespace to ensure they get called correctly and
    avoid duplication.

    Change-Id: Ia76a5ff4200df072b60481f2ee49286b78ece6c4
    Closes-Bug: #1383495

commit f82a5117f6f484a649eadff4b0e6be9a5a4d18bb
Author: OpenStack Proposal Bot <email address hidden>
Date: Tue Oct 21 12:11:19 2014 +0000

    Updated from global requirements

    Change-Id: Idcbd730f5c781d21ea75e7bfb15959c8f517980f

commit be6bd82d43fbcb8d1512d8eb5b7a106332364c31
Author: Angus Lees <email address hidden>
Date: Mon Aug 25 12:14:29 2014 +1000

    Remove duplicate import of constants module

    .. and enable corresponding pylint check now the only offending instance
    is fixed.

    Change-Id: I35a12ace46c872446b8c87d0aacce45e94d71bae

commit 9902400039018d77aa3034147cfb24ca4b2353f6
Author: rajeev <email address hidden>
Date: Mon Oct 13 16:25:36 2014 -0400

    Fix race condition on processing DVR floating IPs

    Fip namespace and agent gateway port can be shared by multiple dvr routers.
    This change uses a set as the control variable for these shared resources
    and ensures that Test and Set operation on the control variable are
    performed atomically so that race conditions do not occur among
    multiple threads processing floating IPs.
    Limitation: The scope of this change is limited to addressing the race
    condition described in the bug report. It may not address other issues
    such as pre-existing issue wit...