🔴 CVE-2025-1098: Fallo crítico en OpenSSL permite ejecución remota sin autenticar

ArtLover

Acabo de leer el aviso de OpenSSL sobre el CVE-2025-1098. Es un buffer overflow en la función de handshake TLS 1.3 que permite RCE sin necesidad de autenticación. Afecta a versiones 3.0.0 a 3.0.12. ¿Alguien ha empezado a parchear sus servidores? En producción tenemos unos 50 endpoints con esa versión y el rollback es complejo. ¿Qué enfoque recomiendan mientras sale el fix oficial?

Pottery

Nosotros ya estamos aplicando workarounds: deshabilitar TLS 1.3 y limitar el handshake a TLS 1.2 en los balanceadores. También hemos bloqueado IPs sospechosas con iptables. El fix de OpenSSL promete parche para la próxima semana, pero no podemos esperar. Importante: verificar que no se rompen conexiones con clientes antiguos.

Designer

No me parece suficiente deshabilitar TLS 1.3. El CVE se explota durante el handshake, pero si el atacante fuerza una downgrade, aún podría ser vulnerable. ¿Han revisado si el balanceador hace downgrade automático? Mejor usar un WAF con reglas específicas para este patrón de ataque. ModSecurity ya tiene una regla experimental.

ArtLover

Gracias por los tips. Lo de deshabilitar TLS 1.3 lo estamos considerando, pero el problema es que algunos clientes corporativos solo negocian con TLS 1.3. Estamos evaluando parchear manualmente la librería con un backport del fix de la rama master. Alguien tiene experiencia compilando OpenSSL con parches parciales sin romper dependencias?

FoodLover

Compilar parches parciales es arriesgado. He visto casos donde el fix introduce otros bugs. Mi recomendación: usar un proxy reverso con nginx o haproxy que termine TLS y reenvíe a los servidores internos. Así solo actualizas el proxy, no cada servidor. Además, el proxy puede filtrar handshakes maliciosos con Lua o scripts.

Opera

También puedes usar tinc o WireGuard para encapsular el tráfico y evitar exponer OpenSSL directamente. No es una solución definitiva, pero reduce la superficie de ataque. Otra opción: si tienes los servidores detrás de una CDN (Cloudflare, Fastly), ellos ya están parcheando sus edge.

ArtLover

Buena idea lo del proxy reverso. Vamos a implementar haproxy con TLS termination y desplegar parche en los balanceadores. De paso, ¿alguien tiene un script para auditar qué versiones de OpenSSL tenemos en la infra? Tenemos muchos contenedores legacy y encontrar todos los afectados manualmente es un dolor.

Drones

Para auditar rápido, puedes usar openssl version -a en cada nodo, pero si tienes muchos, mejor con Ansible: ansible all -m shell -a 'openssl version'. También hay herramientas como Grype o Trivy que escanean imágenes de contenedor y te listan CVEs. Eso te ahorrará tiempo.

Calligraphy

Para auditoría masiva en contenedores, mejor usar 'docker run --rm aquasec/trivy image --severity CRITICAL,HIGH --ignore-unfixed ' y parsear con jq. Si usas Kubernetes, 'kubectl get pods -o json | jq' combinado con trivy en cada imagen. Con Grype también funciona, pero Trivy es más rápido escaneando capas. Y ojo, que si usas Alpine, el paquete openssl se llama libssl3, no openssl.

PC

Buen punto lo de Alpine, pero cuidado: en Alpine el binario openssl sigue existiendo, solo que el paquete se llama libssl3. Para detectar versiones, mejor usar 'apk list -I libssl3' o directamente 'openssl version -v' que funciona igual. Si queréis automatizar con Ansible, un playbook que haga 'openssl version' y 'apk list -I libssl3' cubre tanto Alpine como otras distros. Por cierto, si tenéis contenedores legacy sin actualizar, probad a montar un sidecar con socat que haga proxy TLS y redirija el tráfico al contenedor sin parche, mientras lo actualizáis en caliente. Eso evita downtime.