rsync 3.5.0 corrige 33 CVE y cambia el comportamiento frente a enlaces simbólicos
La actualización ya está en Debian y lo más probable es que llegue al resto de distribuciones en los próximos días: corrige 33 CVE y varias rutas y reglas del demonio dejan de comportarse como antes.
rsync ha saltado a la 3.5.0. La actualización ya está en Debian y lo más probable es que aparezca en el resto de distribuciones en los próximos días, y no es un parche menor: corrige 33 CVE y, de paso, cambia comportamientos que pueden romper instalaciones que hoy funcionan.
El responsable de la actualización en Debian, Samuel Henrique, explica que decidió subir la versión en lugar de aplicar los parches de seguridad uno a uno. Tras revisar el resto de cambios que venían con el salto, concluyó que ese camino entrañaba menos riesgo que la alternativa. El aviso es claro: los cambios de comportamiento no son un efecto secundario del salto de versión, vienen de las propias correcciones de seguridad. La lista completa está en /usr/share/doc/rsync/NEWS.md.gz; aquí van las que más papeletas tienen de romper algo.
Enlaces simbólicos: solo si son de confianza
Las rutas que aporta el operador dejan de seguirse a través de enlaces simbólicos que no sean de confianza. En la práctica, el directorio destino y los argumentos de --backup-dir, --temp-dir, --partial-dir, --link-dest, --compare-dest, --copy-dest, --log-file, --password-file, --files-from, --include-from, --exclude-from, --write-batch, --read-batch y los ficheros merge de --filter se resuelven ahora componente a componente. Solo se sigue un enlace si pertenece a root o al usuario que ejecuta rsync; si es de otro, se rechaza con "refusing to follow a symlink owned by an untrusted user".
Existe una salida: --insecure-links recupera el comportamiento antiguo, pero solo funciona en local y un demonio nunca la respeta. Para un módulo concreto y de confianza, hay que poner "insecure links = yes" en ese módulo.
Además, rrsync rechaza --debug en cualquier invocación. Cuando está restringido a un subdirectorio, deniega --copy-unsafe-links, pasa el nuevo --confine-root para que el servidor no resuelva un fichero merge de filtros nombrado por el cliente fuera de ese directorio, y añade --drop-D al recibir, así que una subida ya no puede crear dispositivos ni ficheros especiales. Un "rsync -a" de toda la vida sigue funcionando.
Otro cambio de matiz: --chmod=a+s ahora pone los bits setuid y setgid, como hace chmod(1); antes solo ponía setuid.
Quién entra en el demonio
rsyncd cambia reglas que deciden quién pasa. "proxy protocol = true" sin "proxy protocol hosts" rechaza ahora todas las conexiones y avisa al arrancar, en lugar de fiarse de la cabecera PROXY que manda el cliente. "hosts deny" falla en cerrado cuando no puede resolver un nombre configurado, así que un host que antes entraba por una entrada de deny irresoluble queda bloqueado. Los valores de "auth users" que empiezan por coma se separan solo por comas, como dice la documentación. Los patrones de "hosts allow" y "hosts deny" pliegan mayúsculas también dentro de una expresión entre corchetes, de modo que [A-Z]* casa con hosts que antes se le escapaban. Y --compress-threads pedido por el cliente se limita a 8.
rsync-ssl ahora verifica el certificado del servidor, y el backend openssl lo ata además al nombre de host solicitado. stunnel y gnutls se niegan a arrancar salvo que esté definida RSYNC_SSL_CA_CERT o se opte por salir del paso con RSYNC_SSL_ALLOW_INSECURE_STUNNEL=1 o RSYNC_SSL_ALLOW_INSECURE_GNUTLS=1.
Merece la pena actualizar pronto, porque 33 CVE son 33 CVE, pero conviene leer las notas antes de dejarlo caer en producción. El riesgo está en las automatizaciones que llevan años funcionando de una manera concreta: un merge de filtros en un directorio con un enlace de otro usuario, o un módulo con proxy protocol, son los sitios donde primero se va a notar.
