Mucho se ha hablado de la vulnerabilidad del visor de ayuda y el montado de imágenes de disco DMG, este artículo no pretende más que clarificar y simplificar por completo lo que realmente representa el problema, al mismo tiempo que aportar soluciones temporales hasta que Apple disponga las actualizaciones de seguridad correspondientes..
A pesar del reciente parche que impedirá que puedan ejecutarse scripts ó aplicaciones a través del visor de ayuda y que, de algún modo elimina a ésta aplicación y protocolo de la vulnerabilidad, no significa que los posible problemas por la vulnerabilidad hayan cesado.
Ya que, lo cierto es que la vulnerabilidad va más allá, y es más complicada de lo que se pensaba al principio. Básicamente entran en conflicto sencillez y seguridad, en una combinación de situaciones que establecen la posible vulnerabilidad ante un software malicioso, y todas confluyen en como maneja los URI (Identificador de Recursos Uniforme) el sistema.
La culpa, la tiene el hecho, de que Mac Os X permite montar automáticamente volúmenes haciendo click o con un javascript que redirija a través de navegadores web compatibles a enlaces del estilo disk://loquesea, que montaría una imagen DMG, o cualquier otro protocolo del estilo, como file://, afp://, smb:// y un largo etc. Al hacer ésto con alguno de los protocolos que están por defecto registrados en InternetCondig, debería de montarse en el escritorio un volumen que podría contener cualquier cosa. Algo correcto, y que no supone ningún problema.
Pero sí cuando éste volumen contenga una aplicación con un archivo .plist que indique que puede usar un nuevo tipo de protocolo no registrado, ya que el encargado de registrar todos estos protocolos, InternetConfig lo registrará automáticamente sin necesidad de ejecutar la aplicación y sin preguntarlo al usuario, de forma que al solicitar alguna petición a través del nuevo protocolo registrado se lanzaría la aplicación independientemente del lugar donde se encuentre situada, tanto localmente como de forma remota. Siendo posible en el caso de alguna aplicación maliciosa, borrar o modificar al antojo cualquier archivo estacionado en la carpeta del usuario, aunque no en carpetas de sistema o de otros usuarios.
Además, no solo podría afectar a protocolos que monten volúmenes, si no que también afecta a otros tipos de protocolos como telnet://-nloquesea que escribiría un archivo vacío en el directorio principal del usuario llamado loquesea, y que puede sobreescribir archivos ya existentes, aunque no carpetas. Y así básicamente con cualquier protocolo registrado de cualquier aplicación no segura que se podría aprovechar.
Para solucionar el problema y suponiendo que se corrija el fallo de telnet://-n, no sólo bastaría con poner barreras a InternetConfig en el registro de nuevos protocolos. Ya que si solo se hiciese eso, se podría seguir accediendo automáticamente al visitar una web a otros protocolos a través de aplicaciones de terceras partes, y aunque esto ya sería problema de las compañías de estas aplicaciones, siendo posible proteger al sistema completo.¿Por que no hacerlo?
La solución completa para un parche por parte de Apple, si no se desea eliminar las posibles funcionalidades de InternetConfig, pasaría por una solución combinada impidiendo que InternetConfig registre éstos protocolos automáticamente, que puedan ejecutarse aplicaciones que no residen físicamente en el sistema conforme se solicite a través de uno de estos protocolos registrados, que a través de javascript se pueda redireccionar a este tipo de protocolos, que se notifique expresamente al usuario del registro de estos protocolos y de la petición remota para usar éstos y que se disponga de una opción en las preferencias del sistema para poder configurar correctamente el uso de las URI.
Como veréis, es más complicado de lo que parece, tanto para la creación de un parche por parte de Apple, como para el creador de virus que quiera aprovecharse de la vulnerabilidad.
Ya que un creador de virus tendría que atraer a los usuarios incautos a una determinada página web preparada con un javascript que primero montase un volumen en cuyo contenido se pudiese encontrar una aplicación que registre un protocolo determinado, y que posteriormente se recargase para ejecutar el protocolo que registre la aplicación. Pudiendo provocar ésta cualquier efecto para lo que el creador la haya preparado, siempre en el espacio de usuario y nunca en directorios protegidos ó encriptados.
Y éste, no tendría propagación alguna ya que para que pudiese ser reenviado a otros computadores sería necesario que incluyese un miniservidor/cliente de correo y que obtuviese las direcciones de la libreta de direcciones de Mac Os X, aún así sería necesario que los usuarios hiciesen click en el enlace o abriesen la aplicación, ya que Mail.app no permite por defecto la ejecución de código javascript ni de ningún tipo, y tampoco serían afectados los usuarios que hayan tomado las precauciones oportunas.
Como precauciones temporales, os avisamos de que algunos de los protocolos que podrían estar afectados son:
afp: Finder, afp.URLMounter
cifs: smb.URLMounter (NB: not from Safari)
disk: DiskImageMounter
disks: DiskImageMounter
file: Finder, Safari, RealOne Player, Opera
ftp: Finder, ftp.URLMounter, VLC, Opera
ftps: ftp.URLMounter (NB: not from Safari)
nfs: nfs.URLMounter (NB: not from Safari)
smb: smb.URLMounter (NB: not from Safari)
Podéis desactivarlos manualmente a través de MoreInternet ó RCDefaults, aunque desde faq-mac os recomendaríamos Paranoid Android una aplicación de Unsanity que no sólo os permitirá desactivar estos protocolos, si no que además os notificará del registro de éstos que podréis cancelar si lo deseáis.
Estoy completamente seguro de que Apple ya está trabajando en ofrecernos una solución, y que probablemente se encuentre estudiando la forma más efectiva de hacer que no se vuelva a repetir sin quitarnos ninguna funcionalidad. De hecho, Phill Schiller así lo ha afirmado, así que habrá que creerle, por el momento Apple ha sido bastante exquisita en lo que respecta a seguridad en sus sistemas, siendo Mac Os X uno de los sistemas más seguros en lo que a arquitectura se refiere, en cualquier caso, todos los sistemas tienen vulnerabilidades y fallos ya que para nuestra desgracia los desarrolladores de Apple son humanos…
NUMAN ya te he dicho que no, que los de Apple no son extraterrestres rockeros con máquinas del tiempo que nos posibilita que nos ofrezcan la tecnología del futuro a los maqueros con respecto a los peceros… : /
Ayer por la tarde tanto en el Mac OS X Panther Server como en el Panther me salto una actualizacion de Seguridad 24-5-04 en la que se corregian problemas encontrados en Help y ayuda, no es esta la actualización de la que hablais, yo creo que si, más que nada porque en una pagina de prueba para probar el exploit antes de esta actualización el exploit ejecutaba Terminal y ejecutaba comandos, en cambio despues de instalar la Actualizacion de Seguridad 24-5-04 y reiniciar al hacer el mismo proceso solo se hacia llamada a la Ayuda (eso por el link que tenia la pagina) peero ahi se quedaba, podia leer los articulos de ayuda de Panther je,je,je…
Un saludo y ya comentareis…
Hala, ya he instalado el Paranoid Android y reiniciado la sesión… y ahora, ¿qué? ¿tengo que hacer algo? porque no veo ningún panel suyo en las preferencias, ni nada. No llego a entender cómo funciona y si tengo que hacer algo.
Yo he instalado el Paranoid Android. Cuando una web me a intentado descargar un cgi sin consentimiento a disco, ha saltado el paranoid advirtiéndomelo y dejandome elegir entre descargarlo o cancelar. parece que Paranoid no se hace notar más que cuando es necesario
help:runscript=MacHelp.help/Contents/Resources/English.lproj/shrd/OpnApp.scpt string=bin:ls
este link hace un list ejecutando el Terminal, antes de instalar el parche de seguridad que he comentado más arriba, se ejecutaba sin mas, ahora ya no.
Nadie ha instalado este parche, antes de utilizar software como el Paranoid Android, el parche es de ayer día 24
About Security Update 2004-05-24
This update delivers a number of security enhancements and is recommended for all Macintosh users. This update includes the following components:
– HelpViewer
Aquí dejo el Link ya que en la pagina española aun no esta. Soporta todos los idiomas.
http://www.apple.com/support/downloads/securityupdate__2004-05-24_(10_3_3).html
Para la gente con la versión 10.2.8 este es el link
http://www.apple.com/support/downloads/securityupdate_2004-05-24_(10_2_8).html
Con esto ya no hay que utilizar ningun programa ni estar pendiente de avisos, por lo menos en este tema.
Ya veo cómo funciona. He probado a poner help://disk0 (por poner algo que tuviera el protocolo help) y me ha saltado un aviso del Paranoid. O sea que mientras no hay posibilidad de peligro, el Paranoid no hace nada. Ya veo que él mismo se ocupa de avisarte.
neodata,
El patch de Apple que indicas, sólo corrije la vulnerabilidad con “Help viewer”. El “Security Update 2004-05-24” de Apple para Panther no tiene ningún efecto en las vulnerabilidades encontradas con los protocolos: ‘disk:’, ‘disks:’, o ‘telnet:’ , ‘afp:’ o ‘ftp:’.
Para la gente que esta usando Jaguar todavía, en el “Security Update 2004-05-24 para Jaguar” además del nuevo “Help viewer”, al menos también se incluye una última actualización de la Terminal que soluciona la vulnerabilidad con ‘telnet:’.
Pero éste no es el caso con el “Security Update 2004-05-24 para Panther” que sólo corrije la vulnerabilidad con “Help viewer”…en Panther las vulnerabilidades existen todavía con los protocolos ‘disk:’, ‘disks:’, o ‘telnet:’ , ‘afp:’ o ‘ftp:’.
La única solución en Panther para evitar las vulnerabilidades con los protocolos mencionados, es instalar “RCDefaultsApps” para desactivar esos protocolos o usar “Paranoid Android” que funciona observando los esquemas de URI requeridos y los detiene, ofreciendo la oportunidad de elegir si se desea continuar o cancelar el pedido (ofrece más control).
Aunque el 99% de lo que poneis aqui me suena literalmente a chino, uno os agradece que que esteis ahi y el entusiasmo que le poneis.