Meltdown and Spectre bugs should help improve IT Security

Yes, I want to be positive and look at a bright future. Everybody is now talking about the Meltdown and Spectre bugs (here the official site). I think that these Hardware bugs at the end will help improve the security of our IT systems. But we should not underestimate the pain that they could cause, even if it is too early to say this for certain since patches and countermeasures could be found for all systems and CPUs or, at the opposite, there could appear unexpected exploits.

The central issue is that IT and IT Security in particular, depend crucially on the correctness of the behaviour of the Hardware, first of all of the CPUs. If the foundation of the IT pillar is weak, sooner or later something will break. Let’s then hope that the Meltdown and Spectre bugs will help design more secure IT Hardware and, in the long run, improve IT Security as a whole.

Hardware Vulnerabilities (Again), Cloud and Mobile Security

Have a very Happy New Year!

… and to start 2017 on a great note, I write again about Hardware Vulnerabilities with comments on Cloud and Mobile Security.

The opportunity for this blog entry has been provided to me by the talk “What could possibly go wrong with <insert x86 instruction here>? Side effects include side-channel attacks and bypassing kernel ASLR” by Clémentine Maurice and Moritz Lipp at Chaos Computer Club 2016 which I suggest to watch (it lasts 50 minutes and it is not really technical despite its title).

A super-short summary of the talk is that it is possible to mount very effective side- (in particular time-) channel attacks on practically any modern Operating System which allow to extrafiliate data, open communication channel and spy on activities like keyboards inputs. All of this using only lecit commands and OS facilities, but in some innovative ways.

The reason for which these attacks are possibile is that the hardware does not prevent them, actually some hardware features, added to improve performances, make these attacks easier or even possible (see also my previous post on Hardware Vulnerabilities about this). So from the Security point of view these Hardware features should be considered as Vulnerabilities.

What is it possible to do with these techniques? Considering Cloud, it is possible to monitor the activities of another Virtual Machine running on the same hardware, extract secrect cryptography keys (but this depends on how the algorithm and protocols are implemented), establish hidden communication channels etc.

Similarly for Mobile, it is possible to have a totally lecit App to monitor the keyboard activity, or 2 Apps to establish a hidden communication so that one reads some data and the other sends it to a remote destination, all without violating any security rule (actually each one having very limited privilegies and restricted setups).

Morevoer it seeems easy to embed this kind of attacks in lecit applications and current anti-virus seem to lack the capabilities needed to intercept them. Indeed the activites performed to implement these attacks look almost identical to the ones performed by any program and it seems that only a particular performance monitoring could discover them.


Implementing Cryptography right is hard

The security researcher Gal Beniamini has just published here the results of his investigation on the security of Android’s Full Disk Encrytion and found a way to get around it on smartphones and tablets based on the Qualcomm Snapdragon chipset.

The cryptography is ok but some a priori minor implementation details give the possibility to resourceful attackers (like state / nation agencies or well funded organized crime groups) of extracting the secret keys which should be protected in hardware. The knowledge of these keys would allow to decrypt the data in the file systems, the very issue which has been at the basis of the famous Apple vs. FBI case a few months ago.

Software patches have been released by Google and Qualcomm but, as usual with smartphones and tablets, it is not clear how many afflicted devices have received the update or will ever receive it.

In a few words, the problem lies in the interface between the Qualcomm’s hardware module, called the KeyMaster module, which generates, manages and protects the secret keys and the Android Operating System that needs to indirectly access the keys in this case to encrypt and decrypt the file-system. Some KeyMaster’s functions used by Android can be abused to make them reveal the secret keys.

This is another case which proves how it is difficult to implement cryptography right.

On Hardware Backdoors

Since at least the ’70s, the time of Multics (see eg. this old document on the vulnerability analysis of Multics security), the Orange Books, Military IT security etc., the role of hardware in IT security has been discussed, evaluated and implemented.

In the last years the discussion has risen again in particular about the possibility of hardware backdoors and malicious hardware. For example, since the publication of the Snowden documents there have been rumors about possible hardware backdoors in Intel, AMD and Cisco products.

A few days ago at the 2016 IEEE Symposium on Security and Privacy has been presented this paper (see eg. also here for a summary) describing how to implement a Hardware Backdoor called Analog Malicious Hardware which, as of today, seems practically impossible to detect.  The researchers were able to add a tiny circuit composed by a capacitor and a few transistors wrapped up in a single gate, out of the millions or billions in a modern chip, which acts as the hardware Trojan horse.

