Bug 1708696 (CVE-2019-10136)
| Summary: | CVE-2019-10136 spacewalk: Insecure computation of authentication signatures during user authentication | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Cedric Buissart <cbuissar> | ||||
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | unspecified | CC: | bkearney, mmraka, rdrazny, security-response-team, tlestach | ||||
| Target Milestone: | --- | Keywords: | Security | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: |
It was found that Spacewalk did not safely compute client token checksums. An attacker with a valid, but expired, authenticated set of headers could move some digits around, artificially extending the session validity without modifying the checksum.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-07-12 13:07:08 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1710351 | ||||||
| Bug Blocks: | 1702600 | ||||||
| Attachments: |
|
||||||
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 |
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.