Curioso ¿no?
Resulta que el plugin Jetpack se actualizó él solito a la versión 9.8 sin pedir permiso, sin intervención ni información al administrador del sitio, y aunque estuviesen desactivadas las actualizaciones automáticas de plugins.
Incluso aunque tuvieses desactivadas las actualizaciones globalmente desde el archivo wp-config.php con estas constantes:
/** Desactivar todas las actualizaciones automaticas (Fernando Tellado) **/
define( 'WP_AUTO_UPDATE_CORE', false );
define('AUTOMATIC_UPDATER_DISABLED', true);Índice de contenidos
¿Por qué se ha actualizado Jetpack él solo?
Bueno, el motivo ha sido que el equipo de Jetpack (de Automattic para más señas) recibió el aviso de un usuario de que el módulo del carrusel de imágenes tenía una vulnerabilidad grave relacionada con los comentarios de las imágenes del carrusel y, en vez de lanzar una nueva actualización normal, avisando a los usuarios de que era una actualización importante, grave incluso, decidió optar por la vía rápida.
De hecho, incluso en el registro de cambios del plugin aparece como si el cambio hubiese sido algo menor:
Traducido viene a ser como «Carrusel: refuerzo de la obtención de comentarios en la vista de carrusel»
¿A que no parece una amenaza grave de seguridad?
¿Cómo han actualizado Jetpack estando las actualizaciones automáticas desactivadas?
Pues resulta que una cosa son las actualizaciones automáticas, introducidas en WordPress 2.5, o las actualizaciones en segundo plano incluidas en WordPress 3.7 y ampliadas en la versión 5.6, y otra las actualizaciones forzadas, algo que siempre ha sido posible desde la API de WordPress.
En esta ocasión, el equipo de Jetpack contactó con el equipo de seguridad de WordPress (dirigido por Matt Mullenweg, CEO de Automattic, casualmente) y la Fundación WordPress, también presidida por Matt, y pidió que se forzase la actualización a Jetpack 9.8 mediante esta especie de puerta trasera de WordPress.
Dicho y hecho, si tenías Jetpack en cualquier versión desde la 2.0.8. hasta la 9.7.1, el plugin se actualizó solo sin pedirte permiso, sin avisarte siquiera, se actualizó y punto.
Da igual si se rompía algo de tu web o de las de tus clientes, alguien decidió por ti que se actualizaba «ese» plugin … por tu bien, por supuesto.
Si es por mi bien ¿qué problema hay?
Hombre visto así, punto en boca, se acabó el debate.
Cuando mañana otros desarrolladores de plugins decidan optar por esta vía rápida de las actualizaciones forzadas dará igual cuáles sean tus decisiones sobre las actualizaciones de tu web o de las de tus clientes, actualizarán y tú a verlas venir ¿te parece bien?
Pero no solo eso, también hay implicaciones sobre la privacidad y seguridad ¿o has avisado en tu política de privacidad de que si la Fundación WordPress lo decide puede actualizar tus plugins sin tu intervención, da igual las implicaciones que esto tenga para la seguridad y/o privacidad de tus usuarios?
Es más ¿qué derecho tiene el autor de un plugin a pedir una actualización forzada por un fallo de seguridad en un módulo del mismo que igual ni siquiera utilizo pero que puede afectar al resto de mi web?
En esta actualización no solo se corrigió el problema de seguridad, también se incorporaron nuevas funcionalidades, como las historias, con sus propias implicaciones de privacidad, SEO y de contenido.
¿Alguien te preguntó si querías actualizar para añadir estas funcionalidades siquiera?
O sino ¿qué responsabilidad podemos asumir frente a las webs de clientes si no podemos evitar que se fuerce la actualización de un componente de sus instalaciones sin preguntarnos siquiera a los administradores, mantenedores y/o webmasters? ¿te parece medio normal?
El asunto creo que no es menor, y debería abrirse un debate importante sobre qué protocolo se debe seguir para poder usar las actualizaciones forzadas, bajo qué circunstancias y con qué nivel de aviso a los usuarios se deberían aplicar. Pero sobre todo incorporar un sistema de información a administradores previo a una actualización forzada.
Personalmente creo que NADA justifica no informar/pedir permiso previamente a los usuarios, para que puedan tomar medidas preventivas antes de forzar una actualización.
Es más, creo que este método de las actualizaciones forzadas debería eliminarse totalmente de WordPress, pues alguien podría usarlo para cualquier uso mal intencionado, y no me digas que es un método seguro, nada es seguro en la red, todo lo que ha creado un desarrollador puede modificarlo y usarlo otro desarrollador, y alguien con malas intenciones podría usar esta posibilidad de la API para provocar una infección masiva de sitios WordPress.
¿Se pueden evitar las actualizaciones forzadas de WordPress?
Pues sí, afortunadamente, puedes añadir la siguiente constante al archivo wp-config.php:
define( 'DISALLOW_FILE_MODS', true );
Con esta constante se desactiva todo lo relacionado con las instalaciones y actualizaciones de WordPress:
- Avisos de actualizaciones
- Instalar plugins
- Instalar temas
- Actualizar plugins manualmente
- Actualizar temas manualmente
- Actualizar WordPress manualmente
- Actualizaciones automáticas de todo
- Actualizaciones en segundo plano de todo
- Actualizaciones forzadas de todo
Vamos, todo. Es una opción bastante radical, y poco práctica incluso para webmasters, pero visto lo que ha pasado es la única salvaguarda para que no se pueda volver a forzar ninguna actualización en tus sitios o los de tus clientes sin previo aviso.
¿Y a tí qué te parece esta historia?
¿Te da igual?
¿Te parece bien?
¿Te parece mal?
¿Por qué?
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
Yo solo lo admitiría si se tratara de una actualización que resolviera de forma exclusiva una vulnerabilidad muy grave. Y aún así, creo que debería salir un aviso, algo así como: «Detectada vulnerabilidad. Si en 24 horas no actualizas, el parche de seguridad se instalará de forma automática» y después otro diciendo: «Parche de seguridad aplicado de forma automática para proteger tu sitio».
Totalmente de acuerdo 🙂
Si como dice Miguel, solo si se tratara de una actualización que resolviera de forma exclusiva una vulnerabilidad muy grave.
Dices que hay Jetpack en cualquier versión desde 2.0.8. hasta 9.7.1, entonces lo correcto era actualizar para 2.0.9. hasta 9.7.2. y no agregar nada nuevo. Ir para la versión 9.8 me parece ILEGAL.
Bueno, yo no pasé por esta experiencia, porque NUNCA he usado Jetpack. No sé bien porque, alguna «intuición» siempre me hizo buscar las funcionalidades en otra parte.
Gracias por la información.
No le tengo nada de simpatía a Jetpack. Antes era fan hasta que me cansé de los problemas que me daba. Ahora vivo sin él y no puedo dejar de sentirme aliviado cada vez que veo una de estas.
De todos modos aún tengo que sufrirlo en webs de clientes y desde luego este tipo de actuaciones no ayuda nada. Aquí Fernando habla un poco en general pero imagina que administras varias webs de clientes con Jetpack y se te fastidian unas cuantas por la dichosa actualización.
Hay que tener en cuenta que hay clientes muy pejigueras que por acceder a sus exigencias tienes que evitar actualizar al máximo (excepto las de seguridad, por supuesto) para prevenir que la web se rompa. El destrozo puede ser considerable.
Saludos!