Independientemente del sistema operativo que estemos utilizando, casi siempre estaremos rodeados de software de código abierto. Los desarrolladores de herramientas bajo licencias propietarias, no han inventado nada. Casi todos utilizan algún tipo de biblioteca de código abierto para que las cosas funcionen bien.
Algunos opinan que estas bibliotecas de código abierto suponen un riesgo significativo, porque los atacantes pueden hacerse pasar por colaboradores del proyecto para insertar malware.
También argumentan que cualquier villano puede crear, o clonar una biblioteca y ponerla a disposición del público en alguno de los repositorios de código abierto, desde donde cualquiera puede descargarla.
En junio de 2022, GitHub tuvo un fallo de seguridad grave que fue explotado para tomar el control de repositorios ajenos con el propósito de llevar a cabo ataques a cadenas de suministro de software.
Pero en muchos casos, las personas u organizaciones que las utilizan, no las gestionan adecuadamente.
Algunos, para ahorrar tiempo y costes, se limitan a copiar y pegar algunas líneas.
Pero, si les regalasen un coche:
- ¿Se embarcarían en un largo viaje sin probarlo?
- ¿Lo llevarían a un mecánico para hacerle una revisión?
Mitos sobre la seguridad del software de código abierto
Por supuesto, existen argumentos perfectamente válidos para cuestionar la seguridad de algunas aplicaciones bajo licencias libres o de código abierto.
Pero muchos de ellos se repiten como mantras, son fruto del desconocimiento, o simplemente no tienen ningún sentido.
Independientemente de la licencia bajo la cual se publican, todas las aplicaciones y piezas de software son susceptibles de presentar vulnerabilidades.
Existen muchas percepciones erróneas sobre el software libre y de código abierto (siempre es gratuito, solo hay software libre para Linux, etc.), y para enumerarlas todas haría falta escribir un libro.
En este artículo intentamos exponer, de forma muy resumida, las relacionadas con la seguridad.
A diferencia del software propietario, cualquiera puede acceder al código fuente de una aplicación de código abierto para instalar malware.
Este es todo un clásico.
Qué el código sea accesible para todo el mundo, no significa necesariamente que el vecino de enfrente pueda explotarlo para instalar una puerta trasera.
Del mismo modo que sucede con el software propietario, para explotar una vulnerabilidad, o agregar código malicioso a una pieza de software con la intención de distribuirla, se necesita esfuerzo y tener las habilidades necesarias.
Por otro lado, cualquier pirata informático que tenga conocimientos sobre lenguajes de programación, y una buena comprensión del lenguaje ensamblador, puede aplicar ingeniería inversa a una pieza de software.
A la hora de explotar un programa, a los villanos les importa bien poco si la aplicación es software libre, de código abierto o, por el contrario, tiene un millón de restricciones.
Básicamente, la ingeniería inversa es el proceso de estudiar las funciones de un producto a partir del análisis de su código. Se trata de un proceso completamente legítimo, si se ha obtenido el permiso del desarrollador de la aplicación.
Da igual que la aplicación este bajo una Licencia Pública General de GNU, o que la empresa que la distribuye (tanto pagando como de forma gratuita), prohíba su copia, redistribución y modificación.
Muchas veces, ni siquiera es necesario profundizar en miles de líneas de código para encontrar una vulnerabilidad.
Por lo tanto, mantener el código fuente en secreto para mejorar la seguridad del software, no tiene sentido, y una licencia comercial no garantiza necesariamente la seguridad.
Y ocultar las vulnerabilidades por motivos comerciales, tampoco hace que estas desaparezcan, sino más bien todo lo contrario: las convierte en una bomba de relojería y en carnaza para los exploits..
Los proyectos de código abierto disponen de pocos recursos y, en consecuencia, son inseguros.
Muchos todavía piensan que las personas que se dedican esto son cuatro frikis o activistas que teclean código en el sótano de su casa.
Pero algunos proyectos de código abierto como Mozilla Firefox (con aproximadamente unos 198 millones de usuarios) tienen un equipo dedicado a resolver todos los problemas de seguridad que puedan ir surgiendo.
Y aunque a Richard Stallman se le puedan poner los pelos de punta, incluso Microsoft (el mismísimo Satán) de vez en cuando aporta código, liberando algunos de sus programas.
La empresa de Redmond, también ha comprado GitHub: un sitio web que ayuda a los desarrolladores a almacenar y administrar su código.
Google Open Source, patrocina una variedad de eventos de código abierto, desde reuniones locales hasta conferencias para toda la industria.
Por no hablar de compañías como Oracle Corporation, una plataforma con infraestructuras en la nube, o Red Hat, una multinacional estadounidense que provee software de código abierto principalmente a empresas.
Incluso los proyectos más pequeños y con menos recursos, cuando encuentran una vulnerabilidad, la solucionan de inmediato.
Muchos de sus desarrolladores son programadores profesionales, que utilizan las plataformas Open Source para demostrar su propia competencia, y a nadie de este mundillo le gustaría ser considerado un chapucero.
La teoría de los mil ojos
Si hemos de ser sinceros, el hecho de que el código fuente de una aplicación esté disponible para que cualquiera pueda revisarlo, no significa necesariamente que se esté auditando continuamente.
Por muy entusiasta que sea, nadie quiere trabajar gratis, auditando indiscriminadamente el código que escriben otras personas.
Pero cualquier desarrollador que quiera incorporarlo a sus propios proyectos, normalmente antes de implementarlo, lo probará para asegurarse de que funciona, y que no tiene errores que podrían derivar en vulnerabilidades.
Y en este sentido, sí que puede darse el caso de que cientos de programadores estén utilizando, y, por lo tanto, revisando el mismo código.
Sí, detectan algo que no está bien, en la mayoría de los casos lo comunicarán al desarrollador original (y a veces también a la comunidad) para que se tomen las medidas oportunas.
Pero lamentablemente, aunque los desarrolladores de código abierto tienden a solucionar los problemas muy rápidamente, a veces la distribución de los parches no siempre es lo fluida que debería ser.
Pero esto pasa con todo tipo de aplicaciones, independientemente de la licencia con la que se distribuyen, incluso con los distintos sistemas operativos.
Un informe publicado por Palo Alto Networks encontró que el 80 por ciento de las vulnerabilidades se hicieron públicas antes de que se publicaran en la CVE (una lista con información registrada sobre vulnerabilidades de seguridad conocidas.).
Como resultado, existe una buena posibilidad de que ya haya un exploit disponible para aprovecharlas, antes de que se corrijan.
Entonces, ¿el software de código abierto es más seguro que el propietario (o privativo)?
Por supuesto que no.
Igual que pasa con los programas distribuidos bajo licencias propietarias, también existen algunos proyectos libres o de código abierto que están obsoletos, desatendidos o discontinuados.
También los hay que son disfuncionales, o están mal escritos, lo que supone un riesgo potencial.
Tampoco hay que descartar la posibilidad de que un sinvergüenza aproveche la coyuntura para distribuir cualquier aplicación popular modificada, repleta de malware.
Cuando se trata de errores y vulnerabilidades, no hay una diferencia significativa en la gravedad de las mismas, independientemente de la licencia con la que se distribuye una aplicación.
Debe observarse la seguridad y la reputación de cada pieza de software de forma individual.
En última instancia, son los programadores quienes hacen que el código fuente sea seguro o inseguro.
Cualquier programador que se preocupe por su reputación, quiere mostrar un código escrito de acuerdo con las mejores prácticas de la industria.
Y detectar los errores y corregirlos, dependerá en gran medida de la cantidad de recursos humanos destinados a ello.
En este sentido, en teoría existen más posibilidades de encontrar una vulnerabilidad en una pieza de software, si su código fuente es de acceso público, ya que cualquier persona que quiera utilizarlo para sus proyectos (si sabe lo que le conviene), lo revisará.
