¿Cómo convencer a mi administrador de que Java ON A SERVER no es inseguro per se?

13

La aplicación

Tenemos una pequeña aplicación Java que usa algunas rutas Camel para recoger archivos cargados de un servidor web, procesarlos y enviar algunos correos electrónicos con los resultados.

El servidor en el que se ejecutaba esta aplicación se ha desarmado. Por ahora tenemos que ejecutarlo en hardware con poca potencia, porque no puedo convencer al administrador de que instale un JRE en el servidor web (que en realidad es un servidor multipropósito).

El miedo

Yo mismo soy un ingeniero de aplicaciones de Java, escribo código JEE para vivir, manejando transacciones B2B por valor de decenas de miles de euros por semana. Pero tengo problemas para encontrar fuentes creíbles que refuten el mito de que Java es inseguro per se.

Los dos argumentos principales del administrador contra la instalación de un JRE:

Las aplicaciones Java se comen toda mi RAM
Java está lleno de vulnerabilidades

¿La verdad?

Cuando se trata de aplicaciones Java que comen ram. Bueno ... yo diría que tenemos que establecer los valores adecuados para Xmx. Hecho.

Ahora hay muchas fuentes que hablan sobre las muchas vulnerabilidades de Java. Estas fuentes apuntan principalmente a los usuarios finales que ejecutan cierto sistema operativo de una compañía en Redmond / EE. UU. AFAIK puede ser cierto para las versiones no parcheadas del Java Browser Plugin que está configurado para ejecutar todos los applets automáticamente, que hay muchas posibilidades de ser víctima de una unidad por infección. Del mismo modo que existe el riesgo de contraer una ETS al tener relaciones sexuales sin protección con cualquier persona en su tren mientras viaja al trabajo.

Pero no pude encontrar a nadie en la red mundial que hablara de aplicaciones de servidor o JRE que funcionen sin cabeza. Eso es otra cosa.

¿O me estoy perdiendo algo aquí?

[edit 2014-08-28] aclaración: solo me preocupa Java en los servidores. No me importan los problemas con el complemento de Java y / o el software específico desarrollado en Java.

— lajuette
fuente

77

Si el hardware en el que se encuentra tiene poca potencia demostrable y causa problemas, entonces, junto con las preocupaciones de las SA, seguramente tiene un caso comercial para obtener nuevo hardware.

— user9517

44

Convénzalo de que no es el código de tu empresa lo que acaba de ver en thedailywtf.com.

— Michael Hampton

99

Java tuvo un año difícil en 2013. Incluso hubo un sitio web que realizaba un seguimiento de las vulnerabilidades de 0 días, ya que seguían desplegándose. Desde mediados del año pasado no ha habido exploits de 0 días, pero los investigadores aún han encontrado 107 Java CVE solo este año. Eso es un largo camino desde "seguro".

— Chris S

55

¿Puedo activar un error de JVM alimentando datos maliciosos a su aplicación? Es mejor que lo creas. Y bastantes de esos CVE se relacionan con la ejecución de Java en servidores, no con el complemento habitual del navegador de escritorio de Windows.

— Michael Hampton

3

@lajuette Proporcioné un enlace con el número 107 por una razón: si hubiera hecho clic en él, todas esas preguntas que acaba de hacer habrían sido respondidas. Algunos de esos 107 están relacionados con implementaciones que no son de Oracle, como Dalvak de Android, pero la gran mayoría están relacionadas con la implementación de Oracle. Java no es inherentemente inseguro, pero el JRE de Sun / Oracle está plagado de problemas. PHP, Perl, Ruby también tienen vulnerabilidades, ninguna de ellas es perfecta. No podría decir si Java es mejor o peor que los actuales, pero durante el último año definitivamente ha sido el chico de la industria de la seguridad.

— Chris S

18

La superficie de seguridad adicional que Java pone en su entorno es compleja, y es importante no ignorarla o intentar simplificarla.

En primer lugar, existe el horrible historial que tiene el JRE de tener errores de seguridad. Es difícil señalar uno específico, y esta es la parte que da miedo: los errores son vulnerabilidades abrumadoramente no especificadas con vectores no especificados.

Cuando yo, como consultor de seguridad, leo cláusulas como "permite a un atacante remoto" sin mayor calificación en cuanto a su significado, veo que muy bien podría significar que ciertos parámetros que entran en una determinada función podrían invocar la condición vulnerable, incluso si usted solo están ejecutando el código que escribiste. Y, como no están especificados, no puede saber si fue afectado.

Aún mejor, el JRE canónico publicado por Oracle tiene un ciclo de actualización trimestral establecido para actualizaciones críticas, incluidas casi todas las actualizaciones de seguridad. Han creado parches fuera de ciclo un total de 11 veces en los últimos cuatro años. Esto significa que existe la posibilidad de que pueda ser vulnerable a un error de seguridad hasta tres meses después de que se informe antes de tener alguna forma de solucionarlo.

Hay otros problemas con Java que no voy a abordar aquí, pero realmente, parece que hay una preocupación justificable, especialmente para un servidor multipropósito. Si tiene que ejecutar tales cosas, al menos debe hacer una VM de un solo propósito y aislarla de otras cosas.

