Por ejemplo, ¿podría ser vulnerable el lenguaje PHP, por lo que millones de sitios web también son vulnerables solo porque lo utilizaron independientemente del código escrito?
Por ejemplo, ¿podría ser vulnerable el lenguaje PHP, por lo que millones de sitios web también son vulnerables solo porque lo utilizaron independientemente del código escrito?
Ken Thompson escribió sobre este problema exacto en 1984 en su famoso artículo " Reflexiones en Trusting Trust ".
En el documento, analiza un compilador escrito en C que compila el código C, 'bootstrapping' en sí mismo. Luego agrega una línea que compila el código C con un error deliberado (utilizando el ejemplo de una contraseña codificada) y lo aprueba como el compilador C "oficial", creando un Caballo de Troya. Finalmente, agrega un segundo error que oculta el primer error. Vuelve a compilar el compilador, lo que elimina el código visible que creó el error pero deja el caballo de Troya en el binario del compilador. También señala que tal engaño puede realizarse a cualquier nivel: ensamblador, compilador, cargador o microcódigo de hardware.
La conclusión lógica fue que no puedes confiar en el código de una computadora que no creaste totalmente, y ningún nivel de control puede identificar estos problemas.
Como esto se presentó antes de que se aprobara el CFAA, su punto final fue que dado que nunca podemos probar que un sistema sea confiable, debemos crear un elemento de disuasión en su lugar y pedir un castigo más severo por piratear los sistemas de otras personas.
Este documento y las ideas son clásicos, y se han mantenido relevantes para la seguridad a lo largo de la historia de la informática. Es muy corto Dale una lectura y ve si satisface tu curiosidad, o alimenta tu paranoia.
"Vulnerabilidad" tiene muchos significados. En el contexto de los lenguajes de programación, podría considerar los problemas de diseño que favorecen la escritura de código inseguro como una vulnerabilidad del lenguaje de programación específico. Por ejemplo, la administración manual de la memoria, los aspectos específicos del manejo de cadenas y la falta de controles de límites implícitos son problemas importantes al escribir el código C. Otros lenguajes de programación fueron diseñados específicamente para evitar tales problemas (a menudo a costa de algún rendimiento).
De manera similar, se podría considerar una vulnerabilidad de PHP como un lenguaje enfocado en el desarrollo web que hizo muy fácil crear dinámicamente una página web, pero hizo mucho más difícil hacerlo de manera segura, es decir, escapar y codificar adecuadamente Salida en función del contexto actual. Es por eso que tienes muchas aplicaciones PHP vulnerables a XSS y similares.
También las bibliotecas centrales con valores predeterminados inseguros o una API que favorece el código inseguro pueden considerarse una vulnerabilidad del lenguaje de programación. Por ejemplo, durante mucho tiempo, la pila de SSL en los principales idiomas como Python o PHP no verificó correctamente los certificados en las conexiones SSL de forma predeterminada y, por lo tanto, las aplicaciones eran vulnerables a los ataques del hombre en el centro, a menos que trabajaran específicamente en los valores predeterminados inseguros.
Y luego, a veces hay un comportamiento débil o explícitamente indefinido para declaraciones específicas en lenguajes de programación que no conducen a errores de compilación, sino a códigos diferentes y, a veces, inseguros, según el compilador o los indicadores, a menudo según el nivel de optimización. Esto también podría considerarse una vulnerabilidad del lenguaje, ya que este tipo de declaraciones no están explícitamente prohibidas y es necesario que sean rechazadas por cualquier implementación.
Y luego, por supuesto, puede haber compiladores con puertas traseras que siempre crean en binarios con puertas traseras. Y hay errores de seguridad en las bibliotecas. Pero estas no son vulnerabilidades del lenguaje en sí (es decir, según lo especificado o documentado) sino solo de la implementación específica.
Las computadoras no funcionan en un 'lenguaje' de 0 y 1. Un lenguaje es simplemente una forma de interpretar 0 y 1 para que signifique algo. Si ayuda, piensa en 0 y 1 como letras del alfabeto; el lenguaje es la formulación de esas letras en combinaciones que tienen algún significado intrínseco.
Es por eso que los virus que impactaron, por ejemplo, Windows 95, no impactaron a una Mac (o viceversa). Podría tener el mismo patrón de 0 y 1, pero cada computadora interpretó lo que significaron de manera diferente. En uno, el comportamiento devastador; en el otro, código no ejecutable.
Entonces, no, no existe una vulnerabilidad al usar el sistema binario. Una vulnerabilidad / virus / lo que sea no es un problema con los 0 y los 1 - es con la forma en que la computadora interpreta esos 0 y 1.
Lea otras preguntas en las etiquetas vulnerability