SecurityInsider
Le blog des experts sécurité Wavestone

MELTDOWN & SPECTRE : attaques par canaux auxilliaires sur les processeurs



Le début d’année 2018 semble être une période difficile pour les constructeurs de processeurs puisque pas moins de 3 vulnérabilités critiques viennent d’être publiées à l’encontre des processeurs de différentes marques (Intel, ARM, AMD). Ces vulnérabilités concernent des attaques par canaux auxiliaires qui permettent entre autres de lire arbitrairement la mémoire du noyau depuis une application non privilégiée, voire la mémoire de l’hyperviseur (et par conséquent des autres machines virtuelles qu’il héberge). 

Suis-je affecté ?

C’est extrêmement probable.


Attaques par canaux auxiliaires?

Les attaques par canaux auxiliaires désignent un ensemble d’attaques qui ne ciblent pas un algorithme dans sa conception mais dans son implémentation. Plusieurs catégories d’attaques par canaux auxiliaires existent, dont :
  • Attaque temporelle
  • Attaque par consommation
  • Attaque par injection de fautes
  • etc.


MELTDOWN & SPECTRE

Les vulnérabilités MELTDOWN (CVE-2017-5754) et SPECTRE (CVE-2017-5715 et CVE-2017-5753) reposent sur une attaque temporelle ciblant les temps d’accès aux informations présentes dans le cache du processeur.
Plus précisément, au sein d’un système d’exploitation, les informations contenues en mémoire sont divisées en deux catégories :
  • Les informations relatives aux applications utilisateur, accessibles par le noyau et (sous certaines conditions) à ces mêmes applications ;
  • Les informations privilégiées, relatives au noyau, uniquement accessibles par le noyau.


Les tentatives d’accès aux portions relatives aux noyaux par une application utilisateur sont par conséquent systématiquement bloquées, et il n’est donc pas possible de récupérer la valeurs contenues à ces adresses mémoires … directement. 
Ces vulnérabilités reposent sur le fait que les processeurs vulnérables utilisent le principe d’exécution spéculative afin d’optimiser les performances de ce dernier. L’exécution spéculative  détermine en amont de l’exécution normale si les instructions à exécuter sont réellement nécessaires et comment elles pourraient être accélérées. Bien que rien ne soit réellement exécuté, des restes de cette analyse sont présents dans le cache du processeur, et peu conduire un utilisateur malveillant à extraire les informations contenues en mémoire noyau, sans pour autant y accéder directement.

Des whitepapers sont disponibles pour MELTDOWN et SPECTRE.

Quels impacts ?

La vulnérabilité MELTDOWN permet l’accès à l’ensemble de la mémoire du système d’exploitation par les applications utilisateur. Sous Windows, il serait donc possible de récupérer des informations sensibles, tels que les jetons d’accès de processus, qui peuvent par la suite permettre l’usurpation de privilèges. MELTDOWN ne cible que les processeurs Intel
La vulnérabilité SPECTRE permet d’accéder à la mémoire des autres applications du système et par conséquent à un ensemble d’informations liées à ces programmes : mots de passe, saisies utilisateur, etc. Cette vulnérabilité bas niveau peut être exploitée par des applications haut niveau, un PoC ayant été réalisé en JavaScript. La vulnérabilité cible les processeurs Intel, ARM et AMD.
Ces vulnérabilités sont également exploitables dans le cas de systèmes virtualisés (hyperviseurs et conteneurs), notamment dans le cas de Docker et de Xen PV.

Que faire ?