En particular, si hay un control remoto en el JRE que permite a un atacante obtener RCE, y otro en PHP que hace lo mismo, y otro en Ruby que hace lo mismo nuevamente, debe parchear los tres. Los tres parecen algo probables, a medida que pasan estas cosas, y el atacante puede elegir el que sea más conveniente y luego ser dueño de todo el servidor. Es por eso que deberíamos usar máquinas virtuales para separar el software, especialmente el software defectuoso, como los marcos de lenguaje administrados, y especialmente aquellos que agrupan parches de seguridad solo cuatro veces al año y son propiedad de un proveedor que afirma ante toda evidencia de que son un modelo de seguridad.

Para actualizar, aquí hay algunos CVE que seleccioné de la búsqueda de CVE vinculada de ChrisS, a modo de demostración.

Y mi favorito, desde que estuve allí:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1488

Eso es solo una pequeña muestra, por cierto.

— Falcon Momot
fuente

6

Las aplicaciones Java se comen toda mi RAM

La alternativa al uso de RAM es desperdiciar RAM. No puedes guardarlo para más tarde.

Java está lleno de vulnerabilidades

Eso realmente no importa porque no vas a exponer la JVM al mundo. Supongo que no ejecutará ningún programa hostil, y si lo hace, Java es más seguro que la mayoría de los otros lenguajes. Lo que importa es si sus aplicaciones tienen vulnerabilidades.

— David Schwartz
fuente

3

Bien, entonces la razón no funciona. ¿Qué otras herramientas hay en su caja de herramientas de persuasión? ¿Tienes alicates oxidados?

— David Schwartz

1

@FalconMomot Sí, el núcleo puede usarlo para almacenar en caché los archivos. El núcleo puede quitarle memoria a la JVM si le da un mejor uso. Así es como funciona casi todo sistema operativo moderno. La alternativa al uso de RAM es desperdiciar RAM. El sistema operativo tiene un administrador de memoria específicamente para garantizar que la RAM sea el mejor propósito. Argumentos como "Las aplicaciones Java se comen toda mi RAM" casi siempre indican un administrador que no entiende cómo los sistemas operativos modernos usan RAM.

— David Schwartz

1

Si la JVM no libera la memoria, tiene que cambiarla al espacio de intercambio (si tiene alguna) para hacer esto, que es lento. El núcleo no puede invocar al recolector de basura. Además, el almacenamiento en caché de archivos suele ser de menor prioridad que las asignaciones de espacio de usuario, incluso si rara vez se utilizan (tanto como el núcleo puede decir que rara vez se utilizan, lo que no está muy bien).

— Falcon Momot

3

Quiero saber más acerca de cómo Linux puede usar simultáneamente un bloque de RAM para caché mientras un proceso todavía cree que es el propietario. Nunca he oído hablar de esto antes.

— Michael Hampton

1

@FalconMomot El kernel no necesita saber que la RAM es "gratuita". El kernel siempre tiene control sobre el uso de RAM a menos que la aplicación bloquee las páginas. Solo tiene que hacer que las páginas asignadas sean descartables para recuperar la RAM. Si los datos no se modifican ni se usan durante un período de tiempo, y el ancho de banda de E / S no está saturado, puede escribirlo de manera oportunista para intercambiarlo, haciendo que las páginas sean descartables, lo que le permite recuperar la RAM tan pronto como tenga un mejor uso para ello. (Este espacio no es lo suficientemente grande como para explicar cómo funciona la administración moderna de la memoria, pero parece que tiene algunas ideas falsas muy comunes.)

— David Schwartz

2

Contrata una empresa para hacer análisis estáticos en tu programa. Veracode, por ejemplo, es una compañía que he usado en el pasado para auditar la seguridad del código de los programas Java, específicamente.

Factura el código de carga de tu equipo de administración, obviamente.

— mfinni
fuente

1

Explique que todos los demás lenguajes (o máquinas virtuales) pueden volverse inseguros por el código que se implementa en ellos, al igual que con Java. Si cree que las otras plataformas son inherentemente seguras (o más seguras que Java) sin una seguridad de dirección correcta, entonces está delirando.

Obviamente, su empresa invirtió en la contratación de un desarrollador de Java, ¿por qué el administrador del sistema se niega a admitir una tecnología que la empresa decidió utilizar?

Daría la vuelta a la pregunta y le preguntaría qué alternativas propone y cómo son más seguras que el último Servidor JRE disponible, en términos muy específicos. Mientras tanto, trabaje para mostrarle que comprende su tecnología, la posible superficie de ataque y que ha trabajado para minimizarla (por ejemplo, marcos innecesarios, código de terceros, etc.). Verifique su código, busque vulnerabilidades publicadas para los marcos en los que confía en los últimos X años, compárelo con otros lenguajes / marcos (asegúrese de incluir también la participación en el mercado, los marcos oscuros sin vulnerabilidades publicadas no significan nada).

No podemos saber cómo ocurrió toda la conversión entre ustedes dos, pero si esos fueron sus dos argumentos, creo que está tratando con un administrador de sistemas junior. ¿Tiene experiencia con servidores de aplicaciones Java? Quizás esté incómodo con la tecnología y tenga miedo de poner algo en producción sin comprenderlo a fondo (buena actitud del administrador de sistemas, entonces).

— Giovanni Tirloni
fuente

Gracias. No estamos hablando de una empresa. Más bien una asociación sin fines de lucro. Out sysadmin tiene un doctor en informática y marketing, pero no es un administrador de sistemas "real". Y sí: creo que le tiene miedo a Java, que no comprende completamente.

— lajuette