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?

  • 2
    Disable agent forwarding? There is an option AllowAgentForwarding.
    – user9517
    Jan 25, 2017 at 20:59
  • I like the English way, thanks. I made the change and resubmitted. Will report back.
    – cdonner
    Jan 25, 2017 at 21:11

3 Answers 3


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.

AllowAgentForwarding no

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.

  • Ridiculous claims require ridiculous workarounds.
    – user9517
    Jan 25, 2017 at 21:24
  • Indeed, and the dispute was approved and the scan passed. Thanks again, English Way!
    – cdonner
    Jan 25, 2017 at 21:44

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.