La vulnérabilité MELTDOWN peut être corrigée par application d’une mise à jour appelée « KTPI » ou « KAISER ». Cette mise à jour rend inaccessible la mémoire noyau pour les applications utilisateur, prévenant leur accès par la vulnérabilité. Cette mise à jour est d’ores et déjà disponible pour Linux (version 4.14.11), partiellement pour Mac OS 10.13.2 (puis complètement en version 10.13.3, et pour Windows (version 17035). Il est cependant important de noter que la mise à jour Windows ne peut être déployée si un logiciel antivirus non compatible est installé, la liste de ceux qui le sont étant disponible et tenue à jour ici.
La correction de la vulnérabilité SPECTRE nécessite en théorie un changement du matériel, ou a minima une mise à jour de son firmware. Cela n’étant pas réalisable de manière simple, des solutions palliatives sont aujourd’hui envisagées, au cas par cas. La vulnérabilité étant particulièrement critique dans le cas des navigateurs (puisqu’exploitable par du code JavaScript), des communiqués ont été rapidement publiés sur par Google et Mozilla ce sujet afin de proposer des solutions court terme.

Concrètement

La majorité du matériel grand public et de celui présent en entreprise est impactée par ces vulnérabilités. Il est donc recommandé de mettre dès que possible à jour les applicatifs et systèmes d’exploitation impactés par MELTDOWN, ainsi que de se renseigner sur les évolutions liées à la mitigation de la vulnérabilité SPECTRE.
Notamment, dans le cadre d’applications et d’infrastructures hébergées en SaaS/IaaS, il est conseillé de se rapprocher des fournisseurs de services d’hébergement pour connaître leur politique de mise à jour sur ce sujet et les dates de redémarrage des infrastructures d’hébergement. Certains communiqués sont déjà disponibles, par exemple Amazon AWS, Azure, OVH et Online.net.



Jean MARSAULT

4 commentaires:

  1. "MELTDOWN concerns only Intel processors". That's completely false, it affects absolutely all CPUs... and more (not just CPUs).
    Basically it is a serious forgotten flaw in the concept of "caches" that have allowed all computer components to considerably accelerate their performance by using different levels of "data locality" everywhere, allowing computing to process independantly and in data flows working in parallel. Caches are everywhere.
    The flaw is in how "caches" are traditionally used: they only use a very basic "LRU" policy for cache eviction. The "LRU" eviction policy IS THE REAL BUG.
    There's absolutely NO WAY to solve it by trying to limit the precision of timers. This was demonstrated: even the limitation of precision or its randomisation allows attackers to still perform a time-based attack with the arbitrary precision they want, with very modest or no cost (remember that attacks are performed by using huge armies of bots, running on systems that were harvested and already compromised, including by Meltdown attacks).

    There's only ONE way to solve the problem of Meltdown: isolate caches by "segregating" their use in separate pools (one separate pool per user or security domain). This means one separate cache per user, and NO attempt at all to reuse the cache used by another concurrent user, if you can prove that the two users are exactly the same.

    This has dramatic consequences, notably for all servers on the internet that can serve many (possibly millions) distinct users (or identities): each user needs his own separate cache, and this would require allocating to each user a separate store for the specific cache each user/identity needs. This will require dramatic increase of the total size of caches used by any online service, so that eahc user is warrantied to have a minimum performance without *ever* impacting the performance (or accelerate it) of concurrent users.

    Spectre is a minor issue compared to Meltdown: solving Meltdown would immediately solve Spectre as well.

    The principles of Meltdown are much wider than what it seems. For now the industry has focused only on internal caches of CPUs, but there are many other caches (just consider the webcaches implemented in front proxies of any webservice: it is targettable by Meldown attacks exactly the same way as for caches in CPUs, and with the huge acceleration of broadband speed on the Internet and dramatic reduction of response times, i.e. the measurable "ping roundtrip delay", Meltdown is usable now to attack ANY webservice to spy other users of the webservice (and spy also the maintainers of webservices as well, which almost everywhere are also depending on the same upstream connection used by other users, even if thery use correctly built secure and encrypted VPNs: there exists on the Internet absolutely no service that depends only on its own ressources, there's nowhere any warranty of performance with dedicated bandwidth and warrantied response time, every one depends on shared resources, including the Internet backbone).

    Meltdown is so serious that it can be used as well to attack the DNS system (built on a huge hierarchy of caches whose performance varies everywhere but is also clearly measurable, in a very precise way: these measurements have never been so precise: we can measure the DNS performance as precisely as nanoseconds, to rebuild completely the topology of the system and then infer exactly who uses it and when and even for which usage!)

    RépondreSupprimer
  2. The "Meltdown" bug is in fact the same bug as "LRU caches": an initial bad design where the "cache eviction policy" was completely forgotten by a simplistic strategy (which works very well for all legitimate uses, but also completely allows abuses, and there's no reliable way to distinguish legitimate and abusive uses, unless we give much stronger usage policies, and only allocate to each user a pretermined fixed amount of resources that he will use exclusively and nobody else).

    Such goal however contradicts the simple concept of the Internet which is entirely built by sharing available computing resources to an unlimited numebr of "users", instead of being built only with statically dedicated resources between known pairs of identifiable users (if we rebuilt the Internet this way, it would be completely closed, we would need to buy computing resources everywhere before attempting to connect to any webservice; advertizing on the internet would no longer work because ads could not be delivered; internet sites would no longer work, as they would not be financed at all.

    Meltdown is so serious (and finally so easy to exploit) that I am sure that this is already used by governmental spying agencies but as well by all kinds of "blackhats" trying to steal our data, without EVER needing to perform any "social engineering" and entering directly in contact with use. This form of spying can leave no trace at all (al lwe can detect for now is the trace of "scripts" that were transfered from one system to another (which is inspected) and that perform such attacks by time measurement, but these scripts do not need to be transfered to monitored systems: they can now be deployed directly on billions of harvested systems which are not monitored at all (think about the emergence of IoT devices: nobody knows what their SmartTV or SmartFridge, is running, there's not even any support to update their firmware. Most smartphones are no longer supported after a couple of years; but as there are also bugs in all softwares, they can still be targetted and exploited to install a bot that will accept to run Meltdown-based spying agents to perform attacks; those few users controlling these harvested devices also have the advantage that these devices do not even make any logging of their activity, because these devices have almost no local storage for logs, or these logs are very rapidly cleared, so an attacker can erase its own tracks by performing enough actions, lauched by other bots, that will force these logs to be exhausted and cleared automatically! So you'll never know who installed the bot and harvested the device, the information in the history of the device is almost immediately lost !)

    And to return collected data to the malicious spiers, spiers do not even need to use a directed link: they can deliver this data back to them use P2P protocols, directed to all other harvested bots createing a P2P network, and no possibility to isolate any P2P member as being the system used by the spier to be the final recipient of the data.

    Let's add as well that the whole Internet is itself built on a pure P2P architecture (notably for finding IP routes): we can never know the complete list of who is actually connected to the Internet, and who is listening data from the Internet, so nobody will be able to locate the final recipient for data collected by a "bot army".

    RépondreSupprimer
  3. Bot armies exist, they have never been so powerful as today, they are unstoppable because they constantly find new ressources to harvest. Meltdown itself allows a bot to harvest new computing ressources and then connect it to the P2P network of other bots, in a completely decentralized way, bots are even unable to detect if they are connected directly with the blackhat, they don't know if the data they deliver to other bots has reached its final destination (so the stolen data can travel indefinitely on the P2P network, without knowing precisely from where it came from or where it is going to).

    Let's focus on Meltdown precisely and what it means: it can really destroy all the trust we may give to the Internet, it is a strong threat now to our legal system (notably since now the law recognizes the numeric identities as equally powerful as traditional identities that were based on physical evidences): the worldwide economy depends on numeric identities (including the virtual currencies like Bitcoins!)

    We'll need to rebuild the Internet completely, but there will be needs to adjust laws: forcing providers to take technical measures, forcing users to use these systems (like two-factor authentification), forcing ISPs to offer a PKI certificate and allow their users to revoke and replace this certificate as often they want, and changing rules governing the insurances that repair damages: they will not longer reimburse the damages if BOTH the providers and their customers have not taken the technical measures, or refused to take them; if they were required to do that by law, the costs of insurances would dramatically explode so much that webservices would no longer be competitive because of the massive scale of frauds, notably like those permitted by Meltdown which can be easily exploited at no cost at all for spiers if they just start using "bot armies"!)

    So let's not minor the impact of Meltdown: it's not jsut a flaw in a specific cache of a specific branch of CPUs, because CPUs are not the only shared component. And in fact all the current resolutions trying to fix Meltdown in CPUs are also flawed: they still dont change the cache eviction policy, they needlessly attempt to reduce the measurability of variable response times, but responses times remain variable, ans still measurable very precisely, so precisely that collected time measurements is statistically discriminative and allows guessing data with extremely accurate certainty (at a rate over 99%, comparable to the predictability of all numeric technologies).

    As the internet is now becoming extremely fast and response time on the Internet is constantly decreasing (think about fiber access and 5G networks coming), Meltdown will change its scale of attacks: it will not just target very local systems (internal L1 or L2 caches of CPUs), it will attack all other caches (buses, network interfaces, routers, proxies and webcaches).

    RépondreSupprimer
  4. There are other ways to moderate the usability of Meltdown to perform time-based covert channel attacks:

    - we may want to use the technic of "segregation of pools" in caches (one dedicated pool per user, legitimate or not we never know), but it changes radically the openness of the internet because it would then be built on set of dedicated resources for each allowed pair of identities (this can only work if we can verify these identities, i.e. making sure that everyone is authenticated, including advertizers for delivering their content: we must know from where these ads are coming, but this also causes severe privacy problems)

    - another way is to build internet systems so that response times (whever positive or negative for any request) NEVER vary in time: this means that even if the system can return its response faster, it MUST delay it. This is possible if the sytem monitors its own performances to make sure that it always have enough available resources to reply to any one (legitimate or not). Some variability of respone time may still exist, but this variation should not be statsitically discriminative between positive and negative replies.

    RépondreSupprimer