Todos not removed for shared projects - Access to (confidential) issues and MRs

HackerOne report #722001 by xanbanx on 2019-10-24, assigned to @jeremymatos:

Hi GitLab Security Team,

Summary

I found a way to bypass the Todo redaction within GitLab. Normally, GitLab removes Todo after a one hour grace period when a user for example leaves a project or does not have access to the feature anymore. However, this is not applied in the case of sharing a project with a group. If a project is shared within a group, the group members receive Todos, e.g., when they are mentioned on issues.

However, when the shared group is removed from the project, Todo for all group members persist. By using the REST API of GitLab, a user can get much more associated information of the Todo. He now can receives for example the full issue, including the title, and description. Note, this is always the fresh and most recent version, which might have changed after the group was removed from the project. Furthermo

Steps to reproduce

1. Share a private project with another group according to the documentation in https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html
2. As a group member, go to one issue of the project, and add a personal Todo via the Add a To Do button in the sidebar of the issue
3. Remove the group from the project
4. Wait for one hour grace period
5. As the group member, perform the following API call: curl --header "PRIVATE-TOKEN: <TOKEN>" https://example.gitlab.com/api/v4/todos

This now returns the old Todo from the previously shared project, which you don't have access to anymore.
This looks similar to the JSON response below. Note, this contains small parts of the private project but also the full details of the issue. The issue here is the most recent version. So if someone from the the project changes the issue description, you also see that here!

[
    {  
        "id": 227,  
        "project": {  
            "id": 17,  
            "description": "",  
            "name": "my-private-project",  
            "name_with_namespace": "testuser / my-private-project",  
            "path": "my-private-project",  
            "path_with_namespace": "testuser/my-private-project",  
            "created_at": "2019-10-24T08:24:25.844Z"  
        },  
        "author": {  
            "id": 4,  
            "name": "testuser",  
            "username": "testuser",  
            "state": "active",  
            "avatar_url": "https://secure.gravatar.com/avatar/d113f00d385aac3f93dcda1532432ee8?s=80&d=identicon",  
            "web_url": "https://example.gitlab.com/testuser"  
        },  
        "action_name": "directly_addressed",  
        "target_type": "Issue",  
        "target": {  
            "id": 527,  
            "iid": 2,  
            "project_id": 17,  
            "title": "Critical security release",  
            "description": "We need to fix this RCE vulnerability ASAP [@]all",  
            "state": "opened",  
            "created_at": "2019-10-24T08:34:07.028Z",  
            "updated_at": "2019-10-24T08:34:07.028Z",  
            "closed_at": null,  
            "closed_by": null,  
            "labels": [],  
            "milestone": null,  
            "assignees": [],  
            "author": {  
                "id": 4,  
                "name": "testuser",  
                "username": "testuser",  
                "state": "active",  
                "avatar_url": "https://secure.gravatar.com/avatar/d113f00d385aac3f93dcda1532432ee8?s=80&d=identicon",  
                "web_url": "https://example.gitlab.com/testuser"  
            },  
            "assignee": null,  
            "user_notes_count": 0,  
            "merge_requests_count": 0,  
            "upvotes": 0,  
            "downvotes": 0,  
            "due_date": null,  
            "confidential": true,  
            "discussion_locked": null,  
            "web_url": "https://example.gitlab.com/testuser/my-private-project/issues/2",  
            "time_stats": {  
                "time_estimate": 0,  
                "total_time_spent": 0,  
                "human_time_estimate": null,  
                "human_total_time_spent": null  
            },  
            "task_completion_status": {  
                "count": 0,  
                "completed_count": 0  
            },  
            "has_tasks": false,  
            "_links": {  
                "self": "https://example.gitlab.com/api/v4/projects/17/issues/2",  
                "notes": "https://example.gitlab.com/api/v4/projects/17/issues/2/notes",  
                "award_emoji": "https://example.gitlab.com/api/v4/projects/17/issues/2/award_emoji",  
                "project": "https://example.gitlab.com/api/v4/projects/17"  
            },  
            "subscribed": false  
        },  
        "target_url": "https://example.gitlab.com/testuser/my-private-project/issues/2",  
        "body": "We need to fix this RCE vulnerability ASAP",  
        "state": "pending",  
        "created_at": "2019-10-24T08:34:07.094Z"  
    }  
]

Impact

The impact of this vulnerability is actually quite high. A malicious user of the group, can simply add a personal todo on all issues, including confidential issues, and merge requests of the project. This can easily be one Add a To Do in the sidebar of an issue or merge request. After the group is removed from the project, the malicious user has access to all issues and merge requests. Note, this always returns the most recent version of the issue or merge request!

What is the current bug behavior?

Todos are not redacted when the group is removed as a project member.

What is the expected correct behavior?

When the group is removed from the project, wait for the 1h grace period, and then remove all todos on the project for the group members.

Output of checks

This bug happens on GitLab.com currently running on GitLab Enterprise Edition 12.3.0-pre d92a13b6 but also on local installation on GitLab 12.4.0.

Best regards,
Xanbanx

Impact

See above.