Barrapunto

He estado leyendo esta mañana el papel que habla de la vulnerabilidad en cuestión. No sólo es Windows, son también las aplicaciones que reciben los mensajes, que pueden considerararse como otra entrada más de usuario.

Es decir, cuando se programan aplicaciones seguras, no se confía en la entrada del usuario, pero en ninguna. Eso también es aplicable a los mensajes que le mandan otras aplicaciones.

El problema más, que de bug irreparable como lo califica The Register, es más bien un fallo de diseño donde se viene de una época de transición de un Windows monousuario, donde este tipo de cosas no tenían mucho sentido a otro con permisos, usuario múltiples y demás.

Por cierto, creo que no es nuevo el agujero, es algo conocido. Cualquiera que ha programado en Win32 ha mandado mensajes a otras ventanas. A mi de hecho, se me ocurrio el tema hace tiempo para quitar los clásicos asteriscos de los password. Lo único que no dí fue con las rutinas que me devolvieran los handles de las ventanas del sistema.

Otro ejemplo es mandar el mensaje EM_ LIMITTEXT, y quitar los límites del texto de los controles de edición. Luego, si no se comprueba la longitud al copiar el texto desde el control ... ¿culpa de Windows o del programador de la aplicación?

A mi la situación me parece parecida al uso de gets() en C: el sistema de un mecanismo, inseguro, y que ha sido (abu)usado por los programadores de aplicaciones sin tener en cuenta las implicaciones de seguridad.

En cuanto al WM_TIMER, siempre podrías ver si el timer lo has instalado tú: existe un parámetro que indica que identificador de timer existe. Si no lo ha instalado tú, podría ignorarse. (al menos es lo que comentan por Bugtraq)

Lo curioso es saber que tipo de procesos GUIs basados en paso de mensajes estarían también afectados.

el hilo en bugtraq y la noticia en Slashdot y Kuro5hin.

Después de leer bastantes comentarios, me quedo con esto:
1. "It is a Win32 vulnerability in that it is even possible to have this kind of elevation of priveleges by "poorly written" services. Basically, any system service that interacts with the desktop is vulnerable (virus scanners). McAfee interacts with the desktop. This is bad too."
2. "Interactive services are a *bad idea*. There is no need to have them. If you do have them they should not run under the context of LocalSystem. A good developer will not use them as there are alternatives. Microsoft does not recommend using interactive services."
3. "Able to program in 23 languages on 14 platforms, Foon takes an average of 3 days to learn a new programming language."

Me mandó ayer este enlace mi amigo Luis (aka "La Mujer de Colombo"), parece que en Kuro5hin se ha discutido bastante el tema y hay algunos comentarios bastante interesantes.

Completamente deacuerdo.

Esto mas que un bug es una curiosidad tecnica y un recordatorio de por que los servicios no deben de tener GUI (o de por que lo servicios no deben estar escriotos en VB :)

Ahora que lo que podria ser mas interesante es poder acceder a las ventanas de otro usuario en Windows XP (o en un Terminal Server).

En entos casos el tema si es bastante grave.

Ejemplo practico:
supermercado en internet www.plusfresh.com
Estos tios usan el citrix para hacer la compra. Se podria meter codigo para trincar numeros de visa cuando la peña entra a comprar?. ==:-)

Y Drizzt tiene razón es culpa de los programadores, pobre microsoft, bastante tenian ellos con pasar de win9x a win2000. Con tantos botoncitos nuevos que pintar se olvidaron de la seguridad. Es normal.

un saludo
Pisuke

¿Y si lo programas tú para que haga una escalada de privilegios el programa? También es culpa del programador, claro... Microsoft en este caso no tiene la culpa.. ¿Verdad?

Vamos a ver, es como si me dices que programas un exploit para aprovechar un buffer overflow porque un programa privilegiado usa gets().

El paso de mensajes de una aplicación a un servicio con otro privilegios es como no comprobar la longitud de una cadena que nos llega a un programa setuid.

Y Drizzt tiene razón es culpa de los programadores, pobre microsoft, bastante tenian ellos con pasar de win9x a win2000. Con tantos botoncitos nuevos que pintar se olvidaron de la seguridad. Es normal.

El diseño del API Win32 es anterior al paso de Windows 95, de hecho data del año 93 con Windows NT 3.1, así que como mínimo te veo poco informado con esto.

