En marge de la vulnérabilité sur bash (et de la connerie d'utiliser du cgi en 2014 + avoir un user www-data dont le shell est capable de se logguer...), il y a celle de Xen.

Cette faille n'a pas encore été révélée publiquement. Il faudra attendre le 1er octobre pour qu'elle le soit. C'est pour laisser le temps à des acteurs comme amazon oracle citrix rackspace etc.. de patcher. voir pre-disclosure list complète: http://www.xenproject.org/security-policy.html

Il y a fort à parier qu'il s'agit là d'une très grosse faille que amazon ne souhaite pas laisser être exploitée. Ils ont donc pris la décision de patcher tous leurs hyperviseurs avant le 'disclosure'.

Les conséquences pour les clients, dont l'entreprise pour laquelle je bosse, sont désastreuses ; car il s'agit de redémarrer - sous 3 jours! - un nombre conséquents de serveurs. Même en redémarrant préventivement des vm, on est pas sur qu'elles arrivent sur un hyperviseur qui est patché ; et donc elles redémarreront suivant la maintenance qu'aura prévu Amazon (ce week-end pour ma boite)... Bref, grosse galère, surtout pour les serveurs dont les données sont sur des stockages éphémères..

Enfin pour ce qui est de la faculté pour amazon de faire de la migration live, je rejoins ce commentaire:
"""
I would be surprised if Amazon didn't have high availability and live migration in the background, allowing them to reboot individual hypervisor hosts. You would still be stuck in your pool, but then if a host dies/needs patching it doesn't affect the guest VMs.

My suspicion is that the patch requires updating paravirtualization drivers (xen tools), which run on the VM itself and thus might require a reboot to update.
"""