Fallos XSS en WordPress: page-new, post-new y user-edit
Publicado el Viernes 25 de Mayo del 2007 @ 17:51 por Armonth.
- 5
- 1
Comentar
Actualización: si bien la solución de abajo soluciona el problema, Ryan ha hecho un Changeset más completo para la rama en desarrollo con múltiples attribute_escape() y int(). No recomiendo aplicar los cambios tal cual están ahí ya que son para la rama de desarrollo y hay que saber qué tocar (aparte de que son 35 cambios y tiene tela).
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/edit-form-advanced.php y wp-admin/edit-page-form.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 ficheros.
5 Comentarios (feed)
-
j_aroche nos comenta:
puffff es de nunca terminar esto!
BTW: El SVN es mejor ni tocarlo, ya está metiendo los cambios de categorías por términos… así que mejor evitarse problemas mientras terminan todo.
-
Angeles nos comenta:
Perdón por mi ignorancia, pero no entiendo bien, si el usuario es “admin” ¿no hay problema?
Por cierto, me he dado cuenta de que la primera vez que comenté en este blog firmé como Enana y la segunda como Angeles. Pero soy la misma, así que ya no sé como firmar :( . -
Armonth nos comenta:
Al contrario Angeles: si cuando entras en la URL preparada para “atacarte” estás registrada en tu blog como admin entonces el ataque surte efecto.
La solución es crearte una segunda cuenta y darle permisos de “Editor” que permite hacer lo mismo salvo algunas cosas (editar/crear usuarios, moderar comentarios en entradas de otros usuarios, etcétera).
-
alex nos comenta:
@Angeles: si hay problema si alguien usa CSRF para aprovecharse de este fallo.
-
Angeles nos comenta:
Muchas gracias por la información, a mí que soy novata en esto (solo llevo un año), me estresa bastante tanta vulnerabilidad, y tanto niñato por ahí dispuesto a atacarte en cualquier momento.
Lo bueno es que la comunidad WordPress, gracias a muchos desarrlladores como vosotros, funciona bien, enseguida llega el aviso.
Gracias por todo.