El lunes negro de WordPress: actualizaciones con fallos y vulnerabilidades que no se solucionan

Definitivamente esta semana no es la mejor para el CMS que, dicen, supone casi el 30% de sitios de Internet. Un fallo introducido en la ultima actualización impide actualizar automáticamente, y una vulnerabilidad que tiene como impacto la denegación de servicio no será solucionada.


El lunes 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.



Francisco López
flopez@hispasec.com

Más información:






Powered by WPeMatico

Entradas relacionadas

About Gustavo Genez 2078 Articles
Informático de corazón y apasionado por la tecnología. La misión de este blog es llegar a los usuarios y profesionales con información y trucos acerca de la Seguridad Informática.