Vulnerabilidades

Todas las versiones anteriores a 3.7.0.

Mediana

Al establecer una conexión backend con la JVM, las versiones anteriores del Wrapper asumían un nivel razonable de confianza en los procesos que se ejecutaban en el entorno local. Si bien la conexión estaba autenticada, dependía de una clave expuesta en la línea de comandos. Existía un breve lapso de tiempo durante el cual un proceso malicioso podría capturar la clave y ganar una condición de carrera conectándose antes que la JVM.

En Windows, el riesgo de captura de claves era limitado, ya que la clave solo estaba expuesta a procesos que se ejecutaban con la misma cuenta de usuario o con privilegios de administrador. Sin embargo, existía el riesgo de apropiación indebida de la tubería (pipe squatting): un atacante podría crear la tubería con nombre de forma preventiva antes que el Wrapper, impidiendo que se estableciera la conexión legítima.

Estas vulnerabilidades son especialmente preocupantes en sistemas multiusuario donde usuarios no confiables tienen derechos de ejecución local, o en entornos que ya han sido comprometidos. Si se explotan, el atacante local podría provocar una denegación de servicio (impidiendo que la JVM se conectara), interceptar datos confidenciales que se transmiten entre el Wrapper y la JVM o, en ciertos casos, enviar un identificador de proceso (PID) falso para engañar al Wrapper y lograr que finalice un proceso no deseado.

A partir de la versión 3.7.0, el Wrapper ha adoptado una postura de seguridad más estricta que ya no presupone un entorno local de confianza. Para establecer un canal verdaderamente seguro con la JVM, se han rediseñado varios aspectos de la comunicación con el servidor, desde la creación del canal hasta la autenticación y la verificación de la integridad de los datos.

Los cambios más notables son:

• El tipo de conexión de backend predeterminado se ha cambiado a PIPE, que es intrínsecamente más seguro que los sockets TCP/IP para la comunicación uno a uno entre procesos.

• En Windows, las medidas de seguridad adicionales impiden el acceso no autorizado a las tuberías y los ataques de denegación de servicio, reforzadas por la validación del PID y el SID (Identificador de Seguridad) durante la autenticación de procesos entre pares.

• Para todos los tipos de conexión, la clave de autenticación, que antes se pasaba como una propiedad del sistema de línea de comandos (-Dwrapper.key), ahora se entrega exclusivamente al proceso Java iniciado y se genera con una entropía criptográfica más robusta, lo que reduce el riesgo de divulgación o adivinación.

• El ciclo de vida de la conexión se ha rediseñado para rechazar y omitir los intentos de conexión no autorizados (garantizando la disponibilidad para el proceso legítimo) y para restablecerse correctamente si es necesario reiniciar la JVM.

• Ahora se verifica rigurosamente la integridad del PID del cliente informado (así como los PID de los procesos secundarios para la Edición Profesional) recibidos a través de la conexión establecida para evitar la terminación no autorizada del proceso.

• En los sistemas Unix, los descriptores de archivo de canal de backend ya no son heredados por subprocesos no relacionados, lo que elimina un posible vector de interferencia.

• Actualizar a la versión 3.7.0 o superior del Wrapper.

