OpenSSH client vulnerabilities: CVE-2016-0777 and CVE-2016-0778

Two neOpenSSHw vulnerabilities, CVE-2016-0777 and CVE-2016-0778, were found yesterday on the OpenSSH project which allows a malicious SSH server to steal the client’s private keys when using the roaming undocumented feature. So, if you have to connect to any server that is not under your control (including git over SSH through third-party services like GitHub or Bitbucket), keep reading!

Vulnerability details

Since version 5.4, the OpenSSH client (this is important, only the client) supports an undocumented feature called roaming. This feature is useful to resume an SSH session if the connection breaks unexpectedly. Unfortunately, it is enabled by default in all OpenSSH clients, and can be used by malicious servers to steal the client’s private keys thanks to information leak and a buffer overflow.

How can I protect myself?

Security patches are being released, but in the meantime it can be hot-fixed by setting the undocumented option “UseRoaming” to “no”.


$ echo 'UseRoaming no' | sudo tee -a /etc/ssh/ssh_config


$ echo "UseRoaming no" >> ~/.ssh/config

What about my server? Should I upgrade?

It is not necessary. The roaming feature is not supported by the OpenSSH server, so the vulnerability only affects to clients connecting to SSH servers. If you connect to a malicious server or in case it is compromised, you might be sharing your private key.

Further reading

January 15 / 2016
Author Raul
Comments No Comments

Upcoming Conferences

Changing the version of PHP in shared hosting

PHP 5.3 and 5.4 are no longer supported, so they won’t get fixes for security vulnerabilities and bugs. Unfortunately, most PHP projects still use these versions. From ServerGrove, we highly recommend you all to upgrade to supported versions of PHP, especially 5.6 and 7.0.

PHP 5.5 is not actively supported but it will receive fixes for security vulnerabilities until July, 2016. PHP 5.6 will be supported until August, 2016 (security fixes until August, 2017), while the shiny PHP 7.0 will get two more years of support and three for security issues.

Changing the version of PHP

We are working on providing PHP 7.0 in all our plans, but if you are using an unsupported version, please change to PHP 5.6 as soon as possible. Changing the version of PHP in our shared hosting plans is fast and easy. For newer versions of Plesk go to Subscriptions > your_subscription > Hosting Settings, and select the PHP version under “Web scripting and statistics”:

Changing the PHP version from Plesk

For older versions of Plesk, the version of PHP can be changed by adding the following line to your .htaccess file:

AddHandler application/x-httpd-php56 php

Change “php56” by “php55” or “php54” for PHP 5.5 and 5.4 respectively.

Migration guides

While PHP tries really hard to keep backwards compatibility, you may have to perform some changes to adapt your project to a newer version. To make the work easier, there are migration guides to adapt your codebase:

Checking if your code is compatible with PHP 5.6

Not sure if your code is compatible with PHP 5.6? You can use PHP_CodeSniffer + PHPCompatibility to get a report of incompatibilities for different versions of PHP.

Photo by philipsharp. CC BY-SA 2.0.

December 23 / 2015
Author Raul
Category PHP, Tutorials
Comments No Comments

Upcoming Conferences

Symfony Awards 2015

A few days ago, SensioLabs presented the third edition of the Symfony Community & Business Awards, which will be announced during the SymfonyCon Paris 2015. We are really happy to hold one of them, as back in 2013, our Control Panel won the “Best B2B Application” award.

For this year’s edition we are not participating as a company. Our Symfony-based Control Panel is pretty stable so we are working hard on other aspects such as infrastructure, security and monitoring. But I would like to ask you, not as ServerGrove but as Raul Fraile (the person behind most ServerGrove’s blog posts) your vote in the “2015 Best Blogger” category. I am glad that ServerGrove encourages me to write technical posts in the blog, and as a Symfony developer, I always try to give back to the community. This year I continued the Symfony components overview series, which explain how to use the Symfony components standalone and dives into their internals, and wrote a few more PHP and Symfony related posts. Here you have the full list of posts of the series as well as all the posts published in 2015:

Symfony components overview series:

Other PHP or Symfony related posts published this year:

If you like my posts and want to encourage me to write more in 2016, please vote for “raulfraile” in the “2015 Best Blogger” category in the Symfony Community Awards page :)

Thank you!

November 30 / 2015

Upcoming Conferences

Introduction to the PHAR format

In the last years there is a trend in the PHP community to release tools, especially command line utilities, as PHAR files, so you can package an entire PHP application into a single file for convenience. But, how PHAR files work? In this post we will try to explain it.

PHAR files

PHAR files let you package PHP applications into a single file

What are PHAR files

PHAR files are equivalent to JAR files in the JAVA world, but for PHP. That is, a way to pack several PHP files, or any other resource, in a single file and be able to execute it.

