A veces los usuarios de Linux necesitan descargar un código fuente para compilarse y luego ejecutarse (se conceden los privilegios de root).
¿Es posible que un código fuente oculte un código malicioso como parte de él? ¿Y cómo se verifica que el código fuente es seguro antes de compilar?
Sin leer y entender cada línea de código y cómo encaja todo, no puedes, de manera realista. Lo mejor que puede hacer es descargarlo como un paquete de una fuente confiable que revisa los paquetes por adelantado, para minimizar el riesgo para el usuario.
Sin embargo, hay ocasiones en que incluso se piratean sistemas operativos completos (como Mint Linux a principios de este año ) así que realmente no puedes estar seguro de que lo que estás obteniendo es seguro.
Al igual que con la mayoría de las cosas que he encontrado al pensar en la seguridad, gran parte de esto se reduce al equilibrio entre la confianza y el sentido común.
No. No es posible verificar el código.
El análogo matemático de esta pregunta se denomina problema de "Verificación del programa". verificación del programa es imposible de decidir. Esto significa que no hay ningún algoritmo que pueda verificar si el código de su computadora es correcto. Estrechamente relacionado, el problema de detención no es decidible, lo que significa que no hay un algoritmo que pueda decirle si su código dejará de ejecutarse . Todo esto se comprobó en la década de 1950-1960, y todos los que obtienen una licenciatura en ciencias de la computación deben recibir información sobre estos resultados. Es matemáticamente imposible verificar el código.
Incluso al leer el código, no es posible verificarlo. En algunos casos, los códigos o algoritmos muy cortos pueden ser comprobados como correctos utilizando la lógica matemática. Las pruebas solo funcionan para algoritmos centrales, como los algoritmos de clasificación y los algoritmos de recorrido de gráficos. Para cualquier base de código de gran tamaño, como un sistema operativo, no hay forma de demostrar la corrección.
Algunos análisis estático y algunos métodos formales existen, y todas estas herramientas intentan realizar alguna forma limitada de verificación. Estas herramientas intentan probar lo que se puede probar fácilmente sobre el código. El análisis estático intenta definir propiedades demostrables del comportamiento dinámico del código cuando se ejecuta. Algunos sistemas utilizan aserciones mientras que otros utilizan invariantes de bucle. Sin embargo, en todos los casos, el análisis estático no puede realizar la verificación completa del programa.
Si decide ejecutar un código, está confiando implícitamente en los autores del código. Confía en su intención de escribir código que funcione y que respete las políticas de seguridad típicas, como la autorización de acceso, los permisos, etc. Las herramientas como mdsums pueden ayudarlo a decidir si descargó la versión del código que los autores pusieron a disposición, pero No puedo ayudarte a verificar el diseño del código.
Sí, si uno descarga y compila ciegamente el código fuente, ese código podría contener una vulnerabilidad que, si se ejecuta, podría dañar el sistema. Además, es posible que no sea necesario ejecutar explícitamente el binario resultante. En su clásico de 1984 Reflexiones sobre Trusting Trust , Ken Thompson demostró cómo se puede hacer para crear un código C que, cuando se compila, explota el compilador y el servidor en el que reside ese compilador.
Hay algunas formas de defenderse contra esto. En 2006, Bruce Schneier publicó en su blog un detalle bastante bueno de un artículo de David A. Wheeler. En defensa contra el ejemplo específico de Thompson. El papel en sí todavía está en su momento, a mi entender.
El papel de Wheeler es muy interesante, pero está enfocado en las entrañas del diseño del compilador, y esta pregunta parece estar más enfocada en las precauciones del usuario final que en el diseño del compilador o incluso en la programación de sistemas. En general, hay dos formas en que entendemos el riesgo que implica compilar un fragmento de código específico:
El segundo caso, una auditoría exhaustiva del código, es una tarea enorme, larga y que requiere muchos recursos. Casi nunca sucede realmente para las bases de código de tamaño no trivial, porque es simplemente demasiado costoso. Con mucha más frecuencia, estamos viendo el primer caso: confiar en el codificador y validar que el código no ha sido manipulado entre el codificador y el consumidor.
En 2015, publiqué un artículo para LinuxJournal sobre cómo el código generalmente pasa del desarrollador al usuario de Linux. Cadena de Custodia ya ha sido reeditado por mi empleador fuera del paywall de LinuxJournal. Está muy enfocado en la ruta que atraviesa la administración de paquetes, pero si lo lee con atención, se dará cuenta de que las partes aplicables a un mantenedor de paquetes que compila el código obtenido en algún lugar de Internet también son aplicables a un usuario final que lo haga.
Por supuesto, al final, como han señalado otros, estas comprobaciones de integridad solo sirven para algo si la infraestructura de los desarrolladores no se ha visto comprometida, si el desarrollador estaba bien programado, etc.
Creo que lo que estás pidiendo es un "análisis estático" (a diferencia del "análisis dinámico" que analiza el código en ejecución).
El grupo de seguridad web OWASP tiene una página que habla sobre análisis de seguridad de código fuente estático en términos generales. Si simplemente busca en Google "análisis de seguridad de código fuente estático", encontrará muchos productos disponibles (algunos programas de pago, otros gratuitos).
La parte de la respuesta que no te va a gustar es: por lo general, estos analizadores buscan vulnerabilidades en forma de desbordamientos de búfer, uso después de la liberación y cosas por el estilo. Es casi imposible que un programa decida qué cuenta como "comportamiento malicioso", por ejemplo, el programa puede leer todos sus archivos y cargarlos en un servidor. Esto está perfectamente bien si el programa es una herramienta de sincronización en la nube como Dropbox, pero menos si se trata de un juego de solitario. En pocas palabras: no hay sustituto para leer el código fuente.
Personalmente, observo la reputación del sitio del que obtuve el código fuente. Si está en github o similar, ¿quiénes son los principales contribuyentes? Si los busco en google, ¿parecen legítimos? El código en sí fue descargado por HTTPS o SSH, ¿verdad? Podría buscar algunas revisiones de este software para asegurarme de que ningún bloguero haya puesto señales de alerta al respecto, etc. (Nota final: los riesgos de este tipo de cosas son mucho menores si instala el software como un paquete a través del paquete de su distro) gerente, así que siempre prefiero esto si es posible.)
Como han mencionado otros, en realidad es prácticamente imposible verificar que el código no tenga un comportamiento malicioso. Hay un puñado de casos especiales, donde el código fue escrito para ser verificable, como el seL4 kernel , pero el el caso general se demuestra fácilmente como insoluble.
En situaciones prácticas, hay pasos que puede tomar para disminuir la probabilidad de un problema:
Lea otras preguntas en las etiquetas source-code linux