URLs, URIs, Comportamientos Automáticos y la Vulnerabilidad del Mac OS X

El reciente descubrimiento de la vulnerabilidad del Mac OS X consistente en la posibilidad de ejecutar un comando cualquiera a través del protocolo help:, vinculado al Visor de Ayuda del Mac OS X, ha permitido que una investigación más a fondo demuestre que en realidad el problema es mucho más profundo, y aunque existen soluciones ya aplicables, como Paranoid Android, que describiremos en la última sección del artículo, es necesario dedicar algo de tiempo a ver qué es un URL, un gestor de protocolos, y qué es exactamente lo que nos hace vulnerables, y cómo se puede crear un ataque. Un artículo de Juan de Dios Santander Vela, Consultor IT Freelance

¿Qué es un URI?

Un URI, o Universal Resource Identifier, es una forma de definir cualquier tipo de contenido disponible en Internet, y consta de tres partes: un identificador de protocolo, una dirección de Internet/Intranet, y el camino al documento. Por ejemplo, el URI de una de mis páginas web en .Mac es:

http://homepage.mac.com/juandesant/Menu8.html

Podemos dividir este URI —la parte que se encuentra entre los corchetes angulares, «»— en tres partes:

http:

El identificador que va antes de los dos puntos, incluyéndolos, es el indicador de protocolo: indica qué conjunto de acuerdos para comunicaciones —protocolo— es necesario seguir para obtener la información que se encuentra en la dirección que va a continuación de los dos puntos. Son protocolos comunes, aunque algunos de ellos estén en desuso http:, ftp:, smb:, telnet:, archie:, gopher:… Por cierto que la inclusión de los dos puntos en el nombre del protocolo puede tener mucho que ver con la sintaxis de paso de mensajes de Objective-C…

http://homepage.mac.com

Esta parte representa el servidor en el que se encuentra la información, y por medio de los servidores de DNS se obtendrá una dirección IP con la que se conectará.

http://homepage.mac.com/juandesant/Menu8.html

Esta última parte especifica el archivo concreto, o conjunto de información concreto especificado por el URI. Podemos considerarlo como un «camino de información» para ese protocolo dentro del servidor especificado. Este «camino» es similar en su formato a las especificaciones de archivo en un sistema Unix, si bien el directorio raíz no tiene por qué coincidir con la raíz del disco.

Si mucho de lo que hemos visto en realidad lo conoces como URL, no vas desencadenado: los URLs (Uniform Resource Locator) son casos particulares de URIs, siempre vinculados a información residente en la red. La diferencia entre URI y URL es lo que permite uniformar el acceso a cualquier contenido, ya sea local o disponible en Internet.

¿Qué es un Gestor de Protocolo?

Hemos visto que un URI/URL puede especificar diferentes protocolos para la obtención de información. Por ejemplo, http: es un protocolo pensado para la Web —HyperText Transport Protocol—, mientras que ftp: es el File Transfer Protocol, un protocolo concebido para sesiones de transferencia de archivos.

Cada uno de esos protocolos son diferentes en incompatibles entre sí, y en la tradición Unix con la que se creó Internet —recordemos que Tim Berners-Lee desarrolló el primer cliente web gráfico en una NeXTStation utilizando el abuelo del Mac OS X—, se concibió que cada programa cliente pudiera ser distinto —el lema de Unix es disponer de una miríada de pequeñas utilidades, cada una de ellas perfectamente adecuada para un fin muy concreto, con la posibilidad de comunicación entre todas ellas—.

Por tanto, hay que asignar un Gestor de Protocolo —Protocol Helper o Handler, en inglés— a cada uno de los diferentes protocolos con el que nos vayamos a encontrar. Así, en una instalación estándar del Mac OS X, el protocolo http: se asigna a Safari, los protocolos smb:, ftp: y webdav: los tienen asignados aplicaciones específicas que montan volúmenes en el Finder, mailto: está asignado a Mail, y el protocolo telnet: está asignado al programa Terminal; por supuesto, esto no es una lista exhaustiva…

¿Cómo funciona la gestión de protocolos en el Mac OS X?

Dicen que en el pasado está la raíz de muchos de nuestros problemas.

Un poco de historia: la gestión de protocolos en Mac OS 9

El Mac OS 7.5 fue una de las versiones más especiales del Mac OS, porque entre otras cosas fue la primera —y a la postre, la última— versión que se licenció a los fabricantes de clónicos Mac. Además, fue la primera versión en llevar de serie Open Transport, la tecnología con la que Apple incorporaba conectividad TCP/IP al Mac. Existían otras formas de conectar un Mac en redes TCP/IP con anterioridad, pero Open Transport las homogeneizaba todas. Lo que no resolvía Open Transport era la asignación de protocolos.

En aquella época, el interfaz principal para la gestión de URLs era el propio navegador: si se trataba de un protocolo y/o formato de archivo reconocido por el navegador, bien; si no, se informa al usuario de algún modo que el navegador no puede gestionar ese contenido.

Internet Config era una utilidad que permitía disponer de una base de datos de configuración de aplicaciones de Internet: uno especificaba información común para todas ellas, como el nombre del usuario, la cuenta de correo electrónico, la forma de conexión a Internet, etcétera; y luego, uno especificaba qué aplicaciones se iban a encargar de qué protocolos. Además, proporcionaba a los programadores una forma de acceder a esa información, de modo que un navegador podía saber quién se iba a encargar de manejar el correo electrónico, o el programa de correo electrónico saber qué navegador abrir si se pinchaba en un URL en el texto de un mensaje.

Para el Mac OS 8, Apple se había dado cuenta de la utilidad de Internet Config, y lo incorporó en el sistema operativo. Versiones subsiguientes del Mac OS exhibieron grados crecientes de integración con Internet: el Sherlock original, el Navegador de Red, AppleTalk sobre TCP/IP, el script Conectarse a…

La gestión de protocolos en NeXTSTEP/Mac OS X

La gestión de protocolos en Mac OS X sigue un camino curioso, con decisiones muy interesantes, por un lado, y algunas inexplicables, por otro. Vamos a intentar ver el origen de todo, y cuál es la filosofía en la gestión de URLs en Mac OS X.

Desde las últimas versiones de NeXTSTEP, y la versión que después se conoció como OpenStep, se dispone de un primitivo mecanismo para gestionar el acceso a URLs, y sólo dispone de gestores para los protocolos file, http, https, y ftp. Para gestionar otros protocolos, un programa debe disponer de código para asumir esa gestión.

De otro lado, sea cual sea el modo en que se gestione la adquisición de información desde un URL, dicha información tendrá un formato determinado. No es lo mismo un archivo de Word que un archivo AppleWorks, y ninguno de los dos representa lo mismo que un archivo de Excel.

En las versiones de Mac OS X previas a Safari, se disponía del mismo mecanismo de acceso a URLs, pero además se introdujo la API de Internet Config dentro de Carbon. Curiosamente, no se portó el interfaz de Internet Config… y se aprovechó el navegador que se instalaba con el Mac OS X, Internet Explorer 5, para introducir tanto un panel de gestión de protocolos, como de gestión de «complementos», para aquellos tipos de archivo que el navegador no pueda manejar.

Gestión de protocolos mediante Internet Explorer. Puede verse el protocolo help asignado al Visor de Ayuda (Help Viewer). Click para ampliar.

Gestión de aplicaciones complementarias para el manejo de archivos mediante Internet Explorer.Click para ampliar

Tenemos, pues, una API capaz de manejar tanto protocolos —formas de acceso a la información— como tipos de archivo, pero sin una interfaz de usuario clara… ¡y cuyo gestor «estándar» ni siquiera pertenece al sistema operativo! El hecho de que la API está abierta lo demuestran aplicaciones como MisFox o RCDefault.

Puesto que una idea que vienen siguiendo todos los diseñadores de sistemas operativos es integrar al máximo posible el ordenador y la red, parece que un paso que hay que dar es tratar un URI, o una URL como que una especificación de archivo como Macintosh HD:Applications:Chess.app. De hecho, es posible convertir cualquier archivo local en un URL mediante el protocolo file:, y en el caso anterior tendríamos .

De ahí nace un un nuevo concepto, el de «Servicios de Lanzamiento», que permiten que cualquier aplicación llame a cualquier otra para que le preste un servicio determinado, pero sin tener que saber qué aplicación concreta es la que hay que llamar. Esta API está pensada para sustituir y ampliar Internet Config.

Mira, Mac OS X, ¡sin manos! La vulnerabilidad.

Si hace tiempo que estáis en el carro del Mac OS X, recordaréis que se habló al principio, con la versión 10.0 y 10.1, y antes de la salida de Safari, del hecho de que la única forma de registrar protocolos era mediante la utilización de Internet Explorer. Pero la pregunta es, ¿cuántas veces habéis accedido a estas preferencias de Internet Explorer últimamente? Al menos yo no lo hacía desde hace mucho tiempo, y si lo he hecho ahora ha sido para ilustrar este artículo 😉

Una de las mejores cosas que tiene el Mac OS X para los programadores —y si las cosas son fáciles para los programadores, es muy probable que las usen— es la forma en que se especifican y publican las capacidades de una aplicación, mediante el uso de archivos de propiedades. Así, simplemente arrastrando un archivo a disco, el Mac OS sabe que una determinada aplicación puede abrir determinadas clases de archivo. Y utilizando un registro del sistema, es posible establecer la relación inversa, y obtener qué aplicaciones son las que son capaces de abrir un determinado tipo de archivo. Podemos ver esta capacidad en acción si utilizamos la opción Abrir con sobre un archivo cualquiera. Por ejemplo, al hacerlo sobre este artículo, sólo hay cuatro programas que puedan abrir este archivo:

Click para ampliar

Pero claro, queremos que esta capacidad esté también disponible para los archivos remotos. ¿Cómo hacemos eso mismo para ellos? Es necesario saber qué protocolo utilizaremos para la obtención de los datos remotos, y quién se va a encargar de gestionarlo. Y a través de la API de Servicios de Lanzamiento o de Internet Config, una aplicación puede hacer que otra sea la que gestione un determinado protocolo. Si esa segunda aplicación dispone de un agujero de seguridad, podemos tener un problema.

Ya que está de moda, utilizaremos el Visor de Ayuda para ilustrar esto: el protocolo help: permite utilizar una forma constante de especificar un contenido, y si ese contenido no está disponible en un archivo local, obtenerlo de Internet. El problema es que este protocolo en concreto disponía de una opción capaz de ejecutar cualquier clase de código si quien crea el contenido sabe dónde se encuentra, y la gestión del URL se producía incluso cuando se había llamado a ese URL desde fuera del Visor de Ayuda. Si se ha descargado antes una imagen de disco —y se ha montado de forma automática—, es posible utilizar esta aplicación con un problema de seguridad en la gestión del protocolo para que ejecute código arbitrario.

Justamente lo único que arregla el parche de seguridad «Security Update 2004-05-24» es la posibilidad de ejecutar código arbitrario a través del protocolo help:, limitando la funcionalidad de la opción runscript para que sólo pueda ejecutarse código desde una página de ayuda, y no desde cualquier otro punto del sistema. Y con programas como MisFox —o el propio Internet Explorer, si no nos da alergia ;-)—, podemos hacer que otros protocolos estén asignados a programas más seguros.

Sin embargo, hay otro mecanismo por el que una aplicación puede introducir de forma totalmente inadvertida para el usuario un agujero de seguridad, intencionado o no, y es la gestión personalizada de URLs.

La idea de utilizar un registro de protocolos es especialmente útil cuando pueden existir muchos programas que gestionen un determinado protocolo: existen muchos navegadores capaces de gestionar el protocolo http:, y puede que queramos que sea un cliente concreto de FTP el que se utilice para las descargas, en lugar de que se monte una unidad en el Finder.

Pero, ¿qué ocurre si nuestra aplicación utiliza un protocolo propio? ¿Debemos «ensuciar» la base de datos de protocolos con el nuestro, cuando sólo es importante para nuestra aplicación? La solución es simplemente declarar qué URLs somos capaces de manejar, sin que exista una asignación: así el sistema se parece mucho más para el desarrollador al registro de tipos de archivo que un programa es capaz de abrir.

El problema aquí es que, simplemente mediante la descarga de una imagen de disco que se abre (protocolo disk, o simplemente un link de descarga automática), o mediante el montaje de cualquier unidad (ftp, smb, afp, webdav…), podemos hacer que un programa aparezca dentro de una unidad remota, pero eso ya ha disparado el mecanismo de registro automático de protocolos. Por ejemplo, una aplicación podría registrar el protocolo «malvado:». Si a continuación Safari ejecuta un URL del tipo «malvado://www.faq-mac.com/», por ejemplo, será el gestor del protocolo «malvado:» el que se active, y ese gestor de protocolo puede hacer cualquier cosa para la que tenga privilegios.

¿Por qué es una vulnerabilidad, y no un caballo de Troya?

Un Caballo de Troya es un programa que depende de una acción voluntaria del usuario para ponerse en marcha, y tiene como misión engañar al usuario tanto tiempo como sea necesario para que realice esa acción —típicamente, hacer doble clic sobre el programa—.

En este caso, basta con navegar a una página malintencionada para que se puedan poner en marcha una serie como esta:

a) El usuario entra en una página con cualquier navegador que utilice el sistema de gestión de URLs integrado en el Mac OS X

b) Esa página dispone de un código que hace descargar una imagen de disco, o que se monte una unidad remota

c) Esa unidad remota, o imagen de disco, contiene un programa que utiliza un gestor de protocolo propio, como «malvado:»

d) A continuación, cuando la página web remota estima que la imagen de disco o la unidad remota ha sido montada, se lanza otro URL, que en este caso contiene el protocolo declarado en c).

Esto quiere decir que una mezcla de automatismo y configuración dejan a cualquier usuario a merced del atacante. Por supuesto, no es posible atacar de forma activa al usuario que no haya llegado a una página «comprometida», pero sí es posible realizar acciones sin que el usuario las haya desencadenado voluntariamente. No es lo mismo descargar un programa que borra la carpeta de usuario y sus directorios pensando que es un procesador de textos al hacer doble clic sobre el icono, que simplemente encontrar que la entrada en la página que ofrece dicho artículo puede provocar ese borrado. La ejecución de programas es una acción de alto riesgo, mientras que simplemente navegar no debe serlo.

De todas formas, la ejecución de código arbitrario puede llegar por ejemplo a la retransmisión de datos locales del usuario, algo que puede considerarse tanto o más peligroso que las acciones sobre los archivos locales, y dar lugar a «spyware» de acción única, muy difícil de detectar, puesto que la transmisión se podría producir justo después de la descarga, en momentos de actividad de red, o cuando se vuelve a visitar la página web del desarrollador desde el programa «comprometido».

¿Qué puede hacer Apple para arreglarlo?

Está claro a partir de nuestra discusión anterior que el problema reside en la posibilidad de registrar automáticamente protocolos por parte de las aplicaciones, lo que unido a una temporización adecuada de acciones automáticas mediante código HTML crea la vulnerabilidad.

Las opciones son:

a) Eliminar el registro automático de protocolos; esto implicaría dejar de lado una parte de la API de lanzamiento de servicios

b) Avisar de que una aplicación registra protocolos, y cuáles son

c) Avisar de que una aplicación cambia protocolos

d) Avisar cada vez que se intenta abrir un URL con un protocolo no registrado permanentemente

Mientras que Apple decide qué hacer, Paranoid Android, de Unsanity, es una aplicación gratuita que realiza las acciones b) y d). No realiza a) por ser una acción realmente drástica, y no hay nada sobre c).

Lo importante es que la solución de Paranoid Android lo que hace es «engancharse» al mecanismo de gestión de URLs del Mac OS X, y controla los URL que se quieren resolver. Si el URL utiliza un protocolo «extraño», esto es, no es http, https, ni ftp, Paranoid Android avisa de ello, y pide que el usuario confirme que desea que se realice la acción, o por el contrario permite cancelarla. Así, recibimos un aviso cada vez que en alguna parte del sistema se gestiona un URL no habitual sin que el usuario haya sido quien iniciaba la acción.

También puede ser necesario que Apple atienda a c), impidiendo que esa base de datos pueda ser cambiada sin la introducción de una identificación de administrador. Pero recordemos que el registro automático no afecta a la base de datos de configuración de protocolos, sino sólo a la disponibilidad momentánea de un gestor de protocolos concreto. Así, si

Acerca de las últimas actualizaciones

Tal y como se menciona anteriormente en el artículo, lo único que arregla el parche de seguridad «Security Update 2004-05-24» es la posibilidad de ejecutar código arbitrario a través del protocolo help:, limitando la funcionalidad de la opción runscript para que sólo pueda ejecutar código desde dentro del Visor de Ayuda, no desde un URL proporcionado de forma externa.

La actualización de Panther 10.3.4 incluye todos los parches de seguridad anteriores, excepto el «Security Update 2004-05-24». Es posible instalar el parche de seguridad después de haber realizado la actualización a Panther. Y por supuesto, es posible actualizar cualquier versión de Panther a la versión 10.4 mediante el actualizador combinado, que pesa 79MB:

<http://www.apple.com/support/downloads/macosxcombined1034update.html>

Si 79MB os parecen muchos, os diré que el Service Pack 4 de Windows 2000 ocupa 140MB 😉

Referencias

Matt Neuburg, en TidBITS, aborda este mismo tema en menor profunidad [en inglés]

Información sobre Servicios de Lanzamiento [en inglés]>

Información sobre Internet Config [en inglés]

Más info sobre la vulnerabilidad en faq-mac:

<https://www.faq-mac.com/mt/archives/008509.php>

MisFox: Missing Internet Settings, programa para la gestión de asignaciones de archivos y gestores de protocolos [en alemán e inglés]

Paranoid Android: Programa, Descripción de la Vulnerabilidad, y páginas de ejemplo de la vulnerabilidad

<http://www.unsanity.com/haxies/pa/whitepaper/>

<http://www.geekspiff.com/unlinkedCrap/innocousPage.html>

<http://www.unsanity.org/rosyna/innocousPage.html>