Ruby's safe mode no permite el uso de datos contaminados por operaciones potencialmente peligrosas. Varía en niveles, 0 está deshabilitado y luego 1-4 para niveles de seguridad. ¿Qué vulnerabilidades son posibles cuando el modo seguro está habilitado? ¿Conoce algún número de CVE emitido para un programa ruby cuando el modo seguro está habilitado? ¿Qué CWE Violations (o familias cwe) son posibles con el modo seguro habilitado?
Todas las vulnerabilidades del nivel de aplicación no se ven afectadas por el nivel $ SAFE. Inyección de ataques que no pasan por una "operación insegura" como scripts de sitios cruzados e inyección SQL, por ejemplo. Esto incluye, más o menos, todas las clases de vulnerabilidad para aplicaciones web, excepto tal vez la inclusión de archivos locales y remotos. Consulte OWASP Top 10, $ SAFE no ayuda con muchos de estos.
Sin embargo, el nivel $ SAFE lo protege de las vulnerabilidades del sistema. Si un atacante puede escribir código Ruby en un archivo en/tmp, no podrá engañar a su programa para que cargue ese código si $ SAFE> = 2.
Y esto, por supuesto, no incluye cualquier vulnerabilidad con Ruby. Estos son mucho más graves y pueden eludir $ SAFE por completo.
o simplemente viejos desbordamientos de búfer, desbordamientos de enteros, etc en el propio intérprete de Ruby que no tienen nada que ver con $ SAFE.
Rails tiene una historia vulnerabilidades que se producen $ SAFE si está activado o no.Esto se complica por el hecho de que la entrada del usuario se almacena en las aplicaciones de Rails, y los datos maliciosos pueden aparecer nuevamente en el futuro.
reportes de vulnerabilidades en aplicaciones Ruby otra de rieles y la RM son difíciles de conseguir.
Otro gran problema con $ SAFE es que no hay una lista real (que yo sepa) que describa exactamente lo que $ SAFE protege y no protege. Lo único que puede hacer es buscar ruby_safe_level en eval.c (este es un eval.c anterior de 1.8.4). Los comentarios proporcionan esta descripción, pero es bastante vaga.
/* safe-level:
0 - strings from streams/environment/ARGV are tainted (default)
1 - no dangerous operation by tainted value
2 - process/file operations prohibited
3 - all generated objects are tainted
4 - no global (non-tainted) variable modification/no direct output
*/
Supongo que lo que estoy tratando de decir es que $ SAFE es todo acerca de la seguridad del sistema. Hace un buen trabajo, pero no hay una manera real de saber exactamente qué es y qué no está protegido. No debería ser su única línea de defensa, es más una red de seguridad para que nada se deslice a una "operación insegura". Por otro lado, no tiene nada que ver con la seguridad de las aplicaciones y no guardará sus datos o usuarios para que no se vean comprometidos. Y además de eso, MRI tiene un historial de vulnerabilidades que omiten por completo $ SAFE.
Desde $SAFE >= 1 sólo protege a formar mediante la entrada contaminada en no seguros operaciones, tales como eval y así sucesivamente, cualquier vulnerabilidad en un método seguro Rubí seguiría siendo un problema. Por ejemplo, CVE-2009-4124 solo requiere que use las funciones ljust/center/rjust en una entrada, y al menos mi versión de ruby 1.8.7 considera que esas funciones son seguras. Aquí hay un fragmento Ruby que utiliza $SAFE = 4, y sin duda ser vulnerable al problema anterior:
$SAFE = 4; ARGV[0].ljust(ARGV[1].to_i)
En general, la mayoría de las vulnerabilidades de Ruby todavía podría ser objetivo, incluso si el guión rubí funciona en modo seguro.
Además, con $SAFE = 1, puede untaint las variables, y por lo tanto su aplicación es vulnerable en cuanto se untaint y, posteriormente, utilizar esa variable en una forma no segura, la aplicación sigue siendo vulnerable.
+1 gran punto, cualquier función puede ser un receptor si sufre daños en la memoria en el idioma o en una biblioteca. – rook
Espera, pensé que PHP era el único que se vio afectado por la inclusión de archivos remotos. ¿No incluye ruby realmente aceptar una url? ¿Tiene algún vínculo con respecto a los ataques de LFI/RFI de rubí? – rook
Ruby no es realmente vulnerable a RFI, hasta donde yo sé. Sin embargo, si incluye la biblioteca de uri abierto, cualquier llamada para abrir potencialmente puede abrir una URL. Esto no afectará ni requerir ni cargar (utilizado para cargar el código de Ruby), pero podría afectar a cualquier otra cosa que abra un archivo. Aunque las condiciones en las que esto puede suceder son limitadas, ya que Kernel # open tiene que ser utilizado, en lugar de File # open (el idioma habitual para abrir archivos). Es tan vulnerable a LFI que alguien es lo suficientemente tonto como para poner la entrada del usuario en una carga o requerir una declaración. $ SAFE debería atrapar esto sin embargo. – AboutRuby
Núcleo # abierto tiene otras vulnerabilidades que no son inmediatamente obvias también. Por ejemplo, si el primer carácter es una tubería, abrirá un subproceso y usará la salida de esa como su flujo de archivos. – AboutRuby