Vulnerabilidad en MongoDB permite la ejecución de código arbitrario

El investigador de seguridad con sobrenombre de agixid, parte de la
empresa franco-suiza SCRT, ha publicado una vulnerabilidad en el sistema
de bases de datos MongoDB. Esta permite la ejecución de código remoto,
manipulando el puntero utilizado por el método nativeHelper para
ejecutar comandos del sistema. Ya ha sido publicado un exploit para el
fallo.

MongoDB es un sistema de bases de datos no relacional de código abierto
desarrollado por la compañía 10gen. Es una base de datos documental,
esto es, que almacena sus datos de forma estructurada. En concreto,
utiliza un formato extendido de JSON, llamado BSON, propio de este
sistema. Actualmente es el sistema NoSQL más popular, contando con
versiones para varios sistemas operativos, y siendo utilizado en los
back-ends de empresas como SAP, SourceForge o Foursquare.

La investigación de agixid pretendía ahondar en los entresijos del
método ‘run’ del sistema para tratar de ejecutar código en el servidor.
Este método ejecuta en una shell el comando que se le pase como
parámetro (por ejemplo, ls en sistemas Linux). Sin embargo, este comando
es sólo valido en el cliente y no permite ejecutar código a través de
consultas al servidor.

Agidix descubrió que el método run simplemente realiza una llamada a
nativeHelper, una función del motor JavaScript SpiderMonkey de Mozilla,
pasando como parámetros un vector asociativo (run_) y el comando a
ejecutar. Este vector run_ no está definido en el lado del servidor,
pero sí se puede utilizar directamente un vector de la forma
{“x”:0x01234}, por ejemplo, para suplirlo. El valor asociado a x apunta
a la dirección de memoria de una función JavaScript, y que será
ejecutada sin ninguna comprobación a través de un método de tipo
NativeFunction. Al poder controlar el puntero a la función que se
ejecuta, se puede ejecutar código arbitrario en el servidor.

La vulnerabilidad, con identificador CVE-2013-1892, ha sido probada en
la versión 2.2.3 de MongoDB para sistemas de 32 bits. La rama 2.4 no se
ve afectada, ya que se ha cambiado el motor JavaScript a V8, motor de
Google, que no es vulnerable. Sin embargo, la última versión de la rama
2.2 (2.2.4) fue publicada el día 26 de marzo sin ninguna alusión a la
vulnerabilidad. Por otro lado, ya se ha publicado un módulo en
Metasploit para su explotación.

 Fuente