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.