Changing an organization teams permission through the API with only the permission field did not rebuild the teams per-unit access, and the requested level was not applied as a cap. After an organization owner demoted a team, for example from admin to read, the teams members kept their previous unit permissions, including write access to the teams repositories. The web form was not affected.
Weakness
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
Potential Mitigations
- Compartmentalize the system to have “safe” areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Related Attack Patterns
- https://cwe.mitre.org/data/definitions/17.html
- https://cwe.mitre.org/data/definitions/35.html
- https://cwe.mitre.org/data/definitions/76.html