Descripción

Vulnerabilidad de Java que permite ataques por medio de red sin autentificar, es decir, pueden recibir ataques sobre la red sin necesidad de un usuario o password. Un ataque exitoso en este punto puede impactar directamente la disponibilidad, haciendo que el JRE quede colgada y entre en repetidas veces a Crashes (COMPLETE DENIAL OF SERVICE). Los servidores de aplicación y web basados en Java están en riesgo por esta vulnerabilidad.

Productos afectados

Versiones afectadas: 6 Update 23 y anteriores, 5.0 Update 27 y anteriores, 1.4.2_29 y anteriores.

Java SE

JDK and JRE 6 Update 23 and earlier for Windows, Solaris, and Linux

JDK 5.0 Update 27 and earlier for Solaris 9

SDK 1.4.2_29 and earlier for Solaris 8

Java for Business

JDK and JRE 6 Update 23 and earlier for Windows, Solaris and Linux

Java Virtual Machine Strategy

Hotspot o jRockit

Este dilema existe desde la adquisición de Sun por parte de Oracle. En la presentación adjunta, Paul Hohensee, JVM Technical Lead y Henrik Ståhl, Sr Director Product Management, nos dan una visión de la estrategia para el futuro de la Java Virtual Machine.

Enfoca ampliamente en a partir de lo mejor de ambas VM's y generar una con capacidades extremas para cualquier segmento de mercado, desde pequeña instancias hasta aplicaciones que requieran el poder del "Deterministic GC" o "Garbage First".

En lo particular, mi primer contacto con el mundo de java fue con Hotspot del extinto Sun y me gustaría puntualizar las siguientes ventajas:

• Hasta 32G utilizando compresión de apuntadores
• La versión x64 de JVM es más rápida que 32-bits x86.
• Mejoras en arquitectura NUMA (Non Uniform Memory Architecture).
• Optimización en concatenación de Strings

• ¿Qué es un OOP y por qué debe de comprimirse?

  Un "oop" u "ordinary object pointer" es un apuntador que administra a objeto. Este es normalmente del mismo tamaño que los apuntadores de la maquina en que reside, esto quiere decir que si es un sistema LP64, 64bits será el tamaño. Como sabemos, en un sistema ILP32 la cantidad máxima de heap que se puede utilizar es menos de 4G, pero por otro lado en un sistema operativo de 64 bits se puede instanciar 5 veces o más dependiendo de cuándo se requiera. Pero, por qué sucede la diferencia de tamaño en uso de memoria? sencillo, por el tamaño de los apuntadores administrados.

Generalmente cuando tenemos problemas, empezamos a buscar herramientas poco comunes para encontrar la causa o causas raices de la situación (actitud reactiva). En fin, el problema que se nos presentó en su momento fue en una aplicación que autentica Vs un directorio Novell, utilizando el standar LDAP. Sin embargo, la librería que se utiliza para esta actividad, es propietaria de la aplicación y contiene un bug que en cada cierto número de petición genera threads nuevos para atenderlas y cuando la petición fue concluída, el thread permanece con estado ALIVE y espera hasta una recolección de basura (FGC) para ser eliminado. "WRONG", es un leak en el heap de java pues se desperdicia una cantidad considerable de memoria y tiempo de ejecución del GC, cuando hablamos de instancias de Java de 32G.

En la siguiente gráfica (Cacti) muestra el comportamiento de los Threads vs FGC:

La solución fue hacer un switch del módulo LDAP a OpenLDAP que sorprendentemente no presentaba el problema.

La versión jdk 1.6u21_b06 contiene el bug “6948537 CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT” que sus consecuencias son considerables si se requiere una aplicación completamente disponible ante la demanda de los usuarios, pues al fallar el Concurrent Marked Sweep garbage collector, ocurre un “Error Fatal” haciendo que se genere un volcado de memoria que tira la aplicación. La razón según información de Oracle,

BOT bulk-updates use memset(). However on Niagara memset() uses BIS for speed and this exposes concurrent readers to out-of-thin-air zeroes, which are fatal for concurrent BOT walks. Such concurrent reads of BOT entries subject to concurrent update are possible with non-contiguous spaces such as CMS (but not any other current GC in HotSpot).

El workaround que menciona el reporte del bug es configurar una variable de ambiente en el profile de Unix:

Después de hacer una investigación con los comandos strings, grep -v, etc. pudimos obtener la lista de opciones con su parámetro (las que apliquen) que se incluyeron en el nuevo update de la versión 6 de Java. Espero les sirva:

El ambiente analizado lo componen 15 servidores Solaris, 1 base de datos Oracle 10gr2, 14 instancias de una aplicación Java que reside en Tomcat v5 y finalmente la capa de red, routers y switches Cisco que van desde el gateway hasta el site.

Servidor de monitoreo: Hardware: Laptop IBM (politics), Software:Cacti, OS: Ubuntu 9.1.

Primero que nada se debe dejar claro que el término "conexiones por segundo" es inválido cuando se habla de un protocolo connection-less como SNMP v1 y v2c. No hay conexión establecida entre el servidor y el cliente cuando un request de SNMP es hecho. No existe un "three-way handshake" TCP SYN/SYN-ACK/ACK, por lo tanto no hay conexiones que rastrear.

Para la versión SNMPv1 y v2c, el servidor de monitoreo Cacti hace un request de un sólo paquete UDP y recibe de igual manera, un paquete SNMP de respuesta por cada valor que solicite por el agente SNMP.

Se llegan a tener "threads deadlocks" que impactan en performance a la aplicación (si nos va bien) o pueden consumir toda la memoria y hasta tirar la JVM.

Para localizar estas situaciones, primero se tiene que identificar el PID de la JVM:

Adjuntar jstack al id del proceso identificado anteriormente:

La tecnología JMX provee de la capacidad para implementar herramientas de monitoreo y administracion distribuída, por web, modular y hasta dinámica de dispositivos, aplicaciones y servicios orientados a la red. Documentación adicional.

20091122. Es importante mencionar que la utilización de esta herramienta de monitoreo se vuelve INTRUSIVA al generar TRHEADS en cada solicitud de información.

La administración remota con JMX se puede activar de diferentes maneras dependiendo de la aplicación. Asumamos que se tiene una instalación standalone de Tomcat en su versión 5 y se requiere medir el performance de la JVM, por lo tanto se tendrán que agregar los siguientes parámetros(básicos) a la variable de entorno JAVA_OPTS:

Entonces, la variable de ambiente estaría integrada de la siguiente forma:

* Unix:
 

Strings es un comando que tiene como finalidad obtener las cadenas imprimibles en un objeto o archivo binario. En este caso utilizaremos este comando para obtener las Opciones de la máquina virtual de java, que residen en el objeto compartido libjvm.so y para eso, necesitaremos de los siguientes puntos:

• Ubicación del SO libjvm. Se puede encontrar con el comando find: find / -name libjvm* -print
• Comando Strings instalado. En las distribuciones GNU/Linux y Solaris, generalmente están activas.
• Opción específica de la JVM a buscar. En este ejemplo utilizaremos AlwaysPreTouch (Versión válida a partir de la versión 6).

Hay que ubicarse en el directorio donde se encuentra el SO.

$ cd $JDK_HOME/jre/lib/sparc

En este caso SPARC por la arquitectura del procesador.

Asegurar que el SO se encuentre.

Usar Strings para encontrar la opción. (versión 6)