Los Bugs en la tecnología. Errores en sistemas tecnológicos

Cualquier error o fallo en cualquier programa o software es considerado un bug , por otro lado existen fallas a nivel de hardware a nivel de diseño algunos consideran que se pueden llamar bugs, pero la gran diferencia es que un programa puede ser reparado (parcheado), generalmente de forma rápida, mientras que un error de hardware en una pieza puede requerir cambiar su diseño y volverla a fabricar, aunque muchas veces este funcionamiento erróneo del hardware es subsanado cambiando la forma en que los programas trabajan sobre estos, por otro lado estas soluciones pueden en ocasiones producir que dicho hardware no funcione de forma tan eficiente, en otras son transparente y como ya se indicó en ocasiones requiere que la pieza sea rediseñada.

Los errores o bugs causan diferentes niveles de fallos, según la importancia del fallo se hablan de diferentes tipos de prioridad o criticidad, desde errores sencillos que no afectan la integridad del sistema, hasta fallos graves donde se ve comprometido el funcionamiento del sistema o su seguridad.

No importa que sistema sea, todo sistema puede tener un fallo, sin importar su criticidad todo fallo tiene un proceso con unos pasos que pueden variar un poco según el ente que lo maneje pero que tiene coincidencias.

Detección: bien sean usuarios o personal especializado detectan un error y lo reportan

Reporte: Cuando un sistema es muy grande y el ente que lo maneja recibe muchas solicitudes es común tener un formato de reporte, donde se detalla el problema

Verificación: Se comprueba que el error exista, en ocasiones un error puede ser exclusivo de una situación específica un error en el equipo donde se prueba o una situación fortuita, por lo cual se busca replicar el error y verificar su existencia.

Clasificación: Cada error tiene un nivel de importancia, según su impacto se clasifica en su tipo e importancia para así darle una prioridad.

Progreso: un ciclo que cambia dependiendo de el ente que resuelve el problema y donde se puede revisar el status del bug, hasta que finalmente se resuelve el problema.

Parche y Publicación: una vez corregido se publica la solución.

Imagen de Pixabay

Estos pasos pueden ser comunes en todo el software, sin embargo puede existir diferencias sustanciales en el tratamiento de estos según la filosofía de software y esto tiene diferentes puntos de vistas y muchos debaten sobre este tema.

En un software de corte privativo, el ente que recibe y controla este proceso desde la recepción hasta la publicación es el dueño del software, bien sea una persona o empresa. Estos pueden y así sucede mantener los reportes de forma privada y darle solución si desean o no. Esto trae consigo una dependencia del usuario y empresas que usan dicho software a depender de la diligencia del ente.

Existen posturas donde empresas alegan que estos reportes, sobre todo los de mayor importancia se mantiene privados, con el objetivo de evitar que un tercero lo utilice de forma maliciosa, esto último se ha visto en errores de seguridad principalmente.

A esto se le ha conocido como seguridad por desconocimiento, donde se piensa que al no conocer un fallo de seguridad este no puede ser explotado, sin embargo hay grupos que alegan que si el error se consiguió nadie evita que más personas lo consigan y utilicen. Siendo para estos lo importante no ocultarlo, como buscar su solución su solución.

Realmente mantener un bug oculto (sobre todo en errores críticos), puede traer consigo problemas mayores, un usuario puede mantener una función activa que puede causar pérdida de información o ser vulnerado en su seguridad.

En este sentido es bueno acotar que muchas el desactivar algún servicio o función mientras se repara un fallo puede evitar que este fallo cause problemas, pero esto no es algo que se pueda realizar si el fallo no es público. Por esto existen especialista que se dedican a buscar fallos en sistemas y tienen como política darle un tiempo razonable a la empresa propietaria de un software para repararlo o notificarlo a sus usuarios, en caso contrario ellos liberan la información.

Si a diferencia estamos usando software libre este hermetismo no existe, cuando el código es de libre acceso no se depende de un ente único que pueda corregir los errores, si bien el software libre tiene organizaciones que dirigen su desarrollo y llevan su ciclo de actualizaciones, versiones y bugs. Estos errores al ser reportados pueden ser atacados por una comunidad más grande, donde según la importancia y magnitud del sistema incluso las empresas que usan estos colaboran a solucionar problemas que desean poder incorporar a las ramas principales.

El poseer acceso al código permite incluso que se libere el código de la solución y así permitir que los usuarios incorporen soluciones de forma rápida. En este entorno de trabajo por ejemplo no se piensa que la seguridad del sistema exista por desconocimiento de los errores, por el contrario la posibilidad de atacar estos de forma rápida y contar con mayor colaboración se convierte en uno de sus pilares. Incluso existen casos donde los que descubren los fallos diseñan la solución y la envían para su prueba e incorporación al ente que dirige el proyecto del software. Solución que pueden diseñar porque pueden detectar el error y cuentan con el código fuente para repararlo.
Es importante recordar que sin importar que sean sistemas de código abierto o software privativo ninguno está exento a errores y un proceso para detección, reporte y corrección de estos siempre es necesario.

Existen diariamente reporte de infinidad de bugs en diferentes sistemas, sin embargo solo aquellos que afectan a sistemas de uso masivo y de gran importancia se hacen conocidos y famosos, entre casos recientes hay casos como:

.- El error de Whatsapp que permite instalar un Spyware mediante una llamada, la gravedad de este error era tal que el atacante solo debía realizar la llamada y no necesitaba que se recibiera, la empresa notifica que se debe actualizar el programa, indicando que en su versión más reciente ya estaba parcheado el sistema.

.- En un reporte CVE-2019-11815 de fallas en linux se habla de un error del modulo rds_tcp_kill_sock en net/rds/tcp.c, que en teoría permitiría a un atacante remoto ejecutar código, sin embargo este afecta a los Kernel anteriores 5.0.8 incluyendo esta.

