Hola a todos, sean bienvenidos a este nuevo artículo que espero les sea de su completo interés y agradezco de antemano sus visitas y apoyo a este espacio.
Cuando escuchamos la palabra "bug" en el contexto informático viene a nuestra mente "errores" en un software que provocan un mal funcionamiento del mismo o de la pc, y es correcto: un bug informático es un estado en el cual una aplicación (aunque también puede ocurrir por hardware defectuoso) no procesa correctamente la información desencadenando una serie de acciones indeseadas o inesperadas que provocan un resultado erróneo (fuente Wikipedia).
El primer bug informático registrado:
El 9 de septiembre de 1947, la física y matemática Grace Murray Hopper y otros informáticos trabajaban en la Universidad de Harvard en el Mark II, una de las primeras computadoras electromecánicas que servían para cálculos matemáticos al servicio de los militares norteamericanos. De pronto el equipo dejó de funcionar y al revisarlo se dan cuenta que un relé electromagnético tiene un problema, pero no es un problema cualquiera: un polilla ingresó en el equipo (quizás atraída por las luces del equipo, no lo se), se posó sobre el componente eléctrico y murió electrocutada causando un desperfecto al equipo.
Parece ser que Grace Hopper no creía que sus superiores fueran a creer la causa del fallo del equipo, así que junto a su reporte técnico del problema adjuntó al pobre insecto y escribió "Primer caso real de «bug» encontrado", parece ser que la palabra "bug" asociado a un fallo ya se había usado con anterioridad, pues Thomas Alva Edison lo utilizó en sus notas en 1872, igualmente en 1878 para referirse a defectos mecánicos o eléctricos y finalmente en 1889 refiriéndose a interferencias y mal funcionamiento en un fonógrafo. Aunque claro, no sabemos si esto tuvo algo que ver con algún "insecto" o bicho que por ahí anduvo haciendo de las suyas, sea como sea, Hopper documenta el primer caso donde un insecto si causó un desperfecto en un equipo.
Desde entonces "bug" (bicho, insecto) se usa como sinónimo de un problema inesperado que provoca un mal funcionamiento de un programa informático (donde suelen ser más comunes) o de un equipo electrónico que no está funcionando correctamente.
Primer "bug" informático registrado | cortesía de Wikipedia.
Grace Hopper:
Grace Murray Hopper (9 de diciembre de 1906 - 01 de enero de 1992) fue una científica de la computación y militar estadounidense con grado de contraalmirante. Aunque no vio acción en el campo de batalla durante la segunda guerra mundial (afortunadamente) si colaboró activamente con el esfuerzo bélico pues fue enviada a Harvard para trabajar en el proyecto de computación que dirigía el comandante Howard Aiken: la construcción de la Mark I, una computadora de gran tamaño creada para realizar cálculos complejos necesarios para operaciones militares como de la artillería balística.
Después de la guerra siguió trabajando para la marina norteamericana en el departamento de computación, es considerada una pionera en el desarrollo de los lenguajes de programación actuales pues hasta aquel entonces la única manera de programar una computadora era directamente en un lenguaje que esta entendiera (lenguaje máquina y posteriormente ensamblador), pero "¿y que tal si se pudiera programar en un lenguaje usando palabras en inglés, más cercanas al lenguaje natural?".
Pues esa es la idea tras el desarrollo del lenguaje COBOL (COmmon Business-Oriented Language, Lenguaje Común Orientado a Negocios) que permitía usar palabras más sencillas y que cualquiera con los suficientes conocimientos pudiera crear sus propios programas sin entender el funcionamiento de la máquina pues ya no tendría que lidiar con códigos técnicos para acceder al hardware y controlarlo desde el programa que estuviera escribiendo. El compilador de COBOL haría todo el trabajo por él, ¿genial no?.
Hasta el día de hoy COBOL sigue siendo usado (tiene unos 60 años en el mercado, siendo lanzado en 1959), no fue la única aportación de Hopper en este campo pues también participó en la creación de FLOW-MATIC (base para COBOL) y al desarrollo general de compiladores de lenguajes de programación que sentaron las bases para el desarrollo de compiladores actuales.
Se ganó el apodo de "la Abuela COBOL" por su aporte al desarrollo de este lenguaje de programación y a la longevidad de su uso, murió el 01 de enero de 1992 a la edad de 85 años.
Grace Hopper | cortesía de Wikipedia.
Errores informáticos célebres y sus consecuencias
Lamentablemente no todos los bugs informáticos han terminados en anécdotas como el caso del fallo temporal del Mark I, algunos han costado muchísimo dinero y vidas humanas en el proceso. Algunos de ellos son los siguientes:
Y2K:
El problema del año 2000 debido a un error en el cálculo correcto de la fecha pudo haber terminado en desastre mundial, pues todas las computadoras de aquel entonces solo usaban los dos últimos dígitos del año para realizar sus cálculos. Afortunadamente se solucionó a tiempo el problema y no hubo mayores incidentes, aún así se estima que costó 214, 000 millones de euros prevenir el problema al tener que actualizar los equipos de cómputo.
Conforme la informática fue avanzando muchas empresas comenzaron a automatizar sus acciones mediante el uso de software especializado, lo cual está muy bien, pero tampoco debemos confiar ciegamente en las mismas. Esto fue lo que le sucedió a Knight Capital, una empresa de compra y venta de acciones bancarias; este empresa utilizaba un programa llamado SMARS para comprar y vender acciones de manera automática.
En el año 2012 por errores de codificación del software este no realizó las acciones de compra y venta correctamente y para cuando se dieron cuenta del fallo la empresa ya había perdido 460 millones de dólares en un solo día, todo esto en 4 millones de operaciones equivocadas. Por si fuera poco la SEC (Securities and Exchange Commission), que regula el mercado de valores les impuso una multa de 12 millones de dólares, un muy duro golpe para la empresa.
Boeing es una empresa constructora de aviones comerciales además de tener contratos militares en el campo de la aviación, deseosa de mantenerse a la cabeza de la aviación comercial frente a los competidores introdujo un "novedoso" sistema de navegación automatizado en el avión Boeing 737 MAX.
El software MCAS (Sistema de Aumento de Características de Maniobra, en inglés, Manoeuvring Characteristics Augmentation System) consistía básicamente en tomar el control de la aeronave cuando se detectaban "acciones peligrosas" por parte del pilo, podemos resumirlo así: "Cuando MCAS detecta que el avión está en modo manual con los flaps arriba y con un ángulo de ataque elevado, ajusta el estabilizador horizontal para bajar el morro y que el piloto no suba demasiado rápido y produzca una caída en pérdida. Aunque el sistema MCAS podía causar picados no intencionados, no se mencionaba en los manuales de vuelo y entrenamiento, por lo que los pilotos lo desconocían" (fuente Wikipedia).
Al desconocer que el software estaba tomando el control cuando era necesario realizar alguna acción que "por error" el software negaba, los pilotos intentaban otra acción para retomar el control del avión, pero el software de nuevo tomaba el control pues "consideraba" que esa acción era peligrosa y de nuevo les arrebataba el control. Era como tener dos pilotas al mismo tiempo, cada uno dirigiendo la aeronave en dos direcciones diferentes al mismo tiempo, ¿el resultado?, dos aviones estrellados y 346 personas muertas, además de 18,400 millones de dólares en pérdidas materiales para Boeing en el año 2019 cuando fue implantado este software de navegación.
La Mars Climate Orbiter fue una sonda de la NASA lanzada desde Cabo Cañaveral el 11 de diciembre de 1998 y llegó a Marte el 23 de septiembre de 1999. El objetivo principal era estudiar las variables atmosféricas como complemento a las misiones Mars Global Surveyor y Mars Exploration Rover y obtener evidencias de cómo fue el pasado climático del planeta rojo.
Por un "error informático" de lo más pintoresco la sonda terminó destruida, ¿Qué sucedió?, los datos enviados a la sonda para el cálculo de operaciones se enviaban en "pies", pero internamente la nave hacía los cálculos en "metros", ¿porqué?, no se, pero así funcionaba y "al parecer" nadie se percató que esto podía ser peligroso, pues cualquier fracción del cálculo podía estar equivocada y así pasó.
En cada encendido de los motores se habría modificado la velocidad de la sonda de una forma no prevista y tras meses de vuelo el error de cálculo se había ido acumulando, al acercarse a Marte "el error de cálculo" durante la conversión de pies a metros y por arrastre de los valores mal calculados se acercó demasiado al planeta. 57 km de altura en lugar de los 140 km a 150 km previstos quedando destruida por la fricción con la atmósfera del planeta.
La Therac-25 fue una máquina de radioterapia producida por AECL para automatizar la dosificación de Rayos X a los pacientes, por un mal funcionamiento del software que lo controlaba la máquina suministraba dosis mayores a las recomendadas a los pacientes. La interfaz no detectaba correctamente algunos cambios introducidos por el operador provocando un desbordamiento de las variables que controlaban la dosis a enviar al paciente y la máquina simplemente suministraba la cantidad "seleccionada" (mal obviamente), lo que llevaba a dosis extremadamente altas.
Las consecuencias fueron al menos seis accidentes entre 1985 y 1987 en los que varios pacientes recibieron sobredosis de radiación. Tres de los pacientes murieron como consecuencia directa.
Ya en otros artículos hemos visto la necesidad de encriptar las comunicaciones http ya que en un principio no lo estaban, para ello se usa el software OpenSSL, que entre sus muchas prestaciones provee esta funcionalidad. ¿El problema?.
Para comprobar si un sitio web está funcionando o no podemos hacer un "ping", es decir, enviar un comando que lo único que va a hacer es pedirle al servidor que responda si está disponible o no, OpenSSL puede hacer eso, pero, "por un error informático" era posible decirle con cuantos bits debía responder a la petición. Osea, si yo mando 4 bits el servidor responde con 4 bits y hasta ahí todo bien, pero, "¿y que tal si envío un mensaje muy corto pero en la longitud del tamaño yo especifico uno sumamente largo?". Pues ahí vienen los problemas.
Como el tamaño no corresponde al mensaje enviado, el servidor no podría simplemente devolver el mismo mensaje enviado, necesita "completar" los datos faltantes y "¿de donde tomará los bits que faltan?", adivinen: sí, de la memoria ram del equipo. Tomará partes al azar hasta completar el tamaño solicitado.
Y esto es gravísimo, mediante enviar pings, pulsos o latidos como es llamado este proceso al servidor vulnerable, la vulnerabilidad "Heartbleed" (corazón sangrante) permite a un atacante enviar sin parar miles y miles de estos "latidos" defectuosos al servidor y mapear la memoria ram del mismo pues en cada pulso podemos ir analizando lo que se encuentra en el servidor en ese momento. Contraseñas, estado de las variables, etc, etc, etc. El servidor con toda la información a la vista.
Se estima que hasta un 17% o medio millón de servidores de seguridad web de Internet estuvieron expuestos a esta vulnerabilidad, la única solución era actualizar a la versión más reciente de OpenSSL que solucionaba esta vulnerabilidad. Claro, hacerlo no era "gratis" por así decirlo, Heartbleed costó unos 500 millones de dólares en todo el mundo para actualizar el software defectuoso. Comparto con ustedes también un video que explica mejor como funcionaba esta vulnerabilidad.
EternalBlue es una vulnerabilidad de los sistemas Windows de Microsoft, ataca a Windows Vista, Windows 7, Windows 8/8.1, Windows 10, Windows Server 2008, Windows Server 2012 y Windows Server 2016 respectivamente hasta el año 2017. Dicha vulnerabilidad permitió el desarrollo de diversos malwares siendo quizá el más famoso de ellos WannaCry.
La vulnerabilidad consiste en permitir a un atacante remoto ejecutar código arbitrario en una computadora vulnerable sin autorización, esto permite controlar el equipo afectado sin que este haga nada o muy poco con resultados desastrosos. WannaCry y otros ramsonware se diseminaron por la red rápidamente y tan solo WannaCry llegó a infectar a unas 200,000 computadoras en 150 países, además de millones de dólares en reparaciones y por aquellos que pagaron el rescate y difícilmente recibirían "la llave" para liberar a los equipos infectados.
Este es un par de vulnerabilidades encontradas en los procesadores de última generación de Intel en 2017, es decir, aquí el fallo no es por software defectuoso, sino hardware que hace mucho más difícil reparar el error. No bastaría con actualizar el software defectuoso, sino "cambiar físicamente" el procesador con problemas, o aplicar ciertos parches informáticos que no resuelven el problema realmente, solo lo enmascaran haciendo más difícil la explotación del problema.
Meltdown y Spectre permiten a los atacantes lean la "mente" de su procesador mientras está "pensando", es decir, acceden directamente al los registros del procesador para extraer información privilegiada, lo que permite a su vez el robo de sus datos privados como contraseñas, información bancaria, fotos, documentos confidenciales, etc.
Tan grave fue esta vulnerabilidad que Intel tuvo que trabajar a toda prisa en desarrollar nuevos procesadores que ya no presentaran este problema y por software tratar de cerrarle paso a ejecución de software peligroso que pudiera aprovechar esta vulnerabilidad. Los principales sistemas operativos lanzaron parches para no permitir el acceso a zonas sensibles del mismo sin la debida autorización y que podrían ser aprovechadas al confiar en hardware comprometido, aunque claro, esto merma el rendimiento del sistema en cuestión.
En el caso del navegador web Chrome también lanzó un parche la vulnerabilidad Spectre que hizo que fuera aún más lento que de costumbre, ya no sabíamos si reír o llorar por esta "solución", en fin. Las acciones de Intel cayó duramente mientras el problema no se resolvió perdiendo probablemente cientos de millones de dólares en el proceso, pueden ver este gráfico de Yahoo finanzas donde vemos como bajan a niveles históricos.
El año pasado (2023) Internet se paralizó debido a la caída de la nube de Amazon, uno de los mayores proveedores de servicios web. ¿Quieres acceder a tu sitio web?, sencillo, el hospedaje se lo compraste a Amazon o tu proveedor se lo compró a él o quizás un tercero lo hizo, ¿necesitas una api en la nube para tal acción?, pues corre en un servicio de Amazon que tal vez alguien más te revende?.
Amazon tiene centralizado Internet, todo, absolutamente todo tarde o temprano termina pasando por sus servidores, y si estos se caen adiós a todo. La explicación oficial que dio Amazon fue "AWS Lambda es un servicio que permite a los clientes ejecutar programas informáticos sin tener que gestionar ningún servidor subyacente. El tablero de AWS también indica que ‘Amazon Connect’ está teniendo problemas, lo que significa que los clientes que usan AWS para centros de llamadas de servicio al cliente tendrán problemas". No queda muy claro si ese software tuvo algún fallo informático por alguna mala implementación o simplemente se saturó y dejó de funcionar.
El resultado es miles y miles de servidores web caídos o sus respectivos servicios que prestan (por ejemplo apis para clientes), es difícil contabilizar a cuanto ascendieron los gastos monetarios porque no se tiene un estimado exacto, además de simplemente tener que esperar a que Amazon estuviera de vuelta no pudiendo hacer más.
Millones de equipos con Windows sin arrancar por un antivirus "defectuoso":
Espero que no se hallan aburrido después de leer este extenso artículo, pero era necesario para ver la magnitud de tener que lidiar con bugs informáticos y lo caro que pueden resultar si no se detectan y se corrigen antes de que pase una desgracia.
En el año en curso, 2024 el 19 de julio millones de equipos no arrancaron y los que estaban funcionando fallaron, en cualquiera de los dos casos mostraban solamente la pantalla azul de la muerte de Windows y hasta ahí, no importaba que apagáramos el equipo, volvía a mostrar la misma pantalla de error, ¿Era Skynet tomando el control de millones de computadoras por todo el mundo?, ¿un hackeo masivo?, no, nada de eso, la culpa la tuvo un antivirus.
CrowdStrike es un fabricante de antivirus empresarial y que está presente en millones de equipos de cómputo protegiéndolos, lo cual está muy bien. Pero este antivirus no funciona como cualquier otro, la mayoría de estos son simples aplicaciones que corren sobre alguna versión de Windows y se mantienen activos cerrando brechas del sistema operativo para proteger al usuario, cuando se apaga la PC Windows le ordena cerrarse, este se descarga de la memoria y el equipo se apaga, cuando se enciende el equipo, inicia Windows y luego este tiene una lista de programas a iniciar de fondo y en algún momento inicia el antivirus y listo. Nada fuera de lo común con respecto a otras aplicaciones.
Pero CrowdStrike no funciona así, no funciona sobre Windows, sino bajo este, tiene acceso directo al hardware algo que no es posible con el software convencional por motivos de seguridad e inicia mucho antes de que lo haga Windows, algo así como los drivers de los sistemas operativos. El motivo para esto es que puede tomar control del equipo mucho antes de que lo haga cualquier malware que pudiera burlas los sistemas de seguridad de Windows y claro, al acceder al hardware y no necesitar a Windows para ello puede anticiparse a cualquier malware corriendo fuera del campo de acción de Windows y cualquier otro sistema de seguridad.
Suena bien pero peligroso a la vez, CrownStrike liberó una actualización defectuosa de su sistema que provocó un choque con Windows haciendo que este dejara de funcionar y solo mostrar la pantalla azul de error dejando al equipo complemente muerto por algunas horas hasta que se encontró como resolver el problema. Millones y millones de equipos de cómputo con Windows (unos 8.5 millones según Microsoft) dejaron de funcionar de un momento a otro paralizando a medio planeta pues aeropuertos, hospitales, tiendas y cualquier lugar donde hubiera una computadora que ejecutara este antivirus quedo en knockout.
Se estima que todo este chistecito de CrowdStrike por lanzar a toda prisa una actualización sin revisar exhaustivamente costará al sector informático unos 280 millones de dólares. También les comparto un video que explica con mayor claridad el problema.
Soluciones:
Como vemos, sale caro y más si hay vida perdidas en el proceso introducir errores informáticos en nuestros trabajos y no detectarlos y mucho menos corregirlos a tiempo. Es verdad que muchas veces no es culpa del programador, es humano y se equivoca, pero hay cosas que se pueden hacer para minimizar estos fallos.
- Control de bugs: cada programador debe probar exhaustivamente el software que está desarrollando, es verdad que en toda empresa se vive sobre tiempos marcados y cualquier retraso cuesta dinero a la empresa. Pero aún así el programador debe probar a fondo su desarrollo y no entregar nada a su superior hasta estar seguro de que no tiene errores, porque si su trabajo va a ser tomado como base o se ensamblará con otros módulos este introducirá errores al resto del software y tarde o temprano todo fallará y será muy difícil detectar donde está el problema.
- Auditorías internas: la empresa desarrolladora debe contar con uno o varios departamentos de pruebas para el software que está en proceso de creación, cualquier fallo encontrado debe ser documentado y devuelto el software al desarrollador para su corrección.
- Auditorías externas: algunas empresas contratan empresas externas para que revisen a fondo el software en desarrollo antes de su liberación comercial, los errores encontrados deben documentarse y el equipo de desarrollo corregirlos. En otros casos se recurre a testers o grupos de prueba en la red que reciben versiones de prueba del software para probarlo y reportar cualquier error encontrado.
- Liberación de parches y actualizaciones críticas: no basta con liberar el software pensando que funciona perfecto y nunca fallará, no es así. El software liberado debe contar con mecanismos que recolecten fallos presentados o permitan a los usuarios reportarlos y periódicamente los desarrolladores deben liberar parches para corregir el software ya funcionando en el mercado.
Conclusiones:
El control de errores en el desarrollo de aplicaciones su super importante, no basta con "solo programar", sino estar completamente seguros de que nuestro código es seguro, que no va a presentar fallas en el futuro y si así es, corregir todo a la brevedad. Todo el tiempo debemos estar haciendo pruebas para asegurarnos de que va bien y estar atento a los reportes de errores que nos lleguen para resolver un problema que a futuro se puede convertir en una calamidad.
Espero les halla resultado de interés este artículo y hallan podido leerlo en su totalidad, un agradecimiento por su tiempo y nos vemos en un próximo artículo.
