Piccolo is an ORM and query builder which supports asyncio. In versions 0.120.0 and prior, the implementation of BaseUser.login leaks enough information to a malicious user such that they would be able to successfully generate a list of valid users on the platform. As Piccolo on its own does not also enforce strong passwords, these lists of valid accounts are likely to be used in a password spray attack with the outcome being attempted takeover of user accounts on the platform. The impact of this vulnerability is minor as it requires chaining with other attack vectors in order to gain more then simply a list of valid users on the underlying platform. The likelihood of this vulnerability is possible as it requires minimal skills to pull off, especially given the underlying login functionality for Piccolo based sites is open source. This issue has been patched in version 0.121.0.
Weakness
The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.
Affected Software
| Name |
Vendor |
Start Version |
End Version |
| Piccolo |
Piccolo-orm |
* |
0.121.0 (excluding) |
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.
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
References