¿Por qué el gobierno de los Estados Unidos no permite los lenguajes dinámicos para proyectos seguros?

Conozco a algunas personas que actualmente están trabajando en un proyecto para el ejército de los EE. UU. (Nivel de seguridad bajo, datos de tipo de recursos humanos sin combate).

Se envió un estado inicial del código del proyecto a los militares para su revisión, y ejecutaron el programa a través de algún tipo de herramienta de análisis de seguridad. Devolvió un informe de problemas de seguridad conocidos en el código y requirió cambios que debían implementarse antes de la entrega del producto final.

Uno de los elementos que debía resolverse era la eliminación de parte del proyecto que se escribió en Ruby, ya que es un lenguaje dinámico.

¿Cuál es el trasfondo / razón para no permitir que se use un lenguaje dinámico en una configuración segura? ¿Es este el gobierno que tarda en adoptar nuevas tecnologías? ¿O los lenguajes dinámicos presentan un riesgo de seguridad adicional en comparación con los lenguajes estáticos (ala C ++ o Java )?

Hay una serie de cosas 'ordenadas' que se pueden hacer en lenguajes dinámicos que se pueden guardar en partes del código que no son inmediatamente obvias para otro programador o auditor en cuanto a la funcionalidad de un determinado código.

Considere esta secuencia en irb (shell ruby ​​interactivo):

irb(main):001:0> "bar".foo
NoMethodError: undefined method `foo' for "bar":String
        from (irb):1
        from /usr/bin/irb:12:in `<main>'
irb(main):002:0> class String
irb(main):003:1> def foo
irb(main):004:2> "foobar!"
irb(main):005:2> end
irb(main):006:1> end
=> nil
irb(main):007:0> "bar".foo
=> "foobar!"

Lo que sucedió allí es que intenté llamar al método fooen una constante de cadena. Esto falló. Luego abrí la clase String y definí el método fooo return "foobar!", y luego lo llamé. Esto funcionó.

Esto se conoce como una clase abierta y me da pesadillas cada vez que pienso en escribir código en ruby ​​que tenga algún tipo de seguridad o integridad. Claro que te permite hacer algunas cosas ordenadas bastante rápido ... pero podría hacerlo de manera que cada vez que alguien almacenara una cadena, la almacenara en un archivo o la enviara a través de la red. Y esta pequeña parte de la redefinición de la cadena se puede guardar en cualquier parte del código.

Muchos otros lenguajes dinámicos tienen cosas similares que se pueden hacer. Perl tiene Tie :: Scalar que puede cambiar detrás de escena cómo funciona un escalar dado (esto es un poco más obvio y requiere un comando específico que puede ver, pero un escalar que se pasa desde otro lugar podría ser un problema). Si tiene acceso al Perl Cookbook, busque la Receta 13.15 - Creación de variables mágicas con empate.

Debido a estas cosas (y otras a menudo son parte de lenguajes dinámicos), muchos enfoques para el análisis estático de la seguridad en el código no funcionan. Perl and Undecidability muestra que este es el caso y señala incluso estos problemas triviales con el resaltado de sintaxis ( whatever / 25 ; # / ; die "this dies!";plantea desafíos porque whateverse pueden definir para tomar argumentos o no en tiempo de ejecución derrotando por completo un resaltador de sintaxis o un analizador estático).

Esto puede ser aún más interesante en Ruby con la capacidad de acceder al entorno en el que se definió un cierre (ver YouTube: Mantener a Ruby Razonable de RubyConf 2011 por Joshua Ballanco). Fui informado de este video de un comentario de Ars Technica por MouseTheLuckyDog .

Considere el siguiente código:

def mal(&block)
    puts ">:)"
    block.call
    t = block.binding.eval('(self.methods - Object.methods).sample')
    block.binding.eval <<-END
        def #{t.to_s}
          raise 'MWHWAHAW!'
        end
    END
end

class Foo
    def bar
        puts "bar"
    end

    def qux
        mal do
            puts "qux"
        end
    end
end

f = Foo.new
f.bar
f.qux

f.bar
f.qux

Este código es completamente visible, pero el malmétodo podría estar en otro lugar ... y con clases abiertas, por supuesto, podría redefinirse en otro lugar.

Ejecutando este código:

~ / $ ruby ​​foo.rb 
bar
> :)
qux
bar
b.rb: 20: en `qux ': MWHWAHAW! (Error de tiempo de ejecución)
    de b.rb: 30: en ''
~ / $ ruby ​​foo.rb 
bar
> :)
qux
b.rb: 20: en `bar ': MWHWAHAW! (Error de tiempo de ejecución)
    de b.rb: 29: en ''

