by the OCF Engineering Team
After the vulnerability disclosed in https://labs.f-secure.com/advisories/saltstack-authorization-bypass which carries with it a HIGH severity score, OCF have been in discussion with SaltStack and been supplied a mitigation for customers affected by this vulnerability running on previous versions of SaltStack.
The first step however is to upgrade the version of salt
to at least 2017.7.x first (please talk to us if you wish to go further than this as there are potential breaking code changes for certain salt formulas) first and foremost in order to be able to apply these patches.
The process for this is as follows:
Synchronise Repositories Locally (optional)
Use the reposync process to make a copy of the salt-2017.7 repository. You can update your repository to synchronise with the 2017.7 repository by updating the file in reposync.repos.d to read:
[saltstack-2017.7]
name=saltstack-2017.7
baseurl=https://repo.saltstack.com/yum/redhat/7/x86_64/2017.7/
enabled=1
gpgcheck=0
And synchronise as explained in your documentation.
Point your head nodes to appropriate package upgrade locations for SaltStack 2017.7.x
Configure your servers yum repository to point the new localised 2017.7 repository files – an example of which is below:
[saltstack-repo]
name=SaltStack repo for RHEL/CentOS $releasever
enabled=1
baseurl=http://mgmtha.cluster.local/install/post/otherpkgs/repos/saltstack-2017.7
gpgcheck=0
If you have a headnode with HA:
pcs resource unmanage salt
On your master node(s):
systemctl stop salt-master
cp -Rp /etc/salt ~/salt-backup #(just as a precaution)
yum -y update salt salt-master
systemctl start salt-master
On a minion node:
salt-call pillar.items
salt-call pillar.highstate #(to be sure all is still working – we would recommend NOT doing this on your master servers!)
At this point you are ready to patch your newly installed/upgraded 2017.7.x instance to an installation without the vulnerability.
Patching Process
Once the version of salt-master (and salt-minion and associated libraries) is up to 2017.7.x then you can apply the patch attached to this article.
If you however are on version 2018.3.x – you can apply the second patch attached to this article.
NB: you need to ensure you have shut down your salt-master instance cleanly – if you have a high-availability instance, be sure to set the resource to unmanaged first before upgrading!
To apply the 2017.7.x patch:
cp Fix-CVE-2020-11651-and-Fix-CVE-2020-11652-2017.7.x.patch /tmp/
systemctl stop salt-master
cd /usr/lib/python2.7/site-packages/
patch -p1 < /tmp/Fix-CVE-2020-11651-and-Fix-CVE-2020-11652-2017.7.x.patch
systemctl start salt-master
And the 2018.3.x patch:
cp Fix-CVE-2020-11651-and-Fix-CVE-2020-11652-2018.3.x.patch /tmp/
systemctl stop salt-master
cd /usr/lib/python2.7/site-packages/
patch -p1 < /tmp/Fix-CVE-2020-11651-and-Fix-CVE-2020-11652-2018.3.x.patch
systemctl start salt-master
On a node:
salt-call pillar.items
salt-call pillar.highstate #(to be sure)
And finally If you have a headnode with HA:
pcs resource manage salt
2019.2.x users
If you are one of our latest deployments, you can simply upgrade your 2019.2.x instance to 2019.2.4 which has the vulnerability patches already included.
The patches you need are here
SaltStack CVE Patches