Our PCI-compliant CentOS 7 system got flagged by Trustwave as FAILED recently due to an OpenSSH vulnerability tagged as CVE-2017-15906, and was told that “OpenSSH sftp-server allows creating zero-length files in read-only mode”. Trustwave also said that upgrading to at least OpenSSH 7.6 will resolve the problem.
We are using SFTP and the configuration was the default one with the following value for subsystem:
Subsystem sftp /usr/libexec/openssh/sftp-server
Since CentOS 7 has no official updates yet to upgrade OpenSSH 7.4 to 7.6, I tried updating the packages on my own referencing this guide: Upgrading OpenSSH on CentOS 6 or 7. I was successful in that aspect, however, it has one big complication. I was locked out of SSH and all our keys do not work anymore even when ssh -vvv says the key is accepted. We are being kicked out right after login. Google Cloud Support (we are using Google Cloud CE instances) believes that there is incompatibility with 7.6 to CentOS 7 and that RedHat and CentOS has not rolled out updates yet and could still be testing and fixing bugs:
The backline support team did answer me.
They were able to reproduce the issue by spinning up their own CentOS 7 machine [and upgrading OpenSSH]. They also couldn’t SSH into the instance after upgrading OpenSSH to version 7.6.
As per your previous message, you were right. They too believe that the problem is caused by a configuration change made to PAM. As a matter of fact, the PAM module was not correctly updated. The backline technician took a backup of /etc/pam.d/sshd before making the changes then he noticed that a lot of lines were missing after the upgrade. He compared the two files. The newer version of /etc/pam.d/sshd has only 6 lines, while the original file had at least 19 lines.
I would like to add that the OpenSSH version 7.6 is not a change RedHat/CentOS have put into mainstream stable yet. This means that even though openSSH 7.6p1 is released, it is not yet in a stable mode with Redhat (Centos). The Redhat team are still working on fixing some bugs.
So upgrading to OpenSSH 7.6 is not an option at this time.
I also see that this vulnerability is only seen if SFTP is on read-only mode. But I do not know how to turn this mode off. I tried finding different resources but there seems to be no specific mention of this mode, but only “how they could turn on read only on specific user”. As I am using a default SSH configuration file, I do not know if read-only mode is enabled by default or not.
I tried changing the subsystem part of
/etc/ssd/sshd_config yet again:
Subsystem sftp internal-sftp
And the PCI scan still failed.
I added another configuration below it:
Match Group psacln ChrootDirectory /var/www/vhosts X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp
Which I think defeats the purpose because now I am chrooting to the main vhosts folder instead of a user which is assigned a folder under vhosts (seems I can only assign ChrootDirectory to a folder that’s owned by the root user). I requested a PCI compliance scan after this change and awaiting for the result as of this writing.
If someone could point me to how to effectively disable read-only mode in OpenSSH’s sftp-server or internal-sftp, I would greatly appreciate it, as I believe that’s the only thing I have to do close this vulnerability.
You can’t do anything to cause the scan to not FAIL. That’s because Trustwave is simply checking your OpenSSH version number and reporting the vulnerability, as if it actually existed, regardless of your actual system configuration.
For this one you will need to dispute the finding and explain the mitigations that you have taken.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.