Estás hablando exactamente de varios mecanismos que existen en Unix, como por ejemplo el pillarse variables de entorno con getenv(), no comprobar que existen ficheros a la hora de crearlos y usar ataques de symlink, o usar en un programa setuid un syslog sin poner el %s en la cadena. ¿Se olvidaron los diseñadores de Unix de la seguridad?.

Veamos, según he leido y no soy experto programador, lo mio es sistemas, he deducido (seguramente mal, según veo) que con una función simple de la API Win32 puedes mandarle mensajes a otra ventana y así conseguir la escalada de privilegios. El mismo autor del artículo ha hecho un programa que así lo hace... así que con solo tener permiso de ejecución (que no de instalación de aplicaciones) puedes liarla... y gorda.

Pero ya te digo Drizzt que es lo que he deducido, corrigeme si me equivoco, pues es probable.

Por las conclusiones que se pueden sacar de el hilo en Kuro5in, no es el tipo de vulnerabilidad que se pueda explotar remotamente y conceda acceso a la maquina ( se puede hacer por VNC, pero si entran por VNC ..., dicen que por Terminal Server no ), sino es mas el tipo de vulnerabilidad que permite acceder a información restringida ( como dentro de un entorno empresarial ) a personas no permitidas.

Como siempre una lección de historia informatica.
Me has recordado porque no me gustaba la clase de historia con tanta fecha por enmedio.

Del artículo:

1. Locate a suitable window within VirusScan (an edit box is perfect), and obtain a window handle to it. Buscamos una ventana con que corra en el contexto de LocalSystem (digamos que root local). Equivalente a buscar un binario setuid.
2. Remove any length restrictions that may be present on that edit box, so that I can type in an arbitrary quantity of data.. Quitamos la restriccion de longitud asociada a los controles Edit de Windows. (realmente este era ya un viejo truco cuando se hacían cracks: buscabas el control y ponias breakpoints en los mensajes de acceso al texto de las claves).
3. Paste in some binary executable code.. Esto es equivalente a injectar el shell code.
4. Force VirusScan to execute my code (as LocalSystem).. Esto lo hace con ayuda del mensaje WM_TIMER. Uno de los parámetros de dicho mensaje es la función que llamará cuando se ejecuta. Si tu ciegamente crees que ese WM_TIMER viene de tu aplicación sin comprobarlo, entonces es el equivalente a no comprobar una cadena de entrada

De algunos mensajes en Bugtraq:

WM_TIMER messages are posted to the message queue and can be filtered by the application, as stated in the documentation for this message. The application can have a list over timers and check this for validity. (Moral of the story: Don't trust window message parameters any more than user input).

De la documentación de MSDN:

The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue

Y como dicen los post de Bugtraq: Es una malísima idea que los servicios inteactuen con el escritorio.

Posi, gracias por ilustrarme.

Hola, de entrada puede que me equivoque, no he tenido tiempo de leer el artículo en profundidad así que nadie se tire de los pelos.

Tal y como lo he entendido, a un programa se le puede enviar un mensaje de parte de otro de manera totalmente transparente para que el primero piense que el mensaje le viene del teclado.

Así pues, si un programa tiene los privilegios y la capacidad de, pongamos por caso, borrar el disco duro pulsando [ctrl+d], se le puede enviar esa secuencia desde otro programa y el primero pensará que es la entrada del usuario.

Esto es bastante distinto a un clásico desbordamiento de buffer.

¿O estoy equivocado?

El diseño del API Win32 es anterior al paso de Windows 95, de hecho data del año 93 con Windows NT 3.1, así que como mínimo te veo poco informado con esto.

Aquí te equivocas. El horroso diseño de la interfaz no es del NT 3.1, ni tampoco del NT 3.5

El primer NT con tener algo como eso fue el NT 4, y éste es posterior al win95 (es del 96, si no me equivoco). Por tanto, la interfaz q tiene windows fue desarrollada para el 95. Otra cosa es que se empezace en el 93 :-), pero no fue pública hasta el winsuxs95.

salud

Ya había extensiones Win32 para Windows 3.1.

Hola,

