¿El error informático más grave de la historia?

26 mayo, 2014

Algunos sistemas informáticos se denominan críticos (safety-critical en inglés) por su relevancia: un fallo en uno de estos sistemas puede tener consecuencias catastróficas, ya sea en pérdida de vidas humanas, daños económicos u otros tipos de pérdidas irreparables. Normalmente, este tipo de sistemas suelen encontrarse en el sector médico, aeroespacial (cohetes, satélites, transbordadores, sondas, …), militar, financiero, energético o de las comunicaciones.

l pantallazo azul: quizás no el más grave, pero uno de los errores más conocidos.
El pantallazo azul: quizás no el error más grave de la informática, pero sí uno de los mensajes de error más conocidos (al menos, por los usuarios de Windows).

Los sistemas críticos requieren de un proceso de desarrollo totalmente orientado a garantizar la calidad del producto final: aquí no valen improvisaciones ni cambios en las especificaciones en el último minuto. Todo tiene que ser probado y verificado para que no haya posibilidad de error. El resultado tiene un nivel de calidad muy superior al que estamos acostumbrados a nivel de usuario pero, como es de suponer, a un coste mucho más elevado. Y obviamente, no siempre se pueden construir usando las mismas herramientas que en una aplicación de usuario. No es casual que los abogados de Sun Microsystems incluyeran este párrafo en los acuerdos de usuario final (EULA) relacionados con la tecnología Java:

La tecnología Java no es tolerante a fallos y no está diseñada, fabricada o prevista para su uso o reventa como mecanismo de control reto de equipamiento en condiciones peligrosas que requiera tolerancia a fallos, como en la gestión de una instalación nuclear, la navegación de aviones o los sistemas de comunicación, tráfico aéreo, mecanismos de soporte vital o sistemas de armamento, donde el fallo de la tecnología Java pudiera conducir directamente a la muerte, daños personales o daño físico o ambiental severo.

Sin embargo, a pesar de todas estas precauciones, en algunas ocasiones los accidentes ocurren. Y no estamos hablando del impreciso “error informático”* que sirve de chivo expiatorio para diluir la responsabilidad ante una metedura de pata colosal. En algunos accidentes, el análisis post-mortem ha permitido identificar la raíz del problema y la causa es un error de software o de hardware. A continuación hablamos de algunas de estas tragedias:

– Entre 1985 y 1987, un dispositivo de radioterapia denominado Therac-25 suministró una sobredosis de radiación a 6 pacientes,100 veces superior a la que requería su tratamiento. Errores similares también se producían en versiones previas del dispositivo (Therac-20) pero en ese caso existían controles de seguridad hardware que impedían que se manifestara el problema.

– El año 1991, durante la primera Guerra del Golfo, un error de redondeo hizo que un sistema de defensa anti-misiles Patriot instalado en Arabia Saudita no detectara un misil atacante que mató a 28 personas.

– El año 1994, un profesor de matemáticas detectó un error en las operaciones de división de números de punto flotante en el procesador Intel Pentium. A parte de un daño considerable a su imagen, la substitución de los procesadores defectuosos tuvo un coste de 475 millones de dólares.

– En 1995, el cohete Arianne 5 de la Agencia Espacial Europea sufrió una explosión 40 segundos después del despegue. El error pudo atribuirse a un fallo en un sistema de control inercial, donde un número de punto flotante de 64 bits se convirtió a un entero de 16 bits, causando una excepción por “overflow”. 7 billones de dólares y 10 años de trabajo destruidos en unos segundos.

– El año 1999, el satélite Mars Climate Orbiter se estrelló contra la superficie de Marte cuando intentaba entrar en órbita, con un coste de 655 millones de dólares. La causa fue un problema en el intercambio de información entre dos subsistemas software del satélite, que estaban utilizando unidades de medida diferentes para representar las distancias (kilómetros y millas).

– En el año 2012, la firma de inversión Knight Capital Group perdió 440 millones de dólares  (10 millones por minuto) por un error en su software de inversiones financieras, que realizó transacciones sin controlar que estaban generando pérdidas en lugar de beneficios. Es lo que pasa cuando tu código de prueba acaba en el entorno de producción.

