Impact: This CVE affects any users running the Salt API. An unauthenticated user with network access to the Salt API can use shell injections to run code on the Salt-API using the SSH client.
Description: A user could use shell injections with the Salt API using the SSH Client.
Solution: Prevent shell injections in netapi SSH client
How to Mitigate: Install the CVE fix and ensure your Salt-API has been restarted
Severity Rating: TBD: Assessed as likely going to be a High or Critical
Impact: This CVE affects any Minions or Masters that previously used the create_ca, create_csr, and create_self_signed_cert functions in the TLS module.
Description: When using the functions create_ca, create_csr, and create_self_signed_cert in the tls execution module, it would not ensure the key was created with the correct permissions. With the CVE fix, the keys are no longer created with world-readable permissions and use 600.
Solution: Prevent creating world-readable private keys with the tls execution module.
How to mitigate: Users will need to check to ensure 600 permissions are applied to any keys that were previously created by the TLS execution module. Going forward, if the CVE fix is applied while using the tls module, the created keys will have the correct permissions.
Severity Rating: TBD: Assessed as likely going to be a Low
Impact: Affects users running the Salt API. Salt-netapi improperly validates eauth credentials and tokens.
Description: Properly validate eauth credentials and tokens along with their Access Control Lists – ACLs. Prior to this change, eauth was not properly validated when calling Salt SSH via the salt-api. Any value for “eauth” or “token” would allow a user to bypass authentication and make calls to Salt SSH.
Solution: When using the SSH client, an unauthenticated user can gain access to run commands against targets set in an Salt-SSH roster.
How to Mitigate: Install the patch provided below and restart your Salt-API
Severity Rating: TBD. Expected to be a High or Critical
all arches done
Please cleanup, thanks!
This issue was resolved and addressed in
GLSA 202011-13 at https://security.gentoo.org/glsa/202011-13
by GLSA coordinator Sam James (sam_c).
Reopened for cleanup.