Fallos XSS en WordPress: page-new, post-new y user-edit
Buenas y malas noticias: las buenas es que sólo afecta como administrador a los que tengan “manía Unix” y usen un usuario no-administrador (como es mi caso, que el usuario Armonth es +/- el equivalente a un editor) están a salvo.
Las malas es que la vulnerabilidad afecta a todas las versiones. Los ficheros afectados son wp-admin/post-new.php, wp-admin/page-new.php y wp-admin/user-edit.php.
En Buayacorp han puesto un DIFF pero si no queremos complicarnos leyendo código la solución se puede resumir, en los ficheros wp-admin/post-new.php y wp-admin/page-new.php buscad la línea que pone:
<div><input type="text" name="post_title" size="30" tabindex="1" value="<?php echo $post->post_title; ?>" id="title" /></div>
Y cambiadla por:
<div><input type="text" name="post_title" size="30" tabindex="1" value="<?php echo attribute_escape($post->post_title); ?>" id="title" /></div>
En realidad sólo cambia el contenido de value="" envolviendo $post->post_title con attribute_escape().
Luego, en el fichero wp-admin/user-edit.php, buscad la línea:
<input type="hidden" name="wp_http_referer" value="<?php echo wp_specialchars($wp_http_referer); ?>" />
Y cambiadla por:
<input type="hidden" name="wp_http_referer" value="<?php echo clean_url($wp_http_referer); ?>" />
Aquí como veis lo que cambia es wp_specialchars por clean_url.
Nota importante: en la rama 2.0.x no aparece la función wp_http_referer en wp-admin/user-edit.php, por lo que en principio sólo hay que editar los dos primeros. Estoy a la espera de que Alex diga algo al respecto.
netemi (WordPress Plugin)
En el mundo telemático ESCRIBIR TODO EN MAYÚSCULAS COMO ESTO es equivalente a gritar. Mucha gente no lo sabe (por inexperta o por idiota o por newbie (”patonauta“).
El 10/05 Luis Beltrán me escribió lo siguiente por chat:
Torito a que te hacés un plugin para pasar a minúsuculas los comentarios escritos solamente en mayúsculas? dale, ¡a que sí! Si todos los caracteres de un comentario están en mayusculas pasarlos todos a minúsculas. Si el comentario esta en minusculas o tiene algunas mayusculas, dejarlo como está.
Me puse una pila y el 11/05 le mandé la 1era. versión preliminar del netemi “No escribas TODO EN MAYÚSCULAS, infeliz…”: WordPress Plugin: NETEMI: No escribas todo en mayúsculas, infeliz! que funcionaba, aunque ya tenía desde el arranque algunos agujeros conocidos en el caso de los acentos en mayúsculas o tildes especiales (Á/Ä/À/Â/etc.).
Desde aquel día y hasta hoy hice varios tiros peleándome con funciones de PHP que desconocía (y que no pude hacer funcionar) como strtr y otras, para al final darme cuenta que el mambo estaba propiamente en la add_filter() de WordPress.
Simplifiqué todo lo que pude, y aunque no sea la 8va. maravilla ni cosa parecida anda aceptablemente y funciona de cualquiera de estas dos formas como digo en el mismo código fuente:
/*
=====================================================================
Opciones para el tipo de filtro:
Elegí que filtro preferís usar, comentando el que "no" con // adelante.
---> 'comment_text': procesa el texto del comentario cada vez
que se muestra, es decir, se graba en la base como originalmente
fue ingresado por el comentarista y/o patonauta.
---> 'pre_comment_content': procesa el texto con netemi y lo graba
en la base procesado, es decir que la manera en que fue ingresado
originalmente se pierde; aunque supuestamente daría menos trabajo
al procesador ya que la función trabajaría una sola vez
por comentario ingresado.
=====================================================================
*/
// add_filter('comment_text','netemi', 19);
add_filter('pre_comment_content','netemi', 19);
Lo que importa:
Casos de uso:
A) Quiero que me envíen a mi e-mail el MSN-Messenger. (Un clásico PätônàutÄ).
queda sin tocar.
B) QUIERO QUE ME ENVÍEN A MI E-MAIL EL MSN-MESSENGER. (UN CLÁSICO PÄTÔNÀUTÄ).
se pasa todo a minúsculas:
quiero que me envien a mi e-mail el msn-messenger. (un clasico patonauta).
(¡pero sin acentos!)
C) quiero que me envíen a mi e-mail el msn-messenger. (un clásico pätônàutä).
queda sin tocar.
Disponible en la sección de plugins torássicos.
Nota posterior (26/05/2007 – 12:10 PM GMT-3
Hubo un problema con la prioridad en que se aplican los filtros, puntualmente en este weblog en particular que tiene muuuuuuuchos plugins funcionando; es por eso que el plug funcionaba bien en mis sitios de prueba y mal acá. Ahora, habiéndole cambiado la prioridad de ejecución de 19 a 14 anda como corresponde (acá) y espero que en todos lados.
Aizatto’s Related Post para entradas relacionadas
He estado utilizando el wasabi related post plugin para incluir entradas relacionadas a los artículos que publico. Hoy me encuentro con aizatto’s related post, el cual modifica el Wasabi añadiendo las siguientes funciones:
1. No hay necesidad de alterar los archivos del tema
2. Ofrece la opción de incluir un extracto de las entradas
3. Ofrece la alternativa de que las entradas relacionadas aparezcan en el feed\
4. Es posible moficar la apariencia de los enlaces
Así que he desactivado el Wasabi y ya estoy utilizando el Aizatto. ![]()
Actualización: Hay un problema mayor con el plugin ya que muestra las entradas relacionadas en las páginas. Espero que exista una manera sencilla de resolver el mismo.
Blogalaxia Tags: wordpress
Frame de vista previa en WordPress 2.2
Las versiones anteriores a WordPress 2.2 incorporaban en la parte inferior, al escribir una entrada, un frame con la vista previa de la anotación tal cual quedaría en el blog. Esta opción ha sido eliminada, incorporándose un enlace “Preview” en la parte superior del formulario que la abre en una nueva ventana.
Muchos usuarios echan en falta el frame de las versiones anteriores, por suerte casi todo en WordPress tiene solución, Preview Frame mostrará en nuestra versión 2.2 la vista previa como en versiones anteriores.
Actualizado a WordPress 2.2
Tras conocer el bug que afecta a las versiones 2.0.x y 2.1.x he actualizado a la reciente versión el blog, los pasos a seguir son los de siempre.
Destacar que me he encontrado con un error, tras la actualización el feed no funcionaba correctamente y daba un error en la línea 100 del archivo wp-settings.php. Al ver que estaba relacionada con la cache he actualizado WP-Cache (tenía 2.0.22) a la última versión y el problema se ha solucionado, por lo que entiendo que hay algún tipo de problema entre versiones antiguas del plugin y la nueva de WordPress.
Bug crítico en WordPress 2.0.x y 2.1.x
Me comenta Armonth por msn la existencia de un bug crítico en las versiones 2.0.x y 2.1x de WordPress, por lo que se recomienda actualizar lo más rápido posible a la versión 2.2 (o 2.0.11 cuando salga) o aplicar el parche correspondiente.
WordPress 2.2 y bug de inyección SQL: soluciones: El fichero a editar es para WordPress 2.0.x el wp-includes/pluggable-functions.php, la línea 121 que corresponde a “return $userdata” (única coincidencia en el fichero), en WordPress 2.1.x es lo mismo pero el fichero se llama pluggable.php y después de esa línea se debe añadir una línea para que quede así (ver Changeset 5442):
if ( $userdata )
return $userdata;
$user_login = $wpdb->escape($user_login);
Por tanto si tenemos una versión vulnerable, un usuario malintenciado podría obtener el hash de nuestra contraseña y a partir de él sacar nuestro password. Si ésta es poco segura bastarían unos minutos para poder acceder como administrador al blog.
WordPress 2.0.11 RC 1
Ya está disponible la versión 2.0.11 RC 1 donde según el roadmap la version final con fecha prevista para el 15 de Junio.
Lista de cambios y arreglos en version 2.0.11 como arreglo a una SQL Injection publicado hace unos dias que afectaba a la WordPress 2.2 y ahora también a las versiones 2.0.x. En SigT nos dan la solución para arreglarlo manualmente en ambas versiones:
El fichero a editar es para WordPress 2.0.x el wp-includes/pluggable-functions.php, la línea 121 que corresponde a “return $userdata” (única coincidencia en el fichero), en WordPress 2.1.x es lo mismo pero el fichero se llama pluggable.php y después de esa línea se debe añadir una línea para que quede así:
if ( $userdata ) return $userdata; $user_login = $wpdb->escape($user_login);
Problema de seguridad en WordPress 2.1
Via Genbeta leo que han encontrado una nueva vulnerabilidad, esta vez seria, que atenta por completo la seguridad de cualquier Blog con la versión 2.1 de WordPress. Esta vulnerabilidad permite conseguir mediante inyección de SQL el hash con la contraseña de tu usuario administrador. Si estás usando esta versión actualizate a la 2.2 inmediatamente. Al parecer la versión 2.0 no sufre estos problemas.
WordPress 2.2 y bug de inyección SQL: soluciones
El bug que comenté hace casi 24 horas para WordPress 2.2 parece ser que también afecta a la rama 2.0 de WordPress.
El ticket (con exploit incluido) es el #4322 Sql injection blind fishing exploit.
El bug está arreglado en WordPress 2.2 y lo estará en 2.0.11 (que será lanzada en muy breve tiempo) pero vamos a arreglarlo manualmente porque es demasiado fácil de usar.
El fichero a editar es para WordPress 2.0.x el wp-includes/pluggable-functions.php, la línea 121 que corresponde a “return $userdata” (única coincidencia en el fichero), en WordPress 2.1.x es lo mismo pero el fichero se llama pluggable.php y después de esa línea se debe añadir una línea para que quede así (ver Changeset 5442):
if ( $userdata )
return $userdata;
$user_login = $wpdb->escape($user_login);
El bug al afectar a la rama 2.1 (no actualizados) y a la 2.0.x (los que pensábamos que estábamos libres) y obtener los hash de usuarios es muy peligroso así que pido la máxima difusión a esta información o vamos a ver caer blogs como moscas.
