During user authentication, the hash input does not contain any length fields or field boundaries, so that the same hashes are computed e.g. for {server-time=1234, expire-offset=567} (end date 1801) and {server-time=1, expire-offset=234567} (end date 234568). An attacker could use this flaw to reuse an expired token, and extend its expiry date.
Acknowledgments: Name: Malte Kraus (SUSE)
in server/apacheAuth.py : 139 def auth_client(): [...] 165 clientId = token['x-rhn-server-id'] 166 username = token['x-rhn-auth-user-id'] 167 signature = token['x-rhn-auth'] 168 rhnServerTime = token['x-rhn-auth-server-time'] 169 expireOffset = token['x-rhn-auth-expire-offset'] 170 171 172 computed = computeSignature(CFG.SECRET_KEY, clientId, username, 173 rhnServerTime, expireOffset) There's no separator between the entries : an attacker could capture a regular token, then shift any field's digits to its neighbors, without modifying the signature, ending up in an extended life. Mainly : 1) It is not uncommon for the username of be empty, so the cliendId's digits can be migrated to Server Time, possibly giving you a long term token at the cost of the server ID 2) rhnServerTime is a float with 2 digits following the '.' : you can migrate these 2 digits to the expire offset to multiply the validity of the token (i.e.: Server time will remain almost the same, but expire will be possibly greatly extended)
This issue has been addressed in the following products: Red Hat Satellite 5.8 Via RHSA-2019:1661 https://access.redhat.com/errata/RHSA-2019:1661
Created attachment 1586993 [details] set field boundaries in signature token
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-10136