Salt peppered with holes? Automation tool vulnerable to auth bypass: Patch now

‘The impact is full remote command execution as root on both master and all minions’

Hackers can penetrate Salt servers and potentially control other servers from there

The Salt configuration tool has patched two vulnerabilities whose combined effect was to expose Salt installations to complete control by an attacker. A patch for the issues was released last night, but systems that are not set to auto-update may still be vulnerable.

The vulnerabilities were discovered by security company F-Secure and assigned CVE numbers CVE-2020-11651 and CVE-2020-11652. They are patched in Salt 3000.2 and, for the previous stable release, 2019.2.4. Older releases will have to be fixed manually.

Salt is a tool from SaltStack which has both commercial and open source editions. It lets you define system components and applications in text as a “salt state” and then apply them to remote systems in a data centre or on a public cloud. In Salt terminology, a Master is a central Salt server which issues commands, and a Minion is a remote process that listens for commands and performs them. The communication protocol is ZeroMQ.

The first vulnerability, CVE-2020-11651, is an authentication bypass which, said F-Secure, “unintentionally exposes the _send_pub() method, which can be used to queue messages directly on the master publish server. Such messages can be used to trigger minions to run arbitrary commands as root.”

As if that were not bad enough, CVE-2020-11652 is a directory traversal vulnerability in the “wheel” module used to read and write files. “The inputs to these functions are concatenated with the target directory and the resulting path is not canonicalized, leading to an escape of the intended path restriction,” the researchers added. “The impact is full remote command execution as root on both the master and all minions that connect to it.”

The implications are severe since it is potentially handing over to the bad actor not only control of servers, but also the ability to configure new resources on clouds such as AWS.

F-Secure is refusing to post a proof of concept exploit as “this would only harm any users who are slow to patch.” That said, it is not much protection, since the company also said: “We expect that any competent hacker will be able to create 100 per cent reliable exploits for these issues in under 24 hours.”

Disclosure of the vulnerabilities to SaltStack was delayed by several days because the company expects issues to be reported via encrypted and signed emails but the published GPG key for this had expired in 2018, said F-Secure. An updated key was eventually published and a report received by SaltStack on 20th March.

SaltStack obtained CVE numbers in early April and one week ago, on 23rd April, warned users that they should not expose master servers to the internet and should prepare for an urgent patch.

Salt users have had little time to respond, and F-Secure has flagged the concern that: “A scan revealed over 6,000 instances of this service exposed to the public Internet. Getting all of these installs updated may prove a challenge as we expect that not all have been configured to automatically update the salt software packages.”

It is difficult to patch open source projects without at the same time revealing the vulnerability, which may be a factor in the disclosure timing.

Exposing a Salt master to the internet is not best practice and firewall security should be implemented. “Adding network security controls that restrict access to the salt master (ports 4505 and 4506 being the defaults) to known minions, or at least block the wider Internet, would also be prudent as the authentication and authorization controls provided by Salt are not currently robust enough to be exposed to hostile networks,” continued F-Secure.

A further annoyance is that in fixing the authentication issue the SaltStack developers introduced a bug. “The _minion_runner method should be minion_runner (without the underscore prefix). This typo breaks the publish module’s runner method,” the docs stated. This may well break scripts in use. A fix for this is promised “in mid-June 2020.”

According to a recent Flexera “State of the cloud” report Salt is used by around 17 per cent of organisations with cloud deployments. The newly reported vulnerability shows first that auto-update is worth considering if it is not already enabled, and second, that network security is critical alongside patch management. ®

Sponsored: Webcast: Build the next generation of your business in the public cloud