Advisories for Pypi/Skops package

The Card class of skops, used for model documentation and sharing, allows arbitrary code execution. When a file other than .zip is provided to the Card class during instantiation, the internally invoked Card.get_model method silently falls back to joblib without warning. Unlike the .skops zip-based format, joblib permits unrestricted code execution, hence bypassing the security measures of skops and enabling the execution of malicious code.

An inconsistency in MethodNode can be exploited to access unexpected object fields through dot notation. This can be used to achieve arbitrary code execution at load time. While this issue may seem similar to https://github.com/skops-dev/skops/security/advisories/GHSA-m7f4-hrc6-fwg3, it is actually more severe, as it relies on fewer assumptions about trusted types.

An inconsistency in OperatorFuncNode can be exploited to hide the execution of untrusted operator.xxx methods. This can then be used in a code reuse attack to invoke seemingly safe functions and escalate to arbitrary code execution with minimal and misleading trusted types. Note: This report focuses on operator.call as it appears to be the most interesting target, but the same technique applies to other operator methods. Moreover, focusing on a …

Deserialization of untrusted data can occur in versions 0.6 or newer of the skops python library, enabling a maliciously crafted model to run arbitrary code on an end user's system when loaded.