Who is using PHAR files

Composer, PHPUnit or the Symfony installer are only three examples of projects using PHAR files. PHARs are especially useful for command line tools, so the user just have to download the file and execute it, as it already contains all the dependencies.

Creating the simplest PHAR file

So, let’s create the simplest PHAR file we can imagine, so we can investigate later what that file we are going to generate contains. First, let’s write a simple stub, which usually takes care of loading the autoload system and create a “map” to be able to find the files included in the PHAR file. The stub must always end with a call to the __halt_compiler() function, which tells the PHP interpreter to halt the execution and stop parsing the code.

#!/usr/bin/env php

echo 'hello world!';


After this, we can create a really simple (and quite useless) PHAR file. Its name will be “test.phar”, the file “1.txt” will be included and it will contain a signature with SHA1 so PHP can detect if the file has been tampered.

$phar = new Phar(__DIR__ . "/test.phar");
$phar->addFile(__DIR__ . '/1.txt', '1.txt');
$phar->setStub(file_get_contents(__DIR__ . '/stub.php'));

Pretty simple, right? But keep in mind that for complex PHAR files it’s recommended to use a tool like Box. Complex projects like Composer have their own compiler to generate PHAR files.


Internally, PHAR files need a container to package all the files and some extra information. There are three different types of containers: zip files, tar files (compressed with gzip or bzip2) and PHAR “native” file. Regardless of the container, every PHAR file contain four sections:

Structure of the PHAR format

Structure of the PHAR format

If we see the file using an hexadecimal viewer, it’s easy to differentiate between the four sections:

Hexadecimal dump of a simple PHAR file

Hexadecimal dump of a simple PHAR file

More info

Photo: Cockpit Box, by Pascal

July 30 / 2015
Author Raul
Category PHP
Comments No Comments
Tags ,

Upcoming Conferences

Linters for PHP projects

Today’s projects are built up from dozens of different components, configuration files, third-party libraries, tests, build scripts, etc. And even if you have the greatest test suite, bad things can happen sometimes. It’s important to catch bugs as early as possible, and syntax validators can be a great (and easy) addition to your continuous integration system. You would be surprised at how many problems are caused by syntax errors. At ServerGrove, we see these kind of problems with our clients almost every day.


PHP code

The PHP binary provides a way to check the syntax of a given PHP file, by using the “-l” option:

$ php -l script.php

Wildcards can also be used to check more than one file. And to check all PHP files in a project, the following command can be used:

$ find . -type f -name "*.php" -exec php -l {} \;

If there are too many files and the process is slow, you may want it to execute it in parallel. For that, create a simple shell script that does the actual lint and then modify the “find” command:

php -l $1
$ find . -type f -name "*.php" | parallel -j4 ./ {}

Twig templates

When used with Symfony, the framework has a command to check one or more Twig templates:

$ php app/console twig:lint template.html.twig

All Twig extensions are taken into account, so custom functions, filters or tags are taken into account to validate the input template.

When using Twig without Symfony, there is no a direct way to validate a template. You can build your own linter or use asm89/twig-lint.


Composer provides a command to validate “composer.json” files in order to find both syntax errors and common issues.

$ composer validate composer.json

XML files

It is common to use XML files for configuration, translations or service definitions. xmllint is a command-line tool that checks that XML are well-formed and valid for a given DTD or XML Schema.

For example, you can check that an XML file is well formed with the following command:

$ xmllint --schema src/ServerGrove/DemoBundle/Resources/config/services.xml

Normally, tags and attributes that you can use in XML files are defined in a DTD or XML Schema. For example, when using XLIFF files for translations, you can both check that are well formed and valid:

$ xmllint --schema --noout src/ServerGrove/DemoBundle/Resources/translations/

There are schemas for many file types:

  • Doctrine mapping:
  • Symfony DIC services:
  • Symfony routing:
  • Symfony validator constraint mapping:
  • PHPUnit configuration:

Bash scripts

If you use bash scripts to automatize tasks, the “bash” command contains an option to check its syntax without executing the script:

$ bash -n

JSON files

JSON files are sometimes used for configuration and dependency management. While there are several tools that you can use, we created a simple Melody script that makes use of Seldaek/jsonlint to check JSON files:

$ melody run bower.json

YAML files

JSON files are widely used for configuration purposes as they are easier to write for a human being. When using Symfony, there is a “yaml:lint” command since 2.5. Without Symfony, you can build your own linter or use the Melody script we did for you:

$ melody run parameters.yml

Are you missing any other file type? Let us know!

Photo: “Syntax Error – Folded Up Beyond All Recognition”, by “Simon Pow”

June 02 / 2015
Author Raul
Category PHP, Symfony, Tutorials
Comments 2 Comments

Upcoming Conferences