oss-sec mailing list archives
CVE Request: salt confidentiality issue
From: Johannes Segitz <jsegitz () suse com>
Date: Fri, 25 Nov 2016 09:02:28 +0100
Hello, Dario Leidi from the SUSE Manager Team identified an issue in Salt. Please issue a CVE for this. We contacted the salt security team, according to their (very quick and friendly) reply this is fixed by the 'rotate_aes_key' parameter https://docs.saltstack.com/en/2015.8/ref/configuration/master.html#rotate-aes-key. that was introduced in 2015.8.11 to correct this issue. It is on by default, so the user would have to change that to be vulnerable. Darios detailed writeup: - Overview Salt minions (clients), come with a descriptive id and a crypto key each. Attaching a minion to a master (server) boils down to "accepting its key" with a command on the master. Now it can happen that after one minion is fully accepted, a second one presents itself to the master with the same id but different key. In that case, Salt will figure out that the key is different and reject the second minion, assuming it is an impostor. Due to Salt's caching mechanisms, I found out that under certain circumstances Salt commands can reach, read data from and write data to, both minions ("original" and "impostor"). That includes pillar data, which is supposed to be secret to a certain minion. - Reproducer # run 1 salt-master machine [master] # run 2 salt-minion machine [minion1, minion2] ## 1. start the salt-master rcsalt-master start ## 2. on both minions give to the minion_id the same value, like 'minion-test' vim /etc/salt/minion_id ## 3. start the salt-minion on the minion1 rcsalt-minion start ## 4. accept the key on the master salt-key -a minion-test ## 5. try a simple test command from the master salt 'minion-test' cmd.run 'cat /etc/machine-id' ## 6. delete the key from the master salt-key -d minion-test ## 7. start the salt-minion on the minion2 ## 8. accept the key on the master salt-key -a minion-test ## 9. try a simple test command from the master salt 'minion-test' cmd.run 'cat /etc/machine-id' ## 10. Here it is the bug: the minion1 is still accepted and responding. We could run any command for the minion2, but the minion1 will listen, execute and respond to them too, not only the accepted minion2. ## real output /------------------------------------------------ suma3pg:~ # salt 'minion-test' cmd.run 'cat /etc/machine-id' minion-test: 52c69eb9c1da2a459375571a9b81e400 minion-test: a44f29fe2e8feb459fb021c259d5485f ------------------------------------------------/ ## expected output /------------------------------------------------ suma3pg:~ # salt 'minion-test' cmd.run 'cat /etc/machine-id' minion-test: a44f29fe2e8feb459fb021c259d5485f ------------------------------------------------/ ## 11. in the end it get solved on its own, but ONLY IF the salt-master is restarted rcsalt-master restart - Reproducer Part2 for pillar_data ## set a custom pillar on the server, valid only for 'minion-test' vim /usr/share/susemanager/pillar/top.sls /------------------------ base: 'minion-test': - data ------------------------/ mkdir /usr/share/susemanager/pillar/data vim /usr/share/susemanager/pillar/data/init.sls /------------------------ data: secret: - value: 123456 ------------------------/ ## refresh pillar salt '*' saltutil.refresh_pillar ## redo steps as described above ## ask for pillar salt '*' pillar.items data ## real output /------------------------------------------------ suma3pg:~ # salt 'minion-test' pillar.items data minion-test: data: secret: value: 123456 minion-test: data: secret: value: 123456 ------------------------------------------------/ ## expected output /------------------------------------------------ suma3pg:~ # salt 'minion-test' pillar.items data minion-test: data: secret: value: 123456 ------------------------------------------------/ The result will be that private pillar_data are exposed to the old and rejected minion1 too. ------- Johannes -- GPG Key E7C81FA0 EE16 6BCE AD56 E034 BFB3 3ADD 7BF7 29D5 E7C8 1FA0 Subkey fingerprint: 250F 43F5 F7CE 6F1E 9C59 4F95 BC27 DD9D 2CC4 FD66 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Attachment:
signature.asc
Description: Digital signature
Current thread:
- CVE Request: salt confidentiality issue Johannes Segitz (Nov 25)
- Re: CVE Request: salt confidentiality issue cve-assign (Nov 25)