En realidad el método que se describe en el artículo sí que se parece a un buffer overflow. Primero toma una aplicación privilegiada y rellena uno de sus campos con datos binarios (supongo que código máquina para lanzar un programa o algo similar). Luego programa un timer mediante WM_TIMER y le indica que la función de callback se corresponde con la misma dirección de memoria que los datos binarios que se introdujeron con un mensaje, de forma que el propio kernel de windows es el que ejecuta el código. A mi me resulta parecido a un buffer overflow, aunque tb puede ser que lo haya entendido mal.

Nos vemos.
     

Vamos a ver, yo no estoy hablando de DISEÑO GRAFICO. Estoy hablando del API de programación y su diseño.

Lo único que no dí fue con las rutinas que me devolvieran los handles de las ventanas del sistema.

Y no te servía la función EnumWindows?

Alguien sabe donde se pueden encontrar el resto de 'Laws' de Micro$oft???? Són de escandalo !!!!

En lo que leí, reconozco que superficialmente, en kuro5hin parece que hablaban de otros métodos como el que comento anteriormente de simular la entrada del usuario en el teclado desde otra aplicación, lo cual no tendría nada que ver con desbordamientos de buffer.

Puedo estar equivocado, me lo miraré de nuevo.

The Ten Immutable Laws of Security

Efectivamente, con la API SendMessage puedes mandar pulsaciones de teclado a otra aplicación sin ningún tipo de problema.

Curioso, curioso;
abro el enlace con konqi y no entraba (el frame principal no cargaba). Miro el userhost que tenía puesto y resulta que estaba en "Netscape Navigator 4.76 on Windows 95". Lo cambio a "Internet Explorer 5.0 on Windows 95" y va super-rápido ];)

Pero tiene su gracia "si un tipo malo te convence para ejecutar su código en tu ordenador, deja de ser tu ordenador"...
me refiero a la nueva EULA con derecho de root y las nuevas "habilidades escondidas" de Win2k / XP para conectarse remotamente con M$ sin avisar...
Y con Palladium ...

debe estar mal copiada la url, yo entre con el konqueror y a mi tampoco me aparecia pero con que le des click en el menu de la izquierda te aparece.

Igual me equivoco (no soy experto en programación win32), pero creo que el problema está en que puedes mandarle mensajes a un CONTROL, no a la ventana de la aplicación. Si le mandas un mensaje directamente a un control (en el caso del artículo, a un control de edición) el bucle principal de proceso de mensajes de tu aplicación ni se enterará. Para poder hacer un mínimo filtrado tendrías que interceptar TODOS los mensajes a TODOS los controles; eso, de hecho, equivaldría a reescribir tu propia versión de la GUI de Windows.

Fíjate en la comparación con XWindow: en X los controles no son ventanas. En Win32 sí: cada control tiene su bucle de mensajes, etc, etc. Ese bucle de mensajes está en el código de windows (supongo que en USER.EXE) y es ESE CÓDIGO el que atacas, no el código de la aplicación.

Una posible solución sería que los controles que se muestran en el desktop corran siempre bajo los privilegios de la sesión del usuario logeado (lo siento por la palabrita). Pero eso supondría que cada vez que se activara un control tendría que haber un cambio de UID efectivo (o como se llame en windows), y supongo que eso no sería precisamente muy eficiente.

Igual todo lo anterior es una chorrada... insisto en que conozco POCO la programación Win32...

Hmmm... Windows 2.X ya funcionaba a base de mensajes. El hecho de que los handles fueran punteros (o punteros a punteros) venía dado por el modelo de memoria segmentada, más que nada. No había protección de memoria; sin protección de memoria, la forma más eficiente de implementar un sistema de mensajes es precisamente a base de direcciones.

Pero ellos son "tipos buenos"!!! Jajajajaj!

Que yo sepa en LiNUX no se puede hacer nada parecido.

Tienes razón, no había leído bien... (vaya cagada XD)

Bueno, una de las cosas que resultan curiosas es que en la actualización que se menciona se hace referencia a que hay servicios de Microsoft corriendo de forma vulnerable...

Es decir, lo realmente terrible de todo esto, lo que parece más tremendamente incomprensible de todo esto, es el que este WM_TIMER puede llegar a ejecutarse; lo que es realmente importante de todo esto es que puedes mandar un mensaje a otra aplicación que le ordene ejecutar código perteneciente a sí misma,... y eso es una burrada enorme en seguridad de un sistema operativo...