Revelación de información sensible en Apache Tomcat

Apache Software Foundation ha hecho pública la resolución de una nueva vulnerabilidad en Apache Tomcat. Esta vulnerabilidad con el CVE-2011-2729 (afecta a las versiones 5, 6 y 7), y queda definida con un nivel de severidad de "Importante" al permitir la revelación de información sensible.

Apache Tomcat es un servidor web que funciona como contenedor de servlets, desarrollado en código abierto por la Apache Software Foundation. Tomcat implementa las especificaciones de las tecnologías servlets Java y de páginas JSP.

Debido a un error en las políticas de seguridad del servicio jsvc se permitiría a las aplicaciones web tener acceso a ficheros y directorios pertenecientes al superusuario.

Esta situación sólo se daría si la instalación de Tomcat está bajo un sistema operativo Linux, el servicio jsvc fue compilado con libcap y se utilizó el parámetro -user.

Se recomienda actualizar Tomcat y aplicar las contramedidas necesarias:

Versiones afectadas
* Tomcat 7.0.0 a 7.0.19
Actualizar a la versión ya disponible 7.0.20:
http://tomcat.apache.org/download-70.cgi

* Tomcat 6.0.30 a 6.0.32 y Tomcat 5.5.32 a 5.5.33
Utilizar las contramedidas disponibles hasta que se hagan públicas las
nuevas versiones (6.0.33 y 5.5.34 respectivamente):
* Actualizar el servicio jsvc a la versión 1.0.7 o posterior.
* No utilizar el parámetro -user para cambiar de usuario
* Recompilar el servicio jsvc sin libcap.

Más información:

Fixed in Apache Tomcat 7.0.20
Important: Information disclosure CVE-2011-2729
http://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.20

Apache Tomcat - Security Updates
http://tomcat.apache.org/security.html


FUENTE: HispaSec

Tomcat y su memoria

Hoy hemos tenido una situación un poco molesta: un mailing masivo de un cliente ha tenido la web a punto de caerse durante media mañana. Y es que la aplicación necesita una cantidad bestial de memoria... y no la tenía asignada.

Simplemente he tenido que cambiar este parámetro, y la cosa ha ido mucho más fluida.

Así que si alguna vez tenéis que hacerlo, ahí va el cómo.

El parámetro a modificar es Xmx, y hay que modificarlo desde el binario que arranca el demonio (en linux). Es simplemente localizarlo y cambiar el valor que tiene a continuación

Servidor:/var/lib/tomcat5/conf# grep -ir Xmx /etc/init.d/tomcat5
CATALINA_OPTS="-Djava.awt.headless=true -Xmx128M"

En mi caso (es la configuración por defecto) estaba a 128Mb. Y lo he subido a 512.

Pues nada, después de hacer la modificación reiniciamos el tomcat (no vale un reload porque sólo carga la configuración, no para y arranca el proceso) y ya lo tenemos.
Ah! y además de verse en el script, también se ve con un ps:

Servidor:/var/lib/tomcat5/conf# ps aufx | grep tomcat

tomcat5 17124 0.0 0.0 7696 1768 pts/0 S 11:27 0:00 \_ /usr/sbin/rotatelogs /var/lib/tomcat5/logs/catalina_%F.log 86400
tomcat5 17131 73.5 6.1 721564 130332 pts/0 Sl 11:27 0:16 /usr/local/jdk1.6.0_04/bin/java -Djava.awt.headless=true -Xmx512M-Djava.endorsed.dirs=/usr/share/tomcat5/common/endorsed -classpath /usr/local/jdk1.6.0_04/lib/tools.jar:/usr/share/tomcat5/bin/commons-launcher.jar:/usr/share/tomcat5/bin/commons-logging-api.jar:/usr/share/tomcat5/bin/jmx.jar:/usr/local/jdk1.6.0_04/jre//lib/jcert.jar:/usr/local/jdk1.6.0_04/jre//lib/jnet.jar:/usr/local/jdk1.6.0_04/jre//lib/jsse.jar:/usr/share/tomcat5/bin/bootstrap.jar:/usr/share/tomcat5/bin/commons-logging-api.jar -Djava.security.manager -Djava.security.policy==/var/lib/tomcat5/conf/catalina.policy -Dcatalina.base=/var/lib/tomcat5 -Dcatalina.home=/usr/share/tomcat5 -Djava.io.tmpdir=/var/lib/tomcat5/temp org.apache.catalina.startup.Bootstrap start

Ah, por cierto, al igual que hay una variable para la memoria máxima que puede asignarse a tomcat para que la utilice, también hay una memoria mínima. La variable es Xms.

Debian Etch, Apache 2.2.3 y Tomcat 5.5

Os habéis encontrado alguna vez algún problema al instalar la última versión de Apache y de Tomcat en una Etch? Sin compilar me refiero, con el cómodo

apt-get install apache2.2 tomcat5.5

(y aprovecho e instalo el JDK de Sun, me gusta instalar peligrosamente!)
¿Os ha funcionado a la primera? Supongo que a vosotros tampoco. Nuestro problema, una vez nos rompimos la cabeza porque no localizábamos el error de ninguna manera, estaba en el mod_jk, concretamente en la librería que utiliza, mod_jk.so. La verdad es que localizamos el error, descargamos la librería, renombramos y la cosa fue como la seda. Digo que la renombramos porque tiene un nombre que es un carro... Vamos, que haciendo:

root@Tuxxxy:~# wget http://www.signal42.com/mirrors/
/apache/tomcat/tomcat-connectors/jk/binaries/
/linux/jk-1.2.23/mod_jk-1.2.23-apache-2.2.x-linux-i686.so

root@Tuxxxy:~# mv mod_jk-1.2.23-apache-2.2.x-linux-i686.so
mod_jk.so
root@Tuxxxy:~# mv mod_jk.so /usr/lib/apache2/modules/

se nos solucionó la papeleta.

Mañana más!