Un fallo introducido
en la última actualización impide actualizar automáticamente, y una
vulnerabilidad que tiene como impacto la denegación de servicio no será
solucionada.
Primero se publicaba
la versión 4.9.3, solucionando un total de 43 fallos, aunque ninguno de ellos
de seguridad. Como es habitual cada vez que hay una actualización, el anuncio
de la nueva versión al final rezaba:
Sites that support
automatic background updates are already beginning to update automatically.
Pero esto nunca llego
a suceder. Irónicamente, la actualización se publicó con un fallo que impide al
sistema de actualizaciones automáticas seguir funcionando, o lo que es lo
mismo: tras esta instalación, WordPress dejará de actualizarse automáticamente.
Esta funcionalidad se implementó en la versión 3.7, precisamente para dar
respuesta a la gran cantidad instalaciones vulnerables (algunos estudios
afirmaban que suponían el 70% del total).
Para solucionar la
situación, el mismo martes se publicó la versión 4.9.4. Sin embargo, al haber
quedado el sistema inservible, para actualizar se requieren operaciones
manuales por parte del usuario:
Unfortunately
yesterdays 4.9.3 release contained a severe bug which was only discovered after
release. The bug will cause WordPress to encounter an error when it attempts to
update itself to WordPress 4.9.4, and will require an update to be performed
through the WordPress dashboard or hosts update tools.
Esto podría suponer
que muchos sitios queden estancados en la versión 4.9.3 hasta que sus
administradores ejecuten la operación.
Más malas noticias: una denegación de
servicio que no se solucionará
Por si esto fuera
poco, el mismo lunes el investigador Barak Tawily publicaba un artículo donde
describía una vulnerabilidad que afecta a casi cualquier instalación de
WordPress, provocando una denegación de servicio.
La vulnerabilidad se
encuentra en el fichero 'load-scripts.php'. Este se utiliza para pedir al
servidor varios ficheros estáticos en una sola petición, reduciendo así el
número total de peticiones.
Como parámetro se
pasa al fichero un array llamado load[] que contendrá nombres de ficheros estáticos.
No todos los estáticos pueden servirse a través de esta petición, solo los
definidos en el listado interno $wp_scripts, y nunca se servirán repetidos,
aunque ni falta que hace: en ese listado hay un total de 181 ficheros que
suponen un número similar de acciones de I/O y un peso del fichero de respuesta
de casi 4MB.
Dado que esta
petición es muy pesada, una repetición constante de la misma puede provocar la
sobrecarga del servidor, llevando finalmente a la denegación de servicio. Y
peor aún, el fichero 'load-scripts.php' no requiere autenticación para ser
llamado ya que, aunque forma parte de la zona de administración, es también
accesible desde la pantalla de entrada 'wp-login.php'.
A pesar de la
facilidad de explotación, WordPress no ha aceptado la vulnerabilidad, ya que
según responden a Tawily:
"This kind of
thing should really be mitigated at the server or network level rather than the
application level, which is outside of WordPress's control."
Aun así, Tawily ha
publicado su propio parche y un script que soluciona la vulnerabilidad.
Más información:
- How to DoS 29% of the World Wide Websites -
CVE-2018-6389 https://baraktawily.blogspot.com.es/2018/02/how-to-dos-29-of-world-wide-websites.html
- Wordpress 4.9.4 Maintenance Release: https://wordpress.org/news/2018/02/wordpress-4-9-4-maintenance-release/
Fuente: Hispasec