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.
Respuestas:
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í:
Eso es solo una pequeña muestra, por cierto.
fuente
La alternativa al uso de RAM es desperdiciar RAM. No puedes guardarlo para más tarde.
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.
fuente
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.
fuente
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).
fuente