• Hasta que se pueda realizar una actualización, considere las siguientes medidas de mitigación aplicables en sistemas Unix:

  • Al ejecutar la versión 3.6.0 o posterior del Wrapper (véase la vulnerabilidad #13), utilice wrapper.backend.type=PIPE. Dado que las tuberías anónimas dependen de descriptores de archivo que son heredados exclusivamente por los procesos secundarios, la conexión está inherentemente protegida de procesos locales no relacionados, incluso si la clave de autenticación es visible.

  • Asegúrese de que el endurecimiento del sistema operativo esté configurado para ocultar las líneas de comando de los procesos a los usuarios sin privilegios. Los mecanismos varían según la plataforma (por ejemplo, hidepid para /proc en Linux o security.bsd.see_other_uids=0 sysctl en FreeBSD). Tenga en cuenta que algunos sistemas operativos restringen esta visibilidad de forma predeterminada.

• Asegúrese de que la máquina que aloja el Wrapper restrinja el acceso de ejecución local únicamente a usuarios de confianza.

Todas las versiones anteriores a 3.6.3.

Advertencia

Las aplicaciones que usan la versión 3.5.16 o superior del Wrapper pueden establecer wrapper.disable_tests en TRUE para bloquear el uso indebido potencial de las funciones de las pruebas. Si no se aplica esta configuración, el riesgo de seguridad es alto para las aplicaciones que permiten el código de ejecución no verificado, y potencialmente malicioso.

La clase WrapperManager expone varios métodos diseñados para probar fallas comunes de la aplicación. Si bien es útil para las pruebas, estos métodos pueden representar un riesgo de seguridad si se invoca con código no confiable en tiempo de ejecución.

El Wrapper ha admitido el uso de un Administrador de Seguridad para controlar el acceso a estas y otras funcionalidades desde versiones muy tempranas. Sin embargo, el Administrador de Seguridad rara vez es utilizado por los desarrolladores y, por lo tanto, estaba en desuso desde Java 17, y luego se deshabilitó en el inicio desde Java 24.

Como alternativa, la propiedad wrapper.disable_tests se introdujo en la versión 3.5.16 para deshabilitar globalmente los métodos de prueba. Sin embargo, su valor predeterminado fue FALSE en todas las versiones antes de 3.6.2, lo que significa que la propiedad tenía que ser agregada explícitamente a la configuración y establecerse en TRUE para ser efectiva.

Si no se utiliza ni el Administrador de Seguridad ni la propiedad wrapper.disable_tests para restringir el acceso, un código no confiable que se ejecuta dentro de la aplicación (como un complemento malicioso o comprometido, un archivo JAR o un módulo cargado dinámicamente) podría invocar estos métodos, lo que causaría problemas como ralentizaciones o bloqueos, lo que lleva a una condición de denegación de servicio (DoS).

La versión 3.6.3 mejora la postura de seguridad predeterminada cambiando el valor predeterminado de wrapper.disable_tests a TRUE, registrando una advertencia cuando la propiedad se establece explícitamente en FALSE y agregando medidas para evitar la ejecución no confiable de cualquier función de prueba dentro de la JVM.

• Añadir wrapper.disable_tests=TRUE a su archivo de configuración (si la versión del Wrapper es 3.5.16 o superior), o

• Actualizar a la versión 3.6.3 o superior del Wrapper.

• Como guía general para el diseño de aplicaciones seguras, restrinja siempre la carga de complementos y módulos a código confiable y verificado.

De la versión 3.5.8 a la versión 3.5.60.

Crítica (si se pasan datos sensibles a través del backend, lo cual es posible desde la versión 3.5.57, y si el backed se establece en PIPE)

Al utilizar la propiedad wrapper.backend.type=PIPE, el Wrapper creaba tuberías con nombre con permisos demasiado abiertos. Las ediciones de Windows no se ven afectadas y pueden usar PIPE con seguridad.

Había un problema de seguridad cuando se las propiedades wrapper.app.property para pasar datos confidenciales a través del backend, ya que era posible que cualquier usuario con acceso al servidor viera el contenido de la tubería.

El tipo de transmisión predeterminado utiliza SOCKET, que no tiene este problema.

• Utilizar wrapper.backend.type=SOCKET, o

• Actualizar a la versión 3.6.0 (o superior) del Wrapper, que utiliza(n) tuberías anónimas con permisos adecuados.

Todas las versiones anteriores a 3.5.58.

Advertencia

Para garantizar la compatibilidad con versiones anteriores de Windows, Microsoft ha decidido habilitar SeImpersonatePrivilege de forma predeterminada para los servicios de Windows. Este privilegio lo añade automáticamente el administrador de control de servicios (SCM) mediante la adición dinámica del grupo SERVICE al iniciar un servicio.

El privilegio SeImpersonatePrivilege permite a un proceso impersonar a otro usuario. Si bien esto puede ser útil para probar el comportamiento del proceso en diferentes contextos de usuario, también puede suponer riesgos de seguridad significativos. De hecho, se puede abusar del privilegio para escalar a la cuenta LocalSystem, que tiene el nivel de privilegios más alto en un sistema Windows.

Este problema de seguridad solo afecta a los servicios configurados para ejecutarse con una cuenta distinta a LocalSystem (de lo contrario, el servicio ya cuenta con los privilegios más altos). Sin embargo, suele ser recomendable ejecutarse con una cuenta de servicio dedicada para restringir el acceso a la aplicación Java en el sistema de alojamiento y, a la vez, evitar que otros procesos de terceros accedan a la aplicación y a los archivos del Wrapper.

A partir de la versión 3.5.58, el Wrapper deshabilitará SeImpersonatePrivilege al ejecutarse como un servicio de Windows con una cuenta distinta a LocalSystem (NT AUTHORITY\SYSTEM). La mayoría de las aplicaciones Java no necesitarán este privilegio, pero, en caso de necesitarlo, se puede usar la propiedad wrapper.ntservice.impersonation para reactivarlo.

• Actualizar a la versión 3.5.58 o superior del Wrapper, o

• Configurar los privilegios requeridos para el servicio (requiere la edición Profesional, versión 3.5.57 o superior).

• Es posible editar la configuración de la Política de seguridad local, pero existe el riesgo de afectar otros servicios (no se recomienda).

Todas las versiones anteriores a 3.5.58.

Alta (si se cumplen las condiciones siguientes).

La API del Wrapper proporciona el método WrapperManager.log() para permitir que el código de usuario registre un mensaje en el nivel de registro especificado. Si el segundo argumento (el mensaje a registrar) contiene un carácter "%", el Wrapper podría bloquearse y causar una denegación de servicio.

Su aplicación está en riesgo si utiliza entradas de usuario que al final se pasan al método WrapperManager.log().

• Actualizar a la versión 3.5.58 o superior del Wrapper, o

• Asegurarse de eliminar cualquier signo '%' en el mensaje a registrar antes de llamar a WrapperManager.log().

3.5.55

Advertencia

Binarios de Windows no firmados.

Por favor, utilize la versión 3.5.56, que está firmada con un certificado EV mejorado.

Versiones 3.5.44 y 3.5.45.

Advertencia

El archivo jar está firmado con un certificado de firma de código antiguo (que vence el 2020-12-15, pero con una marca de tiempo válida hasta 2027-06-27).

El archivo jar se puede ejecutar de forma segura.

No se requiere ninguna acción especial.

Versión 3.5.44.

Mediana

Los binarios de Windows (wrapper.exe, wrapperw.exe, wrapper.dll) no están firmados digitalmente.

Aunque la falta de firma no representa en sí misma una amenaza para la seguridad, no es posible verificar la autenticidad e integridad de los binarios sin una firma digital. Por lo tanto, Microsoft Defender SmartScreen podría bloquear la primera ejecución y advertir de un riesgo de seguridad.

• Actualizar a la versión 3.5.45 o superior del Wrapper.

• Asegúrese siempre de descargar los binarios de Wrapper del sitio web oficial del Java Service Wrapper y guardarlos en un lugar seguro donde no se puedan alterar.

Versiones entre 3.5.35 y 3.5.40.

Alta (cuando se utiliza wrapper.lang.windows.encoding)

A partir de la versión 3.5.35, wrapper.lang.windows.encoding permite cambiar la codificación regional utilizada por el proceso Wrapper. Esto es útil, por ejemplo, para imprimir la salida del registro en UTF-8 o con una codificación específica.

Cuando se establece la propiedad wrapper.lang.windows.encodin, el Wrapper lee la salida de la JVM en un modo diferente. Este modo presenta un error: un carácter de porcentaje '%' en la salida de la JVM podría provocar un bloqueo del Wrapper.

Su aplicación está especialmente expuesta si la entrada del usuario del cliente puede aparecer en los registros, lo que la hace vulnerable a ataques de denegación de servicio.

• Actualizar a la versión 3.5.41 o superior del Wrapper, o

• Comentar wrapper.lang.windows.encoding o configurar a su valor predeterminado (ANSI).

3.5.35

Alta

La propiedad wrapper.lang.windows.encoding permite cambiar la codificación de la configuración regional utilizada por el proceso del Wrapper. Las cadenas UTF-8 se gestionan con una función independiente que utiliza un búfer de tamaño fijo de 4096 caracteres. Una salida de la JVM superior a este ancho provocaría un desbordamiento del búfer.

Su aplicación corre un riesgo especial si las entradas de usuario de gran tamaño pueden acabar en los registros, ya que podrían provocar un bloqueo del Wrapper y una denegación de servicio.

El Wrapper no se ve afectado si wrapper.lang.windows.encoding se mantiene con su valor predeterminado "ANSI" ni si se utiliza una codificación distinta a UTF-8.

• Actualizar a la versión 3.5.41 o superior del Wrapper, o

• Configurar wrapper.lang.windows.encoding en un valor diferente de UTF-8.

De 3.5.8 a 3.5.11.

Crítica

En plataformas UNIX, la máscara de usuario (umask) predeterminada se establece en 0000 en lugar de heredar el valor del proceso principal al ejecutarse como un proceso demonio.

El registro y otros archivos tienen acceso global de lectura y escritura.

La umask predeterminada del proceso Java también sería 0000, y por lo tanto, de cualquier archivo creado por la aplicación Java, a menos que se establezcan nuevos permisos explícitamente.

El archivo de anclaje, si se utiliza, puede ser eliminado por cualquier persona y provocar la detención del Wrapper.

• Actualizar a la versión 3.5.12 o superior del Wrapper, o

• Configurar la propiedad wrapper.umask a un valor seguro.

Todas las versiones anteriores a 3.3.7.

Advertencia

Una política de seguridad estricta de SELinux podría impedir que el Wrapper cargara la biblioteca libwrapper.so.

Esto solo es un problema cuando se ejecuta en un sistema con SELinux habilitado.

• Actualizar a la versión 3.3.7 o superior del Wrapper.

Todas las versiones anteriores a 3.3.0.

Alta

Ocasionalmente pueden ocurrir fallas con UNIX de 64 bits causadas por un problema de sincronización nativo cuando las señales del sistema quedan atrapadas. Error #1614010.

Esta vulnerabilidad se podría utiizar por procesos de terceros para intentar ataques de denegación de servicio.

Ni los binarios de 32 bits ni Windows se ven afectados.

• Actualizar a la versión 3.3.0 o superior del Wrapper, o

• Utilizar wrapper.ignore_signals=TRUE (no se recomienda).

De 3.0.0 a 3.1.2, y luego de 3.2.2 a 3.2.3.

Alta

Los valores de wrapper.ntservice.account y wrapper.ntservice.password se almacenaban en texto sin formato dentro del registro si se especificaban en la línea de comandos al instalar el Wrapper como un servicio de Windows.

• Error #1538725

• Error #1110183

• Actualizar a la versión 3.1.2 o superior del Wrapper.

• No especifique wrapper.ntservice.account o wrapper.ntservice.password en la línea de comandos al intalar el Wrapper como in servicio de Windows.

Todas las versiones anteriores a 2.2.6.

Alta

Un signo de porcentaje '%' en la salida de la JVM podría provocar que el Wrapper se bloquee.

Su aplicación está especialmente expuesta si la entrada del usuario cliente puede acabar en los registros, haciéndola vulnerable a ataques de denegación de servicio.

• Actualizar a la versión 2.2.6 o superior del Wrapper.