De acuerdo con LWN, existe una mitigación que se puede usar mientras no tenga un kernel parcheado:
hay una mitigación disponible en forma de tcp_challenge_ack_limit sysctl mando. Establecer ese valor en algo enorme (por ejemplo, 999999999 ) hará que sea mucho más difícil para los atacantes explotar la falla.
Debe configurarlo creando un archivo en /etc/sysctl.d y luego implementarlo con sysctl -a . Abra una terminal (presione Ctrl +Alt +T ), y ejecuta:
sudo -i
echo "# CVE-2016-5696
net.ipv4.tcp_challenge_ack_limit = 999999999
" > /etc/sysctl.d/security.conf
sysctl -a
exit
Por cierto, puede rastrear el estado de esta vulnerabilidad en Debian en el rastreador de seguridad.
Etiquetó esta pregunta como debian, por lo que asumiré que está ejecutando un sistema Debian basado en Linux.
El parche relevante que corrige este error es pequeño y relativamente aislado, lo que lo convierte en un candidato ideal para la adaptación.
Por lo general, Debian es bastante bueno para respaldar las correcciones relacionadas con la seguridad de las versiones de software que se envían en las versiones de distribución compatibles. Su lista de avisos de seguridad para 2016 incluye actualmente ocho avisos de seguridad relacionados con el kernel de Linux (linux y linux-2.6 paquetes), el más reciente fue DSA-3616 el 4 de julio. El parche para el error que menciona se envió al árbol de código fuente una semana después, el 11 de julio.
El soporte de seguridad para Wheezy está con el equipo LTS (Soporte a largo plazo) hasta el 31 de mayo de 2018, y Jessie actualmente recibe actualizaciones de seguridad normales en virtud de ser la versión actual.
Esperaría un parche de seguridad pronto contra las versiones compatibles de Debian que sufren este error.
También es posible que los núcleos enviados por Debian no sean vulnerables. El CVE lo hace diga "antes de 4.7", pero dudo que la declaración pueda tomarse literalmente; el código relevante probablemente no se introdujo en la primera versión pública del kernel de Linux (en 1991 más o menos), por lo que lógicamente deben existir versiones del kernel que cumplan con los criterios de ser anteriores a la versión 4.7 pero que no sean vulnerables. No he comprobado si esto se aplica a los núcleos que se envían con las versiones actuales de Debian.
Si está ejecutando una versión de Debian no compatible que es vulnerable a este error, o si necesita una solución inmediata, es posible que deba realizar una copia de seguridad de la solución manualmente o actualizar a una versión más reciente al menos del propio kernel.