It's already been a couple of weeks since we introduced you to our revamped console. And as we wrote at that time, we are not stopping there. We are always working on new stuff to make your life easier.

Today we introduce you to our new filtering system built with love by Arnaud and Hubert. As you might have seen already we have merged apps and add-ons. So in the same list you end up having apps that uses different runtime and build tools as well as various add-ons. We are now allowing you to filter this list based on these specifics.

If you type is:redis in the filter field you will only see your Redis add-ons. If you type is:node you will only see nodejs applications. It's that simple. And of course you can combine these filters or use them with the usual name search:

• is:java is:jar
• is:java is:sbt
• is:java ACME
• is:java prod

Now you might be wondering, how does this work? What can I use as filter? For add-ons we use their slug. Here's the list:

mysql
postgresql
redis
cellar
fs-bucket
config-provider
mongodb

For applications it's more subtle. You can use their type or their variant slug. What is a variant you ask? Well it's something we use internally to put different sort of automation secret sauce on our VM images. Take for instance the node image type. It has two variants. One is node which is pretty much the default behavior for node.js applications. The other is meteor, used for Meteor.js applications, which installs Meteor and runs specific build and run tasks. If you look at the java type you will see we have a number of variants representing the different ways to deploy JVM code with different build tools.

Type            Variant Name            Variant Slug
--------------------------------------------------------
python          Python                  python
haskell         Haskell                 haskell
php             PHP                     php
php             Static                  static-apache
ruby            Ruby                    ruby
python-gunicorn Python Gunicorn         python-gunicorn
go              Go                      go
java            Java + Play! 1          play1
java            Java or Scala + Play! 2 play2
java            Java or Groovy + Gradle gradle
java            Java + JAR              jar
java            Java + Maven            maven
java            Scala + SBT             sbt
java            Java + WAR              war
node            Meteor.js               meteor
node            Node                    node
docker          Docker                  docker
rust            Rust                    rust
erlang          Elixir                  elixir

For future releases, we're also thinking about filters like is:running, is:stopped, sort:status, sort:type. We might also add Tags which are already available in our API. If you would like to filter this list based on other characteristic please let us know in the comments below :)

First, the new status icons

A new filter field

Then, the new app overview

• We are now displaying current status, with some additional details on it (git commit, etc.)
• The runtime of the app is now clearly displayed with an icon

• The instances list (reusing the new status icon) is visually optimized
• The scalability settings (read-only) are now shown
• And we've added info about the two last deployments

Oooh, I log you so 🎶

Let's wrap-up

What about some moar

• Global create button on top (new apps/addons panel)
• Variant/runtime icon next to the app (new apps/addons panel)
• Refreshed icons/shape for app creation
• Refreshed icons/shape for addon creation

A future moving forward

Yesterday two issues affecting CPUs have been released to the public.

TL;DR: the attacks are named Meltdown and Spectre. They allow reading the memory of the OS or of other processes, to steal secrets or get information for other exploits. A part of the solution can greatly affect performance of running code. In particular, this attack allows to easily cross container boundaries, and in some cases (not our case) even VM boundaries.

In addition to servers, consumer machines are affected, especially through browsers, so you should definitely update your operating system as well as your browsers.

What it means for Clever Cloud users

Your applications will be (or already have been) automatically restarted (just like any other maintenance deployments). The addons will be patched and restarted in place in the following hours. This will generate limited downtime on addons (usually around a minute, depending on the addon start up time).

In addition to restarting virtual machines, we will also need to restart physical machines, as the attacks theoretically allows VM boundaries crossing. This attack is not usable (yet?) on Clever Cloud due to our virtualization choices and our OS hardening, but we will deploy patches preemptively. Physical machines updates will take place in the following days and will not impact applications. We are currently working on finding the best solution for addons, but it will definitely incur additional downtime for addons.

The patches, while mitigating the issues, also come with performance regressions. It heavily depends on the workload as well as the exact CPU model. The CPUs we use are among the less affected by the performance issues, but a slowdown of at least 5% is to be expected.

Technical details

The Meltdown attack and the Spectre categories of attack are related to a performance feature of modern processors: branch prediction and speculative execution. Meltdown shows that when an instruction can cause a trap, like the privilege check for user → kernel access), the processor will perform speculative execution: it starts executing the code in case there’s no trap, but rollbacks if there was a trap. This attack happens at the boundary between user code and kernel. Before the processor has completely checked that we have the authorization to run privileged code, it starts executing it. When it turns out we were not authorized, it rolls back the results of that code, but not completely, it can leave some data in the cache. Combined with a technique called “cache timing attack”, it is then possible to guess the content of the data that was loaded in cache, bit by bit. Branch prediction has a related behaviour: when encountering a branch (example: an if/else expression), the processor will start executing one of the branches before it calculates the condition, to avoid waiting too much. It guesses which side of the condition is most likely thanks to its branch predictor. Spectre uses branch prediction to cause speculative execution to read out of a buffer’s bounds (among other consequences) in the kernel or another process, then guess the results from the cache.

