Problèmes de sécurité avec le logiciel

Preview:

DESCRIPTION

Problèmes de sécurité avec le logiciel. Novembre 2007. 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. - PowerPoint PPT Presentation

Citation preview

Problèmes de sécurité avec le logiciel

Novembre 2007

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).

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 ?

Exemple

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…

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 !

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.

Exemple

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.

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é.

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.

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 !!!

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.

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.

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.

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.

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 !

Leçons tirées

Même si cette routine fonctionnait avec Ariane 4, elle aurait du être testée dans les conditions d’accélération que pouvait occasionner Ariane 5.On aurait alors découvert cette erreur.

Comment se fait-il qu’un rapport d’erreur a été considéré comme des mesures valides ?

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

Exemple

Crash du réseau d’AT&T

Problème technique

Réinitialisation de 6 secondes

Bloquer nouveaux appels

B note que A ne traite plus d’appels

Crash du réseau d’AT&T

Recommence à traiter des

appels

1er appel traité

B se réinitialise suite au retour de

A

Crash du réseau d’AT&T

2e appel

Réinitialisation non terminée

Crash du réseau d’AT&T

2e appel

Le message de A perturbe le logiciel

B conclut que son processeur est viré « fou »

B arrête son processeur

Crash du réseau d’AT&T

Réinitialisation de 6 secondes

Bloquer nouveaux appels

Bloquer nouveaux appels

C note que B ne traite plus d’appels

A note que B ne traite plus d’appels

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

Crash du réseau d’AT&T

Recommence à traiter des

appels

2e appel traité

2e appel traité

Le message de B perturbe le logiciel

A conclut que son processeur est viré « fou »

A arrête son processeur

Le message de B perturbe le logiciel

C conclut que son processeur est viré « fou »

C arrête son processeur

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.

Black out du 14 août 2003

Nord-est des États-Unis + Ontario

Welcome to Toronto

Exemple

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.

Séquence des événements

12h15Des 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éseauUne ligne 230 kV hors service fausse les

données car le MISO SE assume qu’elle est en service.

Séquence des événements

13h31La centrale Eastlake en Ohio s’arrête.

Séquence des événements

14h02Dé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 .

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…

Séquence des événements

14h27Un 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.

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 !!!

Séquence des événements

14h41Le 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.

Séquence des événements

15h05: Un autre arbre entraîne la défaillance d’une ligne 345 kV à Parma.

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.

Séquence des événements

15h17Baisse de tension sur le réseau électrique

en Ohio. Les opérateurs ne font rien.

Séquence des événements

15h17Baisse de tension sur le réseau électrique

en Ohio. Les opérateurs ne font rien.

Séquence des événements

15h19Le 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…

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.

Séquence des événements

15h35Le téléphone sonne encore. On commence

enfin à comprendre que ça ne va pas.15h39

Perte d’une ligne de 138 kV en Ohio.

Séquence des événements

15h41:La ligne qui avait eu une défaillance vers

14h27 tombe définitivement.

Séquence des événements

Les effets des pannes cumulatives commencent à se faire sentir sur le réseau.

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.

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é.

Séquence des événements

16h09m02: Grosse oscillation de voltage. Le réseau de l’Ohio pompe 2 GW de puissance du Michigan.

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.

Séquence des événements

Séquence des événements

16h10m37: L’est et l’ouest du Michigan ne sont plus connectés ensemble.

Séquence des événements

16h10m38: Cleveland se détache du réseau (trop tard).

Séquence des événements

16h10m393.7 GW est sucé de l’est à partir de l’Ontario

vers le nord de l’Ohio et le sud du Michigan.

Séquence des événements

16h10m40: Inversion du flot de puissance. 2GW entre en Ontario. Et revient une demie seconde plus tard !!!

Séquence des événements

16h10m45: L’ouest de l’Ontario n’est plus branché à l’est. Arrêt d’une première centrale en Ontario.

Séquence des événements

16h10m46: Le réseau de l’état de New York se sépare de celui de la Nouvelle Angleterre.

Séquence des événements

16h11m57: Dernières lignes se déconnectent entre l’Ontario et le Michigan.

16h13: Fin de la cascade. Black out !256 centrales se sont déconnectées du réseau

pour se protéger. 85% après la déconnection des différents réseaux électriques.

Les américains blâmeront les canadiens!Mais c’est un problème logiciel en Ohio qui

est la source de ce gros bordel !

Les centrales qui sont tombées au combat !

Le logiciel avait été testé en simulation

Mais faut croire que cette situation n’avait pas été simulée !

Therac 25

Un traitement anti-cancer mortel !11 de ces machines installées au

Canada et aux États-Unis.

6 personnes ont été victime d’overdose de radiations.