Posiblemente la primera de estas noticias sea la más conocida, un sistema que es usado por un gran número de usuarios y que puede crear una alarma en las personas, por otro lado el segundo caso posiblemente no sea algo tan conocido, las personas no acostumbran realizar un seguimiento en los errores de Linux, sin embargo su impacto en las empresas puede ser mayor, tomando en cuenta que Linux es en la actualidad el sistema dominante en las Internet a nivel de servidores.

Una empresa pequeña donde se desarrolla un software a medida o se diseñe algunos portales, intentara realizar las pruebas más amplias posible de sus sistemas. Buscando errores y seguramente se nutrirá con la información de sus usuarios, pero cuando un empresa crece de manera exponencial y comienza a tener una visibilidad global, la necesidad de mantener su sistema y corregirlo constantemente para brindar la mejor seguridad posible puede volverse un trabajo mayor, en ocasiones se contratan empresas para realizar auditorias que mediante metodologías de pruebas procuran conseguir la mayor cantidad de información posible de un sistema y buscar errores.

Aun así existen infraestructuras tan grandes y complejas en la actualidad que su análisis continuo puede ser costos, en búsqueda de una manera de poder realizar la mayor cantidad de pruebas a sus sistemas, grandes empresas realizan una práctica de nombre Bug Bounty, un práctica donde se ofrecen recompensas a personas que logren conseguir errores en determinados sistemas, muchas veces estas recompensas son altas y son una manera de atraer a especialistas que aprovechan estas recompensas para conseguir reconocimiento.

De esta forma se consigue que un gran número de personas, especialistas en su mayoría dedique tiempo y recursos en probar de forma exhaustiva sus sistemas. Existen listas de los proyectos de Bug Bounty, con gran cantidad de empresas que tienen sistemas donde los interesados pueden rellenar los diferentes formatos donde se reportan los bugs y esperan su aprobación y prueba para cobrar la recompensa, en algunos casos son retos abiertos y en otros para cierto tipo de vulnerabilidades.

Cuando un error no pertenece únicamente al software si no que involucra hardware, buen sea errores en CPU, GPU dispositivos y gadgets, son estos también reportados, sin embargo la forma de reparar un bug de este tipo puede ir desde un cambio en su software, hasta requerir un cambio físico e incluso un rediseño de una arquitectura.

Recientemente se han hecho famosos las vulnerabilidades en procesadores Intel, Meltdown, Spectre y más recientemente Zombieload, si bien algunas de estas son difíciles de explotar, requiriendo incluso tener acceso físico a los equipos, noticias de estas se expandieron, pues afectan a una parte de la arquitectura de los procesadores que se viene usando desde hace años, afectando una cantidad realmente grande de equipos. Una empresa que es el proveedor de procesadores más grande del mundo y una una falla que afecta a dispositivos construidos desde hace años. Esto hace que la cantidad de equipos afectado a nivel doméstico y empresarial sea muy grande. A esto se suma que la solución que se ha conseguido afecta el rendimiento de los dispositivos, donde la única solución real pasa por un rediseño de esa parte de la arquitectura física, lo que imposibilita una solución óptima en los dispositivos existentes.

Por otro lado la cantidad de errores menores, medios y graves realizados en dispositivos es más grande de lo que se percibe en las noticias que logran encabezados, routers, switches, placas, e incluso chips tienen reportes de forma diaria, algunos se solventan con parches, otros con sustitución de componentes y en algunas ocasiones se ven soluciones caseras que pueden incluso dar risa.

En este rubro las vulnerabilidades más conocidas son aquellas que afectan a los Smartphone, pero existen casos que pueden pasar por debajo de la mesa, ejemplo de esto:

.- El fallo en los enrutadores Linksys en donde mediante una acción JNAP en una solicitud JNAP/HTTP, permite realizar un acceso remoto sin autenticar, este según el reporte afecta a más de 25 mil dispositivos, siendo el principal problema que la empresa reportó que no realizar corrección sobre este. En este caso con el hardware sucede algo parecido a la situación del software, donde al ser tecnologías propietarias cerradas no existe manera de solucionar el problema si no es realizado por el fabricante.

En este sentido existe en la actualidad la necesidad de comunidades de promocionar el hardware abierto donde los esquemas sean públicos de la misma manera que sucede con el software de código abierto.

Existen ya personas que desarrollan prototipos de dispositivos los cuales publican bajo esta modalidad,el hardware libre (hardware de código abierto) es aquel donde los dispositivos creados donde sus especificaciones técnicas y diagramas esquemáticos son de acceso público.

Posiblemente Arduino es uno de los casos más famosos de hardware abierto,una placa diseñada para servir de base a proyectos de desarrollos que necesitan de una electrónica base, sobre la cual se han desarrollado gran cantidad de proyectos de índole profesional y educativo, aprovechando su apertura a nivel de software y hardware.

Siendo normal que cualquier sistema puede sufrir de fallas en su diseño, la existencia de un proceso de detección y reporte de errores es necesario. El código abierto permite una mayor transparencia al momento de llevar control de sobre errores de sistemas que pueden afectar a gran cantidad de usuarios.

Tanto en el software como en el hardware existen errores sin embargo sus consecuencias son diferentes, mientras que a nivel de software los errores son siempre reparables en el hardware hay errores que no son reparables sin un cambio físico, lo que en determinado momento puede ocasionar que un dispositivo con un mucho tiempo de vida en el mercado se quede con un defecto.

Así como el software libre ha sido una revolución, el futuro del hardware mediante el hardware abierto puede llegar a sufrir cambios en su manera de ser tratado en un futuro.