Problèmes de sécurité avec le logiciel

1. Problèmes de sécurité avec le logiciel Novembre 2007

2. Sécurité informatique • L’utilisation de microcontrôleurs (ou DSP), comme tout autre équipements programmés, introduit un risque qu’il est difficile de quantifier. • Il est plus facile de faire une analyse de risque avec un système uniquement matériel (pas de logiciel).

3. Exemple Défaillance des missiles Patriot • 25 février 1991, guerre du Golfe, part I; • 28 morts suite à la non interception d’un missile Scud ! • Ou était le bogue ?

4. Défaillance des missiles Patriot • Horloge interne du système Patriot. • L’horloge interne additionnait à chaque 0.1 sec. 1/10. • 1/10 exige en base 2 un nombre infini de décimales. • 0.00011001100110011001100110011001100… • Donc, à chaque 10e de seconde, l’erreur est de : • 0.00000000000000000000000110011001100…

5. Défaillance des missiles Patriot • Correspond à 0.000000095 seconde ! • Semble négligeable, mais après 100 heures d’attente, cela devient: • 0.000000095×100×60×60×10=0.34 seconde • Vitesse d’un missile Scud = 1676 m/s. L’interception du missile est raté par ½ km !

6. Exemple Défaillance de la fusée Ariane 5 • 4 juin 1996; • Premier lancement; • Explosion de la fusée 40 secondes après le lancement; • Coût de recherche/développement de la fusée: • 7 milliards • Perte de 500 M$ au lancement.

7. Système instable • Une fusée est un système instable. • Tellement qu’un ordinateur performant est nécessaire pour permettre à la fusée de suivre sa trajectoire.

8. Système instable • La centrale inertielle mesure les vitesses et accélérations angulaires de la fusée. • L’ordinateur central a un algorithme de contrôle pour assurer le suivit de la trajectoire et la stabilité.

9. Système instable • Il commande l’orientation des tuyères de la fusée. • Par sa dynamique, la fusée réagit aux poussées et orientations des tuyères.

10. Système instable • L’histoire de l’astronautique montre que ça se passe généralement bien. • Du moins, si le software n’a pas de bug !!!

11. Où est le bug ? • La centrale inertielle travaille sur un nombre en virgule flottante de 64 bits. • Une routine fait la convertion ce nombre en un entier sur 16 bits. • Ça fonctionnait bien sur l’Ariane 4. • Donc, inutile de tester, réutilisons le même code. • Mais, l’Ariane 5 est une plus grosse fusée impliquant de plus grandes accélérations.

12. Où est le bug ? • Il s’est produit une erreur dans la routine, car 16 bits n’étaient pas suffisants. • Cette erreur a entrainé un arrêt de la centrale inertielle. • Heureusement, il y a une seconde centrale inertielle en backup !!! • Mais, elle utilise le même code. • Elle subit donc le même sort que la première.

13. Un malheur n’arrive jamais seul • Le hardware des deux centrales inertielles envoie un rapport d’erreur à l’ordinateur central. • Ce rapport est interprété, par l’ordinateur central, comme des données valides, bien qu’extrêmes. • Résultat, les tuyères sont subitement commandées à leur angle maximal.

14. Trop de contraintes • Le fuselage de la fusée a alors changé brusquement de direction et des contraintes indues se sont produites. • Il n’était pas conçu pour supporter ce niveau de contraintes. • Le fuselage s’est brisé et la fusée à explosée.

15. Leçons tirées • Toujours vérifier si les données reçues sont valides. • « Sanity check ». • Les concepteurs d’Ariane ont assumés que les erreurs ne peuvent provenir que du « hardware ». • Il peut y en avoir dans le logiciel aussi !

16. Leçons tirées • Mêmesicette routine fonctionnait avec Ariane 4, elleaurait du êtretestéedans les conditions d’accélérationquepouvaitoccasionnerAriane 5. • On auraitalorsdécouvertcetteerreur. • Comment se fait-ilqu’un rapport d’erreur a étéconsidérécomme des mesuresvalides ?

17. Exemple Crash du réseau d’AT&T • Le 15 janvier 1990, le réseau d’AT&T s’effondre totalement. • Un nouveau logiciel avait été installé à la mi-décembre dans la totalité de ses commutateurs 4ESS. • La défaillance d’un commutateur à New York va révéler une faille de ce logiciel. Source: http://www.phworld.org/history/attcrash.htm

18. Commutateur 4ESS Source image: http://farm3.staticflickr.com/2039/1814566041_01332ebc5e.jpg

19. Crash du réseau d’AT&T B note que A ne traite plus d’appels Problème technique Bloquer nouveaux appels Réinitialisation de 6 secondes

20. Crash du réseau d’AT&T B se réinitialise suite au retour de A Recommence à traiter des appels 1er appel traité

21. Crash du réseau d’AT&T Réinitialisation non terminée 2e appel

22. Crash du réseau d’AT&T Le message de A perturbe le logiciel B conclut que son processeur est viré « fou » 2e appel B arrête son processeur

23. Crash du réseau d’AT&T Bloquer nouveaux appels Réinitialisation de 6 secondes Bloquer nouveaux appels A note que B ne traite plus d’appels C note que B ne traite plus d’appels

24. Crash du réseau d’AT&T Recommence à traiter des appels 1er appel traité 1er appel traité A se réinitialise suite au retour de B C se réinitialise suite au retour de B

