[jboss-jira] [JBoss JIRA] (WFCORE-1067) CVE-2015-5304 Missing authorization check for Monitor/Deployer/Auditor role when shutting down server or canceling op

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1067:
-------------------------------------
             Security:     (was: Security Issue)
    Affects Version/s: 2.0.3.Final
                       2.0.2.Final
                       2.0.1.Final
                       2.0.0.Final
                           (was: 2.0.0.CR7)


>  CVE-2015-5304 Missing authorization check for Monitor/Deployer/Auditor role when shutting down server or canceling op
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1067
>                 URL: https://issues.jboss.org/browse/WFCORE-1067
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.Final, 1.0.1.Final, 2.0.0.Final, 2.0.1.Final, 2.0.2.Final, 2.0.3.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 2.0.4.Final
>
>
> It was found that the server or host controller did not properly authorize a user performing a shut down. A user with the role Monitor, Deployer, or Auditor could use this flaw to shut down the EAP server, which is an action restricted to users in other roles.
> The following commit introduced this issue:
> https://github.com/wildfly/wildfly-core/commit/6e5611b4c6
> The context.getServiceRegistry(true) call, which throws an exception when write authorization fails, was replaced with a call to context.authorize, which only returns an authorization result. Nothing was then done with the authorization result.
> The same flaw exists in the handling of the cancel-active-operation op, although there this only means the admin could cancel an in-progress operation, perhaps initiated by a different admin. It also lets the admin cancel his own operation, which is arguably a benefit. But losing that benefit is an acceptable price to having a consistent RBAC scheme. (Note: CLI users whose own operations are hanging can always cancel them by doing a soft kill of the CLI process. Users of custom clients that use ModelControllerClient can cancel their own ops by using the ModelControllerClient executeAsync API and cancelling the Future returned thereby.)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)