Todos estos errores han tenido consecuencias muy severas. Pero puede que aún haya otro “error» informático, en este caso de diseño, con consecuencias mucho más profundas. Se trata de la decisión de codificar los strings como una cadena de caracteres acabados en “null” (null-terminated string en inglés) en el lenguaje C. Se prefirió dicha estrategia en lugar de utilizar las cadenas «tipo Pascal”, donde las primeras posiciones indican explícitamente el  número de caracteres que contiene la cadena. A pesar de sus grandes ventajas, esta decisión ha conllevado una gran cantidad de problemas no previstos en su día: bugs, ataques de buffer overflow, … Haciendo números, quizás la suma de todos estos problemas ha tenido (y tendrá) un coste superior a todas las catástrofes mencionadas.

Por último, aunque no sea un sistema crítico ni siquiera un error (más bien un síntoma de otros errores), hay un problema que merece una mención especial: el aborrecido pantallazo azul (Blue Screen of Death o BSOD, en inglés). Esta pantalla aparece ante un fallo irrecuperable del sistema en algunas versiones de Windows… ¡hasta en Windows 8!. La frecuencia de su aparición la han elevado a la categoría de hito cultural con su propia entrada en Wikipedia.

* Igualito que el típico “error humano» cuando el causante ha fallecido durante el accidente: es fascinante lo rápido que se le atribuye la responsabilidad a algo o alguien que no puede protestar.

EDIT 1: Aunque la lista no pretende ser completa, algunos de vosotros habéis echado en falta el incidente Therac-25 por el hecho de haber  víctimas. Lo hemos añadido a la lista, gracias a todos los que nos habéis dado el apunte.

EDIT 2: Manolo Palao me ha enviado un interesante artículo relacionado con esta entrada. El artículo, titulado «Presunción de inocencia» y publicado en Novática, se centra en la facilidad con la que atribuimos la responsabilidad de un fallo a los sistemas informáticos. Os dejo el enlace por si es de vuestro interés.

(Visited 249 times, 1 visits today)
Autor / Autora
Robert Clarisó Viladrosa
Comentarios
Manolo Palao26 mayo, 2014 a las 1:17 pm

Muy interesante, enhorabuena.
Opino que todo error es humano, y son los errores humanos los que pueden ocasionar fallos en los sistemas.
Un cordial saludo
🙂

Responder
J.M. Martinez27 mayo, 2014 a las 8:34 am

Y el error de programacion en el protocolo SSL/TLS que se conocio hace pocos meses y afecto segun dicen a 600 webs de las 10000 webs que mas trafico generan en Internet, y a miles de webs más, ¿Ese no es un error importante y grave? Tanto por su dimension como por su importancia.

Responder
    robert27 mayo, 2014 a las 5:05 pm

    Hola José Maria,

    Gracias por tu comentario.

    La lista de incidentes no pretendía ser completa. Como bien dices, el bug Heartbleed ha tenido (y tendrá) consecuencias muy importantes para la seguridad de Internet y bien merecería un lugar en esta lista. Sin embargo, este bug tan reciente que aún no se han cuantificado los daños que ha producido, y no sé si en algún momento será posible echar la vista atrás y dar una cifra.

    Un saludo,

    Robert

    Responder
Miguel Angel Nicolao30 mayo, 2014 a las 12:40 pm

Buenas,

Ilustrativo. Me queda la curiosidad de saber algo sobre las consecuencias finales que tuvo el error, más allá de «La justicia ha caído con todo su peso sobre el becario responsable del fallo».

Son cifras tan mareantes que intuyo habrán llevado a la parálisis … ¿cómo recupero mi inversión de 7 billones? … buff, tiro la toalla.

En todo caso, interesante.

Saludos,
MAN

Responder
Luis Fernández20 septiembre, 2014 a las 7:27 pm

Lo más sencillo para errores: la archiconocida lista exhaustiva de Peter Neumann desde finales de los 80

http://www.csl.sri.com/users/neumann/illustrative.html

Responder
jose29 agosto, 2017 a las 4:58 pm

Apple también cometió un gravísimo (que casi roza el ridículo) error en su implementación de SecureTransport, una capa del sistema de gestión de TLS/SSL como ya han contado nuestros compañeros en Seguridad Apple.
Como podeis ver nadie se escapa…

Responder
Deja un comentario