25. Crash du réseau d’AT&T Recommence à traiter des appels 2e appel traité 2e appel traité Le message de B perturbe le logiciel Le message de B perturbe le logiciel A conclut que son processeur est viré « fou » C conclut que son processeur est viré « fou » A arrête son processeur C arrête son processeur

26. Crash du réseau d’AT&T • Et le problème s’est répandu comme une trainée de poudre à l’ensemble du réseau. • Si le second appel était arrivé après la période d’initialisation du commutateur, tout aurait bien fonctionné. • Mais, la loi de Murphy s’applique ici.

27. Exemple Black out du 14 août 2003 • Nord-est des États-Unis + Ontario Welcome to Toronto

28. Black out du 14 août 2003 • Plus grand black out de l’histoire de l’Amérique du Nord. • Parmi les conséquences: • A affecté 50 millions de personnes. • Pertes financières de 10 G$. • Défaite du gouvernement ontarien à l’automne 2003.

29. Séquence des événements • 12h15 • Des données incorrectes rendent un système de diagnostic non-fonctionnel en Ohio. • L’estimateur d’état du MISO génère de mauvaises données. • Aide les opérateurs à gérer le réseau • Une ligne 230 kV hors service fausse les données car le MISO SE assume qu’elle est en service.

30. Séquence des événements • 13h31 • La centrale Eastlake en Ohio s’arrête.

31. Séquence des événements • 14h02 • Défaillance d’une ligne 345 kV à cause d’un arbre à Walton Hill en Ohio. • A ce point pas de problèmes si le soft suit. Mais la loi de Murphy va s’appliquer ici .

32. Séquence des événements • 14h14: • Une condition de course entre des portions de logiciel corrompt les données. • Cela aura de graves conséquences, car les opérateurs de la salle de contrôle du réseau électrique de l’Ohio ne recevront bientôt plus aucun signal d’alarme! • Ce problème surgit au pire moment…

33. Séquence des événements • 14h27 • Un second arbre entraîne la défaillance d’une autre ligne de 345 kV. • Les opérateurs ne voient rien sur leur écrans. • La ligne se réenclenche.

34. Séquence des événements • Grosse erreur des opérateurs: • À 14h32, un opérateur d’un autre réseau averti les opérateurs en Ohio qu’une ligne s’est déconnectée puis s’est rebranchée. • Ces derniers n’ont rien vu, leur système de gestion des alarmes est corrompu. • Ce premier signe d’un problème n’a pas été pris en compte !!!

35. Séquence des événements • 14h41 • Le serveur en charge des alarmes entre en « shutdown ». Mise en marche du système de secours (gestion des alarmes). • 14h54: • Défaillance de ce système. On tente de le redémarrer, mais en vain.

36. Séquence des événements • 15h05: Un autre arbre entraîne la défaillance d’une ligne 345 kV à Parma.

37. Séquence des événements • 15h08: • Redémarrage du serveur de gestion des alarmes. Les opérateurs pensent avoir un système opérationnel ! Ce n’est pas le cas. • La perte de la ligne de Parma n’étant pas signalée, ils ne peuvent la corriger.

38. Séquence des événements • 15h17 • Baisse de tension sur le réseau électrique en Ohio. Les opérateurs ne font rien.

39. Séquence des événements • 15h17 • Baisse de tension sur le réseau électrique en Ohio. Les opérateurs ne font rien.

40. Séquence des événements • 15h19 • Le téléphone sonne à nouveau. Un opérateur d’un réseau voisin annonce qu’une ligne est en probablement en défaillance (voir 15h05). Mais les opérateurs en Ohio indiquent que tout est normal. Sauf que leurs données sont fausses…

41. Séquence des événements • 15h32 • A cause des transferts de puissance une ligne de 345 kV entre en oscillation et touche un arbre. • 1200 MVA de puissance doit passer ailleurs.

42. Séquence des événements • 15h35 • Le téléphone sonne encore. On commence enfin à comprendre que ça ne va pas. • 15h39 • Perte d’une ligne de 138 kV en Ohio.

43. Séquence des événements • 15h41: • La ligne qui avait eu une défaillance vers 14h27 tombe définitivement.

44. Séquence des événements • Les effets des pannes cumulatives commencent à se faire sentir sur le réseau.

45. Séquence des événements • 15h41 et 15h46: Deux sectionneurs se déclenchent au nord de l’Ohio, le coupant du réseau voisin, en raison de la défaillance d’une ligne à 345 kV et de 15 lignes à 138 kV. • A ce moment, c'eut été la dernière chance de sauver le réseau en déconnectant la ville de Cleveland.

46. Séquence des événements • 16h06 : La tension sur le réseau de l’Ohio est très instable. Perte totale du contrôle du réseau. Une autre ligne de 345 kV tombe. • Le sort en est jeté.

47. Séquence des événements • 16h09m02: Grosse oscillation de voltage. Le réseau de l’Ohio pompe 2 GW de puissance du Michigan.

48. Séquence des événements • 16h10m34: Défaillance de plusieurs lignes au Michigan et en Ohio. Gros déficit de puissance. Grandes surtensions dans l’est entrainant la déconnection automatique de centrales électriques pour les protéger.

49. Séquence des événements

50. Séquence des événements • 16h10m37: L’est et l’ouest du Michigan ne sont plus connectés ensemble.