How difficult could it be to add a single, almost undetectable gate to the blue prints of a chip at the chip factory? How can be verified that similar gates are not present on a chip?

PS. 10 years ago I gave a couple of seminars in Italian about some aspects of history of IT security and I looked into some issues of how hardware must support the security features of Operating Systems; if interested some slides and a paper (in Italian) can be found here and here.

On a Kernel Backdoor and IT Security

It just became public that a custom built Linux kernel for embedded devices has been shipped and installed in production with a root debug backdoor open to anyone, see here for the announcement and for example here for some more details.

Besides the gravity of this particular incident and the difficulty of remediating it (I expect that many devices shipped with this kernel will never be updated) a couple of considerations come to my mind:

  • first of all the need for IT Security Awareness and Education starting from everybody working in IT : anybody can make a mistake or even a blunder, but there should be safety nets proportional to the risks and IT professional should always be aware of the “security” consequences of what they do;
  • the process of “bringing into production” IT products (aka Change Management) should be improved: as of today most of the time the really important test of an IT product is the final User Acceptance Test, which means that it is only important that the features requested by the final users work as expected. But this is not enough, and it is not like this in many other industries, think for example of televisions, refrigerators, cars etc. they all need to pass safety tests and be labelled accordingly otherwise they cannot be sold on the market. Why is it not like this also for IT products? As of today it is difficult to think of security standards, tests and labels common to all IT products, but it should be possible to agree on and adopt some common IT security baseline.

Statistiche sulle Vulnerabilità

Secunia ha rilasciato il suo Vulnerability Review 2013 (qui c’è un breve riassunto) da cui risulta che la grande maggioranza delle vulnerabilità che hanno afflitto i sistemi Microsoft nel 2012 hanno avuto origine in applicazioni di terze parti quali flash, acrobat, java ecc.

E’ probabile che i numeri citati da Secunia siano corretti, ma la cosa importante è quale conclusione se ne trae. E’ ovvio che la presenza di vulnerabilità in qualunque applicazione è una mancanza, ma quello che personalmente mi preoccupa di più è che un sistema operativo, che per definizione ha come principale scopo quello di gestire le risorse hardware e software, quindi anche le applicazioni, possa essere sovvertito a causa non di una propria vulnerabilità interna ma di una vulnerabilità di una applicazione.

Ridisegnare i Sistemi Operativi per una Nuova Sicurezza

Ho appena pubblicato sul mio sito un breve articolo intitolato “Ridisegnare i Sistemi Operativi per una Nuova Sicurezza” sulla presunta necessità di ripensare i fondamenti della sicurezza dei Sistemi Operativi per poter soddisfare le nuove richieste di funzionalità di sicurezza necessarie in ambito Cloud e Mobile. L’articolo può essere scaricato da

Computer Security from bottom-up with a “clean slate”

This is my first post in my new blog and I would like to start with this interview to Robert Watson (Cambridge University UK) on IEEE Spectrum which I found interesting. The main points in my opinion are:

The role of operating system security has shifted from protecting multiple users from each other toward protecting a single…user from untrustworthy applications.…Embedded devices, mobile phones, and tablets are a point of confluence: The interests of many different parties…must be mediated with the help of operating systems that were designed for another place and time.


in historic systems, large multiuser computer systems, you know, we had these central servers or central mainframes, lots of end users on individual terminals. The role of the OS was to help separate these users from each other, to prevent accidents, perhaps to control the flow of information. You didn’t want trade secrets leaking from, perhaps, one account on a system to another one.


So the observation we make on these new end-user systems like phones is that what we’re trying to control is very different. The phone is a place where lots of different applications meet. […]  And on phones today, we encourage users to download things all the time. So what has changed now? Well, we’ve deployed something called sandboxing inside of these phones so that every application you download runs inside its own sandbox. And that is a very different use of security. And it is provided by the operating system, so it’s still a function of the operating system.

The main point is that we should re-think security from bottom-up starting with a new paradigm for the OS primitives, the main scenario which we should add to the historical one is the single-user multiple-untrusted applications, whereas all our OSes have been designed for the multiple-users multiple-trusted applications scenario.

This also reminds me of Qubes and Bromium which are efforts to obtain a larger control on applications by using microkernels and Virtual Machines as underlying OS.

An article by Watson will be published in the February 2013 issue of Communications of the ACM.