Untrusted user input in the 'X-RHN-Server-ID' header flows through these functions to be directly used as part of a path name, if CFG.USE_LOCAL_AUTH is true: __checkAuthSessionTokenCache -> update_client_token_if_valid -> set_client_token -> AuthLocalBackend.__setitem__ (_compute_key) -> _fname -> cleanupPath With the resulting path, files are read, written, truncated, deleted, and directories created.
Acknowledgments: Name: Malte Kraus (SUSE)
Discovered in private SUSE fork based on version spacewalk 2.8, but upstream master looks to be equally affected.
The attack does not require authentication. * The attack can be used to force the Proxy into reading files outside of the dedicated token directory. However, unless the said file is specially crafted, this will result in an error and the file content will not be revealed to the attacker. * Considering the parent Satellite trusted, the attack can not be used to force writing data outside of the token directory, nor writing arbitrary data * The attack can be used to test the existence of files in the proxy's filesystem (the error differs whether the token file exists or not) * If the attacker has the ability to write arbitrary data on an arbitrary location, the flaw could be used to execute code on the proxy server, in the context of the proxy service, during the unserialization of the token file.
Mitigation: SELinux in enforcing mode will prevent the proxy to access files that have an incompatible SELinux context
This issue has been addressed in the following products: Red Hat Satellite Proxy v 5.8 Via RHSA-2019:1663 https://access.redhat.com/errata/RHSA-2019:1663
Created attachment 1586994 [details] make sure file is created inside CACHEDIR
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-10137