A critical security issue in the Xen virtualization software will become public on Tuesday, November 22nd 2016. The Xen team has already informed Gandi of the necessary patches.

Following this announcement, we have pre-emptively deployed the patches required to correct the issue. We have been monitoring the particular security flaw, and have determined that we will need to stop/start certain Xen VMs in order to assure that no further attack vector remains.

We will be contacting the affected customers by email in order to allow them to sufficiently prepare for this stop/start. Those of you who do not receive any message from us about needing to stop and start your VM are therefore unaffected.

 

 In order to minimize downtime and the impact in general, we advise all affected customers to perform a stop/start of their platforms sometime between now and November 22, 2016.

Warning: a simple "reboot" of the concerned servers is not enough. They must be stopped and started in order to apply the security measures.

Any affected VMs that you have not yet been stopped and started prior to the maintenance will be automatically stopped and started by us on November 22 at 3:00 AM PST (11:00 UTC). Please expect around 30 minutes of downtime per stop/start.

As always, if you have any questions or need of assistance, please do not hesitate to contact our Customer care team.


A critical security issue in the virtualization software Xen will become public July 26 and the Xen team has already informed Gandi of the necessary patches. 

Since this announcement, we have already preemptively deployed the patches required to correct the issue. We have been monitoring the particular security flaw and have determined we will need to stop/start certain Xen VMs in order to assure that no further possible attack vector will remain.

We will be contacting the affected customers directly in order to allow them to sufficiently prepare for this stop/start and those of you who have not received any message from us are therefore not affected.

In order to minimize downtime and also to help minimize the impact in general, we would advise all affected to schedule a stop/start of their platforms yourselves sometime between now and the cutoff date of July 26, 2016.

Any affected VMs that you have not yet stopped and started again by 12:00 AM PDT July 26, 2016 (07:00 UTC), we will stop/start at some point between then and July 28 at 9:00 AM PDT (16:00 UTC). Please expect around 30 minutes of downtime per stop/start.

As always, if you have any questions or have any difficulties, please do not hesitate to contact our Customer care team.

Edit 7/21/16: Previously we used the term "reboot" instead of "stop/start." Rebooting isn't sufficient to apply the security patch. Your VM(s) need to be stopped and then started again in order for the patch to take effect.


ImageMagick announced a security vulnerability, registered as CVE-2016-3714, that allows malicious users to craft filenames to execute code remotely.

We have applied the appropriate fixes on Simple Hosting to protect customer applications using ImageMagick libraries.

If you're using ImageMagick in your application, make sure you restart your instance after 18:00 UTC (11:00 AM PDT) on May 4, 2016 in order to apply the patch.

You can restart your instance from the website or from the terminal with Gandi CLI:

$ gandi paas restart {instance_name}

Please don't hesitate to contact Customer Care if you experience any issues or have any questions related to this topic.


Following this announcement we applied the necessary patches, thus reinforcing the existing security measures we had previously implemented. Over the past week, we have continued to study the vulnerability. As a preventative measure, we have decided that a reboot of KVM based VMs is required in order to ensure that all possible attack vectors have been mitigated.

We will contact affected customers directly via email to provide instructions on performing the reboot on their own. This preventive reboot will not affect customers we do not contact.

We will reboot the VMs of affected customers (who have not rebooted on their own) on November 19th. An outage of 30 minutes maximum is expected for each impacted VM.

If you have questions or encounter any problems regarding this issue, our support team is available to assist you.

A new critical security vulnerability will be publicly announced Thursday, October 29. The Xen team has already communicated fixes to Gandi. This flaw is found in the Xen virtualization software.

Following this announcement we applied the necessary patches, thus reinforcing the existing security measures we had previously implemented. Over the past week, we have continued to study the vulnerability. As a preventive measure, we have decided that a reboot of Xen-based VMs is required in order to ensure that all possible attack vectors have been mitigated.

