CVE-2015-8559: knife bootstrap leaks validator.pem private key into system logs #3871
When you 'knife bootstrap' a node, the validator.pem private RSA key is leaked into the system logs /var/log/messages.
The reason is that 'knife bootstrap' constructs a shell command to run on the node from a template, filling the private key in as a here-doc (see
ssh node 'sudo sh -c full-command-goes-here'
As a result, the private key ends up on the command-line, in the process table, and, by way of sudo command logging on most reasonable systems, in the system logs. The logs may also be forwarded to other places (possibly in clear text), and possible stored on other systems, making the private validator key not quite so private any more.
I can't recall but I suspect this is also a problem with the validatorless bootstrapping as well, which copies client.pem up to the node instead validation.pem.
It would be very good not to tactically patch this but to pull more of dan's boostrapper code into knife bootstrap. The big shell command is shitty for so many other reasons as well...
Its being worked on internally, no ETA right now. Since we need to support unix and windows bootstraps, we need a transport abstraction over at least winrm and ssh. That already exists in several places (test-kitchen/chef-provisioning) but needs to get extracted out into its own library. Then mixlib-install and that "mixlib-transport" need to be glued together in knife bootstrap (then those mixlibs need to be patched into test-kichen/chef-provisioning in order to DRY up the code across all the projects). So, its highish priority, but we're trying to engineer it right.
Possible quick band-aid solution:
ssh node 'sudo sh -c 'shell script with here-docs'
echo 'shell script with here-docs' | ssh node "sudo sh"
This allows the shell on the remote system to read and execute commands from stdin, without having everything on the command-line. This also has the benefit of only using a single ssh connection (compared to the possibility of creating the script as a file and scp(1)'ing the file to the remote side for execution).
Either way, please do note that this issue does not only affect the validator key, but other materials as well (for example, the 'encrypted_data_bag_secret'). Also note the race condition noted in #3872.