jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-8422) Deleted Users Not Removed From Group
Date Thu, 20 Jun 2019 16:26:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868679#comment-16868679
] 

angela commented on OAK-8422:
-----------------------------

[~jenslauterbach], just in case you decide to make use of the {{ClearMembershipAction}}: as
it should follow from the exercise it is strongly recommend to limit user management permission
to those subjects that have will read/usermgt access on all users/groups. otherwise the cleanup
might either be incomplete (the editing session can't see.a given membership) or will fail
the operation (editing session can't modify the membership). but in general {{User.disable}}
should be the way to go for a productive environment. hope that helps

> Deleted Users Not Removed From Group
> ------------------------------------
>
>                 Key: OAK-8422
>                 URL: https://issues.apache.org/jira/browse/OAK-8422
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>         Environment: Operating system: macOS 10.14.5
> Java: 
> {code:java}
> java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
> {code}
>            Reporter: Jens Lauterbach
>            Priority: Major
>
> h1. Overview
> When a user is created, added to a group, deleted and then re-created with the same userId
(authorizableId) the user is assigned to the group he/she was assigned to before the user
was deleted. This behaviour is unexpected and is potentially a security problem. When a user
is created again and gets back his/her privileges (through the groups he/she was assigned
to before the user was deleted), then this could be treated as privilege escalation.
> If an attacker has influence on the userID, for example he/she can choose it freely
during account creation, then it would be possible to assume the identity and privileges of
a previously deleted user with higher privileges.
> h1. Steps to Reproduce
>  # Create group named "test".
>  # Create user.
>  # Add user to group.
>  # Delete user.
>  # Create user with same "userID" as in step 2.
> Expected result:
>  * User is not member of group "test".
> Actual result:
>  * User is member of group "test".
> h1. Additional Information
> I have created a unit test to demonstrate this problem. The unit test is in my fork of
the repository and has detailed comments to explain what is going on:
> [https://github.com/jenslauterbach/jackrabbit-oak/blob/OAK-8422/oak-core/src/test/java/org/apache/jackrabbit/oak/security/user/UserManagerImplTest.java#L453]
> You can run the test as follows:
> {code:java}
> git clone -b OAK-8422 https://github.com/jenslauterbach/jackrabbit-oak.git
> cd jackrabbit-oak
> mvn test -DfailIfNoTests=false -Dtest=org.apache.jackrabbit.oak.security.user.UserManagerImplTest#testDanglingUserGroupMemberships{code}
> This should run the unit test I have written and fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message