We will contact affected customers directly via email to provide instructions on performing the reboot on their own. This preventive reboot will not affect customers we did not contact
We strongly recommend that customers concerned by this to restart their VMs themselves, in order for them to verify that all of their services have been correctly restarted.

We will reboot the VMs of affected customers (those which were not rebooted by their owner) from Thursday, October 22 until Wednesday, October 28. An outage of 30 minutes maximum is expected for each impacted VM.

Maintenance status page: http://status.gandi.net/timeline/events/226


We recommend making sure that automatic updates are enabled for your WordPress installation, or running a manual update. There's a lot to gain, and a lot to lose if you don't, since this release is mainly focused on security fixes.

Two of the corrected vulnerabilities are XSS (Cross Site Scripting), related to the processing of "shortcode" tags in versions 4.3 and earlier, and the user list page.

The other problem is a privilege escalation which in some cases allows an unauthorized user to post private items and mark them as "sticky".

Although this version does not add any new features, it corrects a total of 26 bugs that exist in version 4.3.

In all, 64 files have been modified, with improvements to various aspects of the web interface of the world's most popular CMS, as well as its backend functions.

So, log in to your admin console and get started!

Visit the official changelog for more details: https://codex.wordpress.org/Version_4.3.1


A new security vulnerability, CVE-2015-3456, was announced last week. The flaw is found in the QEMU virtualization software, and permits an attacker to gain access to a vulnerable host from a virtual machine located on that host.

Immediately following this announcement, we applied the necessary patches, thus reinforcing the existing security measures we had previously implemented. Over the past week, we have continued to study the vulnerability. As a preventative measure, we have decided that a reboot of certain VMs is required in order to ensure that all possible attack vectors have been mitigated.

This preventive reboot will only affect a small proportion of our customers. We will contact affected customers directly via email to provide instructions on performing the reboot on their own.

We will reboot the VMs of affected customers (who have not rebooted on their own) on Monday, May 25 at 11:59 p.m. PDT (that is: Tuesday, May 26, 2015 at 07:59 UTC).

For more information, see the following resources:

If you have questions or encounter any problems regarding this issue, our support team is available to assist you.


We have updated mirrors.gandi.net following today's announcement of the GHOST vulnerability. This newly-discovered flaw is in the popular glibc library, which is used in many Linux distributions and different flavors of Unix. The newly-discovered flaw, which has been present since November 2000, enables an attacker to execute code remotely on a vulnerable system.

We recommend that you upgrade your servers immediately. The following patches have already been made available by the distribution teams:

We will keep this list and our mirrors up-to-date as more affected distributions release their fixes.

If you are a Simple Hosting customer, we recommend that you restart your instance.


Starting this Wednesday, October 22[1], Gandi will begin issuing SHA-2 Standard, Pro and Business SSL certificates.

As you may have heard, the SHA-1 signature algorithm is being gradually deprecated in favor of SHA-2 (including SHA256, SHA-512, and so on).

Don't panic, though. At present, it's still really hard to break a SHA-1 hash. But collision attacks against SHA-1 will only become easier, so the sooner everyone migrates, the better.

Note that if you are currently using a SHA-1 certificate or want to buy one, you will still be able to do so. We are now entering a transition period where both the algorithms are supported. SHA-1 will be supported until 1 January 2017.

The majority of certification authorities, browsers, and operating systems already support SHA-2. You may encounter compatibility problems in some cases, for example with Mozilla Firefox[2], as not all root certificates supporting SHA-2 have been added. This process is now underway for various browsers.

If you're ready to migrate to SHA-2, you have two options to choose from:

  • If you want to secure your website or application with SHA-2 only, and the issue of compatibility is not a concern, install your SHA-2-signed certificate along with the SHA-2 intermediate certificate only. This solution is the most secure, since the entire certificate chain will be SHA-2. It is a good option if you want to emphasize security over compatibility, or if you are certain that your visitors have SHA-2 enabled browsers (for example, all the employees of a company are using modern browsers to access a secure site).
  • If you want to provide SHA-2 while avoiding compatibility issues with certain browsers that have not yet updated the root certificates, you can use the intermediate certificate with SHA-2 enabled and add the cross-signed SHA-1 intermediate certificate as well. If so, the last element of the chain of trust will be SHA-1, which is not optimally secure. This option is useful during the transition period: once all relevant browsers have performed the update, you can then remove the cross-signed intermediate certificate. This option is good if you want to switch to SHA-2 without disturbing visitors whose browsers do not have updated root certificates.