En este código, el cierre pudo acceder a todos los métodos y otros enlaces definidos en la clase en ese ámbito. Escogió un método aleatorio y lo redefinió para generar una excepción. (vea la clase Binding en Ruby para tener una idea de a qué tiene acceso este objeto)

Las variables, los métodos, el valor de sí mismo y posiblemente un bloque iterador al que se pueda acceder en este contexto se conservan.

Una versión más corta que muestra la redefinición de una variable:

def mal(&block)
    block.call
    block.binding.eval('a = 43')
end

a = 42
puts a
mal do 
  puts 1
end
puts a

Que, cuando se ejecuta produce:

42
1
43

Esto es más que la clase abierta que mencioné anteriormente que hace imposible el análisis estático. Lo que se demostró anteriormente es que un cierre que se pasa a otro lugar, lleva consigo el entorno completo en el que se definió. Esto se conoce como un entorno de primera clase (al igual que cuando puede pasar funciones, son funciones de primera clase, Este es el entorno y todos los enlaces disponibles en ese momento). Se podría redefinir cualquier variable que se definió en el alcance del cierre.

Bueno o malo, quejándose de rubí o no (hay usos donde uno quieren ser capaces de conseguir en el entorno de un método (véase Segura en Perl)), la cuestión de "¿por qué el rubí estar restringido en un proyecto del gobierno "Realmente se responde en ese video vinculado anteriormente.

Dado que:

1. Ruby permite extraer el medio ambiente de cualquier cierre.
2. Ruby captura todos los enlaces en el alcance del cierre.
3. Ruby mantiene todos los enlaces como vivos y mutables.
4. Ruby tiene nuevos enlaces que siguen los viejos enlaces (en lugar de clonar el entorno o prohibir volver a enlazar)

Con las implicaciones de estas cuatro opciones de diseño, es imposible saber qué hace cualquier parte del código.

Puede leer más sobre esto en el blog Abstract Heresies . La publicación particular es sobre Scheme, donde se tuvo ese debate. (relacionado con SO: ¿Por qué Scheme no admite entornos de primera clase? )

Con el tiempo, sin embargo, me di cuenta de que había más dificultades y menos poder con entornos de primera clase de lo que había pensado originalmente. En este punto, creo que los entornos de primera clase son inútiles en el mejor de los casos y peligrosos en el peor.

Espero que esta sección muestre el aspecto peligroso de los entornos de primera clase y por qué se le pediría que elimine a Ruby de la solución provista. No se trata solo de que Ruby sea un lenguaje dinámico (como se mencionó en otra respuesta, se han permitido otros lenguajes dinámicos en otros proyectos), sino que hay problemas específicos que hacen que algunos lenguajes dinámicos sean aún más difíciles de razonar.

Asumiendo que la evaluación fue solo de seguridad, y no solo un escaneo de aceptación (es decir, no aceptan a Ruby porque no quieren apoyar a Ruby) entonces:

Las herramientas de análisis de seguridad suelen tener un mal momento con comportamientos dinámicos.

Por ejemplo:

Ejecute cualquier proyecto .NET escrito con características modernas como ASP.NET MVC y Entity Framework a través de algo como Veracode y vea qué tipo de lista de falsos positivos recibe en su informe.