The Meltdown attack is specific to Intel processors, it allows reading from the OS’s memory. There are patches available (the kPTI feature, also named KAISER https://lkml.org/lkml/2017/12/4/709). Those patches have a great impact on syscall performance (https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1), with programs running 5% to 30% slower depending on the workload. The Intel Haswell processors with the PCID (Process Context Identifiers) feature get the lowest performance hit (5%). We use those processors on Clever Cloud.

Spectre affects processors from Intel, AMD and ARM, it allows reading from the memory of other processes. It looks more like a new attack category, for which we will have to fix the issue individually in each affected software. The only global solution for Spectre is a radical change in processor architecture, and this is unlikely to happen soon. We will follow closely any new related vulnerability and promptly patch our infrastructure.

For further information

• Papers and explanations about Meltdown and Spectre: https://spectreattack.com/
• Proofs of concept from Google’s Project Zero team: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html
• French twitter thread explaining the attacks: https://twitter.com/fenarinarsa/status/948697105996156928
• English twitter thread explaining the attacks: https://twitter.com/nicoleperlroth/status/948684376249962496

This post has been written by @gcouprie and @clementd.
Spectre and meltdown logos of are designed by Natascha Eibl.

Hello from Team Clever Cloud!

We are quite excited to release a major new version of our Dashboard.
It includes a lot of bug fixes as well as a few additions. We've included automatics payments, a design refresh, an activity feed, a better log management. And a nice GitHub integration too.

So today we’re launching these new features, and I'd like to detail some of them:

GitHub

As you may have noticed, the GitHub button showed up recently on the Clever Cloud website and our login & signup forms.
This feature aims to simplify the login & signup process, but also to bring your GitHub repositories to Clever Cloud.

Automatic Payments

We used to base our billing on an account balance. While running, apps consume those credits. Since the begining, our users had to fill it with money manually. Now, a monthly amount can be automatically credited each month.

And to deal with scalable consumption, a threshold can be set up too. How does it work?

The billing threshold is initially set at a certain amount. Each time your account hits its threshold before the 30-day billing cycle has ended, your credit card is debited of the amount you've set up. See an example of recurring payment configuration below:

New UI

We teamed up with our most active users to create a better and clearer UI. We’re bringing to the dashboard simpler components and a more contrasted layout. You can even add an avatar for your profile or organization.

Activity Feed

The activity feed lets you track your apps' activity. When you open the activity tab, you will see each deploy and un-deploy event, with the following data:

• the date
• the type (deploy, undeploy)
• the reason of deploy (scaling, monitoring etc)
• and the commit ID

Better Logs Management

It's now easier to deal with logs: the start time of each instance is now displayed next to its id. This allows an easier bug tracking on deploy processes. It comes with a nicer and more helpful UI.

If you want to give this a whirl, head up to the console!

TL;DR:
We are disabling the support of SSLv3 in front of our platform the Friday, 24th October. CBC has already been disabled, mitigating the issue.
The secure web is not for Internet Explorer 6 anymore.

Say hello to the POODLE

POODLE is the codename of a new vulnerability disclosed by Google earlier this week. This vulnerability is not related to a specific software but to a whole protocol: SSLv3.

In few words this vulnerability gives the ability to an attacker to force a client downgrading the protocol version and the cipher suite used to talk to a secure server even if it is compatible with the most recent and secure one. After that the attacker will be able to perform a Padding Oracles attack to decipher the communication.

Does Clever Cloud POODLE?

The most efficient way to prevent this attack on the server-side is to remove the support of the SSL version 3. Removing this version will block some users like Internet Explorer 6 -which is not compatible with the newest protocol TLS- and very old devices.

Even if it is a good pretext to end the very long life of Internet Explorer 6, we prefer to check the impact on our customers before applying this update.

We are planning to disable the support of SSLv3 in front of our platform the Friday, 24th October. If you are a SSL customer and want to keep it, let us know by sending an email to our support.

Disabling SSLv3 is not the only way to mitigate this issue. After the downgrade dance, the most vulnerable cipher suite is CBC and… good news, this cipher was disabled widely on our platform earlier this year!

We are also deploying a patch to support a new cipher suite flag which tells to a server to reject any inappropriate fallback from a client.

Did you like [Heartbleed?]({{ site.basepath }}/features/2014/04/08/openssl-101g-update.html) Meet Shellshock — aka CVE-2014-6271 — a new bug discovered this week in the widely used Bash command line interpreter.

First things first

Are you safe at Clever Cloud?

Yes. Yesterday afternoon (September, the 24th), a patch was released by the bash developpers to address this issue.

A member of our team, Kevin Decherf, then submitted an updated bash package with this patch to the distribution we use: exherbo.

The patch was reviewed by several members of the core exherbo team and finally validated by me, both as member of Clever Cloud and of the exherbo core team at around 5PM (CEST).

The update was then propagated inside our Cloud platform and all the critical virtual machines got bash updated today.

What about you, <localhost>?

You really should care about this new vulnerability.

It can compromise especially Apache web servers using CGI scripts with Bash invocation, making your system vulnerable to remote-code injection. OpenSSH and some DHCP clients are affected as well on machines that use Bash.

Yesterday, a security patch of OpenSSL 1.0.1g was issued, fixing a pretty critical vulnerability (refered to as CVE-2014-0160).

Once issued, the Clever Cloud support team immediately updated our service with it.

Who's affected?

If you have SSL enabled on Clever Cloud, you have to read the following.

What to do?

Clever Cloud is not vulnerable to this security breach anymore, but we urge you to regenerate SSL keys and re-issue your certificate. Certificate regeneration is not a sufficient solution to protect you completely, you also have to regenerate a new SSL key. If you have any questions related to this security update for your apps hosted on Clever Cloud, feel free to send us an e-mail, our team will keep you informed of future developments.

Which versions of OpenSSL are vulnerable?

• OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
• OpenSSL 1.0.1g is NOT vulnerable
• OpenSSL 1.0.0 branch is NOT vulnerable
• OpenSSL 0.9.8 branch is NOT vulnerable