FreeBSD 7.2 and below (including 6.4) are vulnerable to race condition in VFS
and devfs code, resulting in NULL pointer dereference. In contrast to pipe race
condition, this vulnerability is actually much harder to exploit.
Due to uninitalised value in devfs_open(), following function is called with
fp->f_vnode = 0:
static int
devfs_fp_check(struct file *fp, struct cdev **devp, struct cdevsw **dswp)
{
*dswp = devvn_refthread(fp->f_vnode, devp);
if (*devp != fp->f_data) {
if (*dswp != NULL)
[6] dev_relthread(*devp);
return (ENXIO);
}
KASSERT((*devp)->si_refcount > 0,
("devfs: un-referenced struct cdev *(%s)", devtoname(*devp)));
if (*dswp == NULL)
return (ENXIO);
curthread->td_fpop = fp;
return (0);
}
struct cdevsw *
devvn_refthread(struct vnode *vp, struct cdev **devp)
{
struct cdevsw *csw;
struct cdev_priv *cdp;
mtx_assert(&devmtx, MA_NOTOWNED);
csw = NULL;
dev_lock();
[1] *devp = vp->v_rdev;
if (*devp != NULL) {
[2] cdp = (*devp)->si_priv;
[3] if ((cdp->cdp_flags & CDP_SCHED_DTR) == 0) {
[4] csw = (*devp)->si_devsw;
if (csw != NULL)
[5] (*devp)->si_threadcount++;
}
}
dev_unlock();
return (csw);
}
In [1] vp is dereferenced, resulting in user-controllable *devp pointer (loaded
from *0x1c). If values dereferenced in [2], [3] and [4] are reachable, at [5] we
have memory write at user-controllable address. Unfortunately, the value is
decremented in [6].
In my exploit, I use si_threadcount incrementation to modify kernel code in
devfs_fp_check(). Opcode at 0xc076c64b is "je" (0x74). After incrementation it
changes to 0x75, which is "jne". Such modification results in not calling
dev_relthread() at [6] and eventually leads to function pointer call in
devfs_kqfilter_f().
The following exploit code works only on default 7.2 kernel, due to hardcoded
addresses:
http://www.frasunek.com/devfs.
This bug was fixed a week ago and official advisory was issued:
http://security.freebsd.org/
WordPress 2.8.4 Actualización de seguridad disponible desde el día de hoy 11 de Agosto del 2009.
“Remote admin reset password” Se trata de una vulnerabilidad que puede ser aprovechada por un atacante remotamente a través de un navegador web bloqueando temporalmente la cuenta del administrador de nuestro WordPress, impidiendo así que nos podamos loguear, ósea acceder de forma correcta a la administración de nuestro blog.
Los desarrolladores de WordPress ya fueron advertidos de dicha vulnerabilidad y seguramente estemos viendo una actualización de seguridad WordPress 2.8.4 en los próximos días y aunque si bien no han liberado un parche oficial si lo han corregido en la versión de desarrollo del programa.
La solución es fácil y rápida de implementar y simplemente se tiene que editar el archivo que se encuentra en el directorio raíz de su blog llamado “wp-login.php” donde buscaremos lo siguiente:
if ( empty( $key ) )
para remplazarlo por:
if ( empty( $key ) || is_array( $key ) )
Desde InfoSpyware le recomendamos a todos los usuarios de WordPress a implementar esta modificaciones de seguridad cuanto antes, mientras esperamos la actualización oficial.
Actualización de WordPress 2.8.4 disponible desde el día de hoy.
Tal como anunciábamos en este mismo post, sabíamos que la gente de WordPress siempre trabaja muy rápido y se preocupa mucho por solventar rápidamente los bugs de seguridad encontrados. Por eso el día de hoy acaban de liberar la nueva versión de WordPress 2.8.4: Security Release que soluciona la vulnerabilidad de “Remote admin reset password” totalmente.
Independientemente si parcharon o no su actual WordPress, desde InfoSpyware les recomendamos actualizar cuanto antes a la nueva versión 2.8.4 que aparte de las líneas que recomendamos modificar arriba, agrega otras líneas más.
Fuente: http://www.infospyware.com/blog/nueva-vulnerabilidad-en-wordpress-2-8-3/