Attention! New intermediate certificates, which differ from those used with plain old SHA-1, will be issued with certificates signed with SHA-2. Be sure to use the correct intermediate certificate to match the hashing algorithm used in your main certificate. You can verify the signature of the certificate with the following command:

$ openssl x509 -in example.crt -text -noout

The output will contain lines like the following, indicating the certificate is signed with SHA-1 or SHA-2, respectively.

For certificates issued with SHA-1:

Issuer: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA 

and:

Signature Algorithm: sha1WithRSAEncryption

For certificates issued with SHA-2:

Issuer: C=FR, ST=Paris, L=Paris, O=Gandi, CN=Gandi Standard SSL CA 2

and:

Signature Algorithm: sha256WithRSAEncryption

Here's an example of a valid trust chain for a SHA-2 certificate:

Certificate chain

0 s:/OU=Domain Control Validated/OU=Gandi Standard SSL/CN=example.com

i:/C=FR/ST=Paris/L=Paris/O=Gandi/CN=Gandi Standard SSL CA 2

1 s:/C=FR/ST=Paris/L=Paris/O=Gandi/CN=Gandi Standard SSL CA 2

i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority

2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority

i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

We have put in place some rules to ensure we deliver the right certificates for SHA-1 and SHA-2. Please be sure you review these and get the right certificates for your site or application:

Until 1 January 2016:

  • Certificates with an expiration date after 1 January 2017 will be issued as SHA-2 only, even if the CSR was generated with SHA-1.
  • Certificates with earlier expiration dates will be issued as SHA-1 if the CSR was generated with SHA-1
  • Certificates with earlier expiration dates will be issued as SHA-2 if the CSR was generated with SHA-2 

After January 1, 2016:

  • All certificates will be issued in SHA-2, regardless of the hash specified in the CSR

Note that if you already have a certificate, you can regenerate it as SHA-2 by chosing the regenerate option and using a CSR signed with SHA-2. Remember to update the intermediate certificate on your server if you do this.

For more information, please visit our documentation:

[1] Several weeks ago, our SSL partner, Comodo, began issuing certificates in SHA-2 if the expiration date of the certificate was after January 1, 2017. This caused some confusion for customers whose issued certificates weren't signed with the signature algorithm they were expecting, and who therefore may have installed the wrong intermediate certificates, resulting in some confusion. We weren't able to update our documentation to reflect this in a timely manner, and for this we sincerely apologize. You will now find all the information you need to set up your SHA-2 certificates at the links above.

[2] You can install the root certificate manually by navigating to this URL in Firefox:

http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt


In response to the publication of a security flaw in the design of SSLv3, we have integrated TLS_FALLBACK_SCSV on our hosting platform and mailservers.

The flaw, dubbed POODLE in the announcement by the Google security team, allows a network attacker to force use of a less secure version of the protocol, making it easier to obtain the content of secure connections in plain text.

If for some reason you are not able to upgrade to a modern browser or operation system, you should take steps to protect yourself, such as disabling SSLv3 in your browser.

SSL 3.0 is already an obsolete protocol, so the vast majority of email clients will not notice any difference. However, some very old email clients, operating systems and browsers (Windows XP, IE6) may encounter issues. If you notice any problems connecting to our mailservers, please write to our support team with details.

For those interested in the technical details, there's some good reading over at Ars Technica (new window).

Note: We considered disabling SSLv3 on connections to mail.gandi.net via IMAP and POP3, but decided not to do so immediately. We will do so in the months to come, after taking steps to minimize the impact it will have on our customers' services.


Page 1 2
Change the news ticker size