TrustWave has become a little better in accommodating CentOS in their scans - I can now at least select "I have backported software" when I file a dispute. But they are still providing excellent job security by requiring hours of painstaking pointing and clicking on their website every month.
Now to my question. CVE-2016-10009 has not been patched by the RHEL folks, and there is no direct fix available for CentOS. In TrustWave's response to my initial dispute there is this note:
Since this finding affects PCI DSS Compliance, it does need to be confirmed to have been addressed in some fashion. The requirements as listed within the scan report are to upgrade the system or utilize the compensating controls mentioned (such as never loading PKCS#11 modules from paths outside a trusted whitelist (run-time configurable)).
The latest OpenSSH patch has fixes backported up to OpenSSH 7.3 and it is unclear to me if this particular vulnerability will be addressed. The "compensating control" that is mentioned - only allowing whitelisted modules - is exactly the fix that was put in 7.4, so this is not helpful, and the scan report does not list anything.
I am therefore looking for a configuration change that would satisfy the scanner, but I could not find one. Here is a decent explanation of the issue. Is there something that I can do? Disable PKCS#11 altogether?
This is a vulnerability where a malicious ssh server can attack the client if the client has connected with ssh-agent forwarding, and has somehow gotten a malicious file installed on the client's filesystem.
I also think TrustWave has vastly overestimated the importance of this issue.
That said, the obvious workaround is to disable agent forwarding in
/etc/ssh/sshd_config
.Keep in mind that if the server is compromised, the attacker can just remove that and then wait for hapless admins to connect with their agents. So it's kind of a ridiculous workaround.
I believe this issue is moot.
It's my understanding that Trustwave reviewed the vulnerability and adjusted their CVSS/severity ranking so that the finding is no longer a PCI fail.
(It also bears repeating that
AllowAgentForwarding no
is a silly red herring. That's a server-side configuration, and this is a client-side vulnerability.)I think, as @pilcrow suggested, this is a client-side vulnerability, so the workaround would be on the client side to have the flag
ForwardAgent no
in the file ssh_config.