Pire accident de l’histoire des accélérateurs appliqués aux traitements médicaux.

Exemple

Therac 25

Cette machine de 3e génération avait deux modes de fonctionnement:Mode rayon X;Mode électrons rapides.

Ce dernier mode est utilisé pour obtenir des doses profondes.

L’installation

La table tournante

Modes de fonctionnement

En mode électrons:Niveau d’énergie ajustable de 5 à 25 MeV.

Des aimants dispersent le faisceau d’électrons à un niveau sécuritaire.

En mode photon (ou rayon X):Niveau d’énergie de 25 MeV. Requiert la

présence d’un atténuateur pour disperser et rendre uniforme le faisceau de rayon X.

L’accident de Tyler (au Texas)

Treatment monitor task (Treat)

Utilise la variable Tphase pour savoir à quelle étape on est dans le traitement.Tphase sélectionne la routine à exécuter.

Tphase = 1:Datent : Data Entry;

Communique avec le Keyboard handler task;

Entrée de la prescription

Variable globale commune

Data Entry Complete Flag. Indique quand la prescription correcte est

entrée.

Si activé, ce bit indique à la routine Treat de passer de Tphase = 1 à Tphase = 3.

Quand tout se passe bien…

Variable globale commune

Par contre, n’assure pas que la prescription à été toute entrée !Si accidentellement l’opérateur retourne le

curseur sur la ligne de commande Data Entry Complete Flag devient vrai.

Quand le bug arrive !!!

Quand le bug arrive !!!

Ce qu’affiche l’interface

Quand le bug arrive !!!

Ce qu’affiche l’interface

Position tabletournante

Quand le bug arrive !!!

Ce qu’affiche l’interface

Position tabletournante

Ajustement du faisceau

Routine Datent

Transferts à des convertisseurs N/A

Routine Magnet

Prend 8 secondesà s’exécuter

Remis à 0 lors dela première

exécution !!!

Routine Magnet

Ce bout de coden’est plus exécuté !!!

C’est la course à la catastrophe

L’opérateur descend le curseur à la ligne de commande avant la fin de l’édition des paramètres. Data Entry Complete=true.

La routine Ptime s’est exécutée au moins une fois. Bending magnet flag=false.

C’est la course à la catastrophe

L’édition du mode et de l’énergie arrive trop tard.Car sorti de Datent et Tphase=3.

C’est la course à la catastrophe

L’ajustement est alors incorrect et non conforme avec ce qui est affiché sur l’interface homme machine.

Donc, pas la bonne dose et pas le bon mode.

Risque d’ « underdose » ou d’overdose !

Mais en plus(comme si c’était pas assez)

Le registre MEOS est sur 2 octets. La partie haute est utilisée par Datent pour ajuster les paramètres de fonctionnement.

La partie basse est utilisée par la routine Hand qui ajuste la table tournante et les collimateurs en fonction du mode et de l’énergie sélectionné.

Mais en plus(comme si c’était pas assez)

Donc, avec le bug précédent, si on change le mode/énergie, Hand fait les changements, mais pas Datent.

Et aucune détection de l’inconsistance des ajustements est fait, car il est connu qu’un logiciel ne fait pas d’erreur…

Mais en plus(comme si c’était pas assez)

Et si le mode par défaut dans Datent envoie 25 MeV (mode rayons-X – ou photons) alors que Hand est ajusté dans le mode électrons, le patient recevra une dose extrême de radiation.

Et ainsi

Et, ce ne sera pas le seul bug que l’on trouvera sur Therac 25

Et, ce ne sera pas le seul bug que l’on trouvera sur Therac 25

Et, ce ne sera pas le seul bug que l’on trouvera sur Therac 25

L’incident de Yakima (état de Washington)

C’est encore la course à la catastrophe

Registre Class3 à 8 bits.Routine Set Up Test appelée

continuellement tant que non complétée. Incrémentation de Class3 à chaque appel;

Mais: 255 + 1 = 256 0 sur 8 bits.Regardez le test fait dans Lmtchk.Vérification pas faite et…

Était-ce évitable ?

Bonne question.

Le problème majeur est de tester toutes les conditions possibles que le logiciel peut rencontrer.

Impossible parfois de découvrir les failles en simulation.

Voyons d’autres exemples…

Un risque de course (race hazard)

Bien connu en électronique.A la source des “glitches”.

A

B

C

Y

Un risque de course (race hazard)

Table de Karnaugh:

On ajoute une porte logique de plus:

0 0 0 1

0 1 1 1A

B

C

Y

0 0 0 1

0 1 1 1A

B

C

Y

Un risque de course (race hazard)

Problème réglé:

A

B

C

Y

Un risque de course (race hazard)

Malheureusement pas aussi simple au niveau software !

Recommended