What is the issue?
Researchers have discovered a vulnerability in the glibc library, used by many Linux systems, which may allow remote attackers to cause a denial of service or potentially initiate arbitrary code execution via a crafted DNS response.
For details please refer to:
What components of Syncplicity are affected?
The issue may impact customers’ deployment of the Syncplicity On-Premise Storage Connector.
Is Syncplicity’s cloud service vulnerable to this issue?
Syncplicity’s cloud servers use a specific internal resolver and would not be vulnerable to an external DNS exploit. We have no indications or reason to believe that this vulnerability may have been exploited. As a standard practice, all servers in Syncplicity’s cloud that may have included vulnerable versions of the glibc library have been patched.
What steps do customers need to take to address the vulnerability?
There is no action needed by Syncplicity Personal Edition, Business Edition, and Enterprise Edition cloud storage only customers to address this vulnerability.
Customers that have configured a Syncplicity On-Premise Storage Connector are advised as follows:
Step 1: All customers should verify the glibc version running on their Storage Connectors. Versions 2.9 up to 2.12-1.166 are known to be vulnerable.
Step 1.1: To verify glibc, ssh to each deployed storage connector
Step 1.2: run the following command: sudo yum list glibc
glibc.i686 2.12-1.166.el6_7.7 updates
glibc.x86_64 2.12-1.166.el6_7.7 updates
In this case the server is running glibc-common-2.12-1.132 which is known to be vulnerable, and should be patched.
Step 2: Customers who have deployed their Storage Connectors using an rpm should update their glibc version as follows. Note: customers whose Storage Connectors are behind a firewall may need to whitelist centos.org and related remote mirrors necessary to retrieve the patched components.
Step 2.1: To update the glibc version, run the following command: sudo yum -y update glibc
Sample response (this is typically located at the end of the message)
Step 3: Customers who have deployed their Storage Connectors using an .ova in vSphere should verify their .ova version. OVA versions 2.5 and newer contain a CentOS based image that already has the patched glibc version.
Note: If you have v2.5.1 or v2.5.2 you are encouraged to upgrade to the most recent .ova release which is 126.96.36.199 as of March 2016.
Step 3.1: To verify your .ova version, ssh to each deployed storage connector
Step 3.2: Run the following command: sudo yum info syncp-storage | grep Version
Note the version, if it is any of the following, the Storage Connector image may include a vulnerable version of glibc:
If the version is lower than 188.8.131.52 is no longer supported and should be upgraded to the newest released version to maintain a supported configuration.
Step 3.3 run the following command to update your image:
Step 3.4: After updating the glibc package on affected systems, it is recommended to reboot the system or restart all the affected services.
For future reference, the latest Storage Connector version is maintained on this support site under Latest Server Versions, https://syncplicity.zendesk.com/hc/en-us/articles/204203890.
If you have any questions, please contact Syncplicity Support.
Syncplicity recommends that all users determine the applicability of this information to their individual situations and take appropriate action. The information set forth herein is provided "as is" without warranty of any kind. Syncplicity disclaims all warranties, either express or implied, including the warranties of merchantability, fitness for a particular purpose, title and non-infringement. In no event, shall Syncplicity or its suppliers, be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Syncplicity or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages, so the foregoing limitation may not apply.