Veracode incluso enumera muchas técnicas básicas dentro de las bibliotecas principales de .NET 4 como "marcos no compatibles" como no compatibles o beta solo aunque la mayoría de ellos tienen varios años en este momento.

Si se trata de una entidad que tiene una gran dependencia de dicha herramienta, casi se ven obligados a considerar a aquellos inseguros si no tienen la experiencia técnica y los recursos para evaluar manualmente un proyecto y ver si está escrito y seguro.

En las operaciones civiles donde los sistemas informáticos generalmente no controlan nada peligroso o terriblemente costoso, la mitigación es que se discuten los falsos positivos y generalmente se aceptan como tales a granel.

En las operaciones bancarias todavía tiene la posibilidad de una mitigación de falsos positivos, pero va a pasar mucho más tiempo discutiendo las minucias de cada elemento. Esto rápidamente se convierte en un costo prohibitivo y comienza a utilizar métodos más tradicionales.

En el ejército, la aviación, la industria pesada y similares, los sistemas pueden controlar cosas que tienen modos de falla terribles, por lo que pueden tener reglas muy estrictas sobre idiomas, compiladores, etc.

Las organizaciones también generalmente escriben su política de seguridad para el peor de los casos que conocen, por lo que incluso si está escribiendo algo trivial, si lo está escribiendo para una organización que tiene sistemas no triviales, el valor predeterminado generalmente será retenerlo. un estándar más alto a menos que alguien solicite una excepción específica.

Se pueden usar lenguajes dinámicos en aplicaciones militares y de defensa. Personalmente he usado y entregado Perl y Python en aplicaciones DoD. También he visto PHP y JavaScript utilizados y desplegados. En mi experiencia, la mayoría del código no compilado que he visto ha sido scripts de shell y Perl porque los entornos requeridos están aprobados e instalados en una variedad de posibles sistemas de destino.

El hecho de que estos lenguajes sean dinámicos probablemente no sea el problema. Los intérpretes para estos idiomas deben estar aprobados para su uso en los sistemas de destino. Si el intérprete no está aprobado para su uso (o tal vez sí, pero no está implementado en los sistemas de destino), entonces no se puede usar el idioma. El uso de un intérprete determinado (o cualquier aplicación) en un sistema seguro requiere cualquier número de obstáculos de seguridad: análisis de la fuente, la capacidad de compilar desde la fuente para entornos de destino, análisis adicional de los binarios, garantizar que no haya conflictos con la infraestructura existente, etc.

Pasé algún tiempo entrevistando con el Departamento de Defensa (DOD), para obtener un código de posición para la MMU del F-16 . Sin violar ninguna divulgación: la MMU es la unidad de computadora que controla casi todas las funciones del F-16. Es (obviamente) crítico que no se produzcan errores, como errores de tiempo de ejecución, durante el vuelo. Es igualmente crítico que el sistema realice operaciones informáticas en tiempo real.

Por esta y otras razones históricas, todo el código para este sistema está escrito o compilado en ADA, un lenguaje de programación estático orientado a objetos .

Debido a las características de soporte críticas de seguridad de Ada, ahora se usa no solo para aplicaciones militares, sino también en proyectos comerciales donde un error de software puede tener graves consecuencias, por ejemplo, aviónica y control de tráfico aéreo, cohetes comerciales (por ejemplo, Ariane 4 y 5), satélites y otros sistemas espaciales, transporte ferroviario y banca. Por ejemplo, el software del sistema de vuelo por cable en el Boeing 777 fue escrito en Ada.

Odio citar demasiado, pero esto explica muy bien por qué se usan exactamente lenguajes estáticos (como ADA) para proyectos como este:

Se admite una gran cantidad de comprobaciones en tiempo de compilación para ayudar a evitar errores que no serían detectables hasta el tiempo de ejecución en otros idiomas o requerirían que se agreguen comprobaciones explícitas al código fuente. Por ejemplo, la sintaxis requiere el cierre explícito de bloques para evitar errores debido a tokens finales no coincidentes. La adherencia al tipeo fuerte permite la detección de muchos errores comunes de software (parámetros incorrectos, violaciones de rango, referencias no válidas, tipos no coincidentes, etc.) ya sea durante el tiempo de compilación o durante el tiempo de ejecución. Como la concurrencia es parte de la especificación del lenguaje, el compilador puede en algunos casos detectar posibles puntos muertos. Los compiladores también suelen buscar identificadores mal escritos, visibilidad de paquetes, declaraciones redundantes, etc. y pueden proporcionar advertencias y sugerencias útiles sobre cómo solucionar el error.

Ada también admite comprobaciones en tiempo de ejecución para proteger contra el acceso a la memoria no asignada, errores de desbordamiento del búfer, violaciones de rango, errores fuera de uno, errores de acceso a la matriz y otros errores detectables. Estas comprobaciones pueden desactivarse en aras de la eficiencia del tiempo de ejecución, pero a menudo pueden compilarse de manera eficiente. También incluye instalaciones para ayudar a la verificación del programa. Por estas razones, Ada se usa ampliamente en sistemas críticos, donde cualquier anomalía puede tener consecuencias muy graves, por ejemplo, muerte accidental, lesiones o pérdidas financieras graves. Los ejemplos de sistemas donde se usa Ada incluyen tecnología de aviónica, ferrocarriles, banca, militar y espacial.

La gestión dinámica de la memoria de Ada es de alto nivel y de tipo seguro. Ada no tiene "punteros" genéricos (y vagos); ni declara implícitamente ningún tipo de puntero. En cambio, toda la asignación y desasignación de memoria dinámica debe realizarse a través de tipos de acceso declarados explícitamente. Cada tipo de acceso tiene un grupo de almacenamiento asociado que maneja los detalles de bajo nivel de la administración de memoria; el programador puede usar el grupo de almacenamiento predeterminado o definir otros nuevos (esto es particularmente relevante para el acceso no uniforme a la memoria). Incluso es posible declarar varios tipos de acceso diferentes que todos designan el mismo tipo pero usan diferentes agrupaciones de almacenamiento. Además, el lenguaje proporciona comprobaciones de accesibilidad, tanto en tiempo de compilación como en tiempo de ejecución, que aseguran que un valor de acceso no pueda sobrevivir al tipo de objeto al que apunta.

Tanto DoD como NASA tienen una larga historia con fallas de programación que les costaron miles de millones de dólares. Ambas instituciones han aceptado procesos que deberían protegerlos de la repetición de los mismos errores.

Is this the government being slow to adopting new technologies?

Esta es una idea errónea: los lenguajes dinámicos no son una tecnología nueva, son bastante antiguos. El problema es que si alguna vez tuvo un problema causado por un lenguaje dinámico (por ejemplo, por un tipeo débil / dinámico) y ese problema le costó mucho dinero, podría aceptar una política que le impediría volver a cometer el mismo error, por ejemplo Prohibir el uso de lenguajes dinámicos en sistemas sensibles.

Los lenguajes dinámicos a menudo "tragan" errores y terminan con un comportamiento inesperado. Esto es muy peligroso en sistemas sensibles. Si sucede algo incorrecto, desea saberlo lo antes posible.

Si se trata de seguridad, sería necesario ver el caso de uso real. Por ejemplo, no creo que una página web de Ruby on Rails sea automáticamente menos segura que una página web de Java.

Me gustaría agregar a las respuestas existentes describiendo SA-CORE-2014-005 de Drupal , que es una vulnerabilidad muy crítica que permite la inyección de SQL y, en última instancia, la ejecución de código arbitrario. Está causada por las reglas de tipeo dinámico y tipeo de ejecución laxa de PHP.

La totalidad del parche para este problema es:

-      foreach ($data as $i => $value) {
+      foreach (array_values($data) as $i => $value) {

Este código es parte de una capa de abstracción de SQL diseñada para evitar la inyección de SQL. Toma una consulta SQL con parámetros con nombre y una matriz asociativa que proporciona un valor para cada parámetro con nombre. Se permite que el valor sea una matriz, en casos como WHERE x IN (val1, val2, val3), donde los tres valores se pueden pasar como un solo valor de matriz para un único parámetro con nombre.

La vulnerabilidad se produce porque el código se supone que $ien $i => $valuedebe haber un índice entero del valor. Continúa y concatena este "índice" directamente en la consulta SQL como parte del nombre de un parámetro, porque los enteros no necesitan ningún escape, ¿verdad?

Desafortunadamente para Drupal, PHP no ofrece tal garantía. Es posible pasar otra matriz asociativa, cuyas claves son cadenas, y este bucle concatenará felizmente la clave de cadena en la consulta, tal como está (recuerde que el código cree que solo puede ser un entero).

Si bien hay formas de tener un error similar en un lenguaje de tipo estático, es poco probable. Un buen desarrollador consideraría las posibles cosas $iantes de concatenarlo en la consulta. Con un lenguaje tipado estáticamente, es muy fácil hacer cumplir que $idebe ser un número entero, y en un código sensible a la seguridad como este, seguramente se haría.

Además, el código realmente comprueba si el valor es una matriz antes de iterar sobre los elementos. Y aquí se encuentra una segunda parte de la falla que habilita esta vulnerabilidad: tanto una matriz asociativa como una matriz "normal" son verdaderas para is_array. Si bien también es cierto que en C #, tanto los diccionarios como las matrices lo son IEnumerable, es difícil construir código que combine las claves del diccionario con índices de matrices como este, incluso intencionalmente, y mucho menos accidentalmente.

Si una base de código es segura o no depende de cómo escriba su código, cómo lo pruebe y cómo valide y monitoree su proceso de desarrollo e implementación. Los idiomas no son seguros ni inseguros, así es como codifica.

La mayoría de los incidentes de seguridad debidos a entradas maliciosas (inyecciones de sql, desbordamientos de búfer), virus, rootkits y troyanos. Ningún idioma puede protegerte de eso.

Por lo tanto, prohibir las clases de idiomas por ser "inseguros" no es una razón válida.

Sospecho que alguien, por cualquier razón, informado o no, decidió prohibir estos idiomas. Después de un tiempo se convirtió en una verdad organizacional . Puede haber sido cierto en ese momento para algunos proyectos, pero las culturas de control no están interesadas en cambiar las decisiones (admitir que estaban equivocadas) y prefieren reglas simples. Prosperan con las reglas y regulaciones y no importa si tienen sentido o no, lo que cuenta es la seguridad percibida .

Esto sucede todo el tiempo en las culturas de control. Lo veo más o menos a diario. No tiene sentido, pero así es como funciona. Si desea leer más sobre este tema tan relevante, le recomiendo el libro de Schneider " La alternativa de reingeniería ". Aquí hay un diagrama de cultura de Michael Sahoto / Agilitrix , basado en el libro de Schneider:

Por lo que puedo decir, la política oficial del Departamento de Defensa generalmente no prohíbe los lenguajes dinámicos.

Las normas para el software desarrollado o adquirido por el DoD son promulgadas por la Agencia de Sistemas de Información de Defensa (DISA). Su seguridad de las aplicaciones - Seguridad de Aplicaciones y Desarrollo guía de implementación técnica de seguridad (STIG) no prohíbe cualquier idioma en particular. No menciona a Ruby, pero menciona a Perl y Python que son igualmente dinámicos. Los menciona en el contexto de varios temas (siguiendo los estándares de codificación establecidos, evitando vulnerabilidades de inyección de comandos, etc.).

Probablemente lo que está viendo es una herramienta de escaneo demasiado estricta (hay varias diferentes mencionadas en el STIG, cada una puede tener su propia interpretación de las reglas) y / o una interpretación demasiado estricta de su salida.