Menú principal

jueves, 31 de marzo de 2011

La web de Apple otra vez hackeada para distribuir malware

Los ataques masivos para distribuir malware se empezaron a poner de moda hace ya varios años. La idea es que el atacante selecciona las víctimas a través de un programa automático que busca patrones en los buscadores como Google o Bing. Una vez obtenida una larga lista de sitios vulnerables, se realizan ataques SQL Injection a todos ellos, que están especialmente creados para introducir código script malicioso en la página web. Así, cuando un visitante navegue por la web vulnerada será atacado con un exploit que tratará de ejecutar un malware en su máquina.

En este caso, la empresa de seguridad Websense ha publicado cómo se ha producido un ataque en masa para añadir referencias maliciosas a LizaMoon.com en 280.000 sitios, utilizando esta técnica de SQL Injection en masa.

Figura 1: Apple.com hackeada
Lo curioso es que la web de Apple se ha vuelto a ver afectada y aparece entre los sitios vulnerados que distribuyen malware. Hay que decir que Apple está trabajando rápido y ha limpiado la web de cualquier referencia a este sitio, aunque aún es posible acceder a los resultados utilizando la caché de los buscadores, y ver como, en esta ocasión, el código era inyectado en el título de los podcast en iTunes.

Figura 2: Inyección en el código fuente del script malicioso

En este caso se desconoce el número de usuarios que han podido caer en el engaño, o el número de enlaces que resultaban efectivos, ya que estos podcasts también son leídos por medio de lectores RSS. El caso es que no es la primera vez que Apple cae en esquemas de ataques de SQL Injection masivo para distribuir malware. Ya en Agosto de 2010 cayó en otro ataque masivo a través de la web de iTunes.

Figura 3: Hackeo e inyección en Agosto de 2010

También fueron hackeados los foros el año pasado y, en Zone-h se puede ver una lista de sitios a los que se hizo defacement en Appe.com. Lo cierto es que la web de Apple deja mucho que desear en seguridad. Hace ya más de un mes y medio, nosotros reportamos unos fallos de seguridad en la web de Apple que encontramos, y tras un rápido correo de respuesta aún estamos esperando a ver si los arreglan, para que os los podamos contar.

Como recomendación final, para evitar que una navegación normal por una página web te infecte de malware te damos las recomendaciones habituales:

1) Ten todo el software de tu sistema actualizado.
2) Ten instalado un antimalware con protección en tiempo real.
3) Instala una solución AntiXSS en el navegador que utilices.
4) Navega por Internet con un usuario poco privilegiado.
5) No confíes en ninguna descarga de ficheros automática.

miércoles, 30 de marzo de 2011

Apple juega con los jailbreakers al gato y al ratón

iOS 4.3.1 con jailbreak
Al más puro estilo de película de espías se está poniendo el guión de la película que protagonizan en Internet tanto Apple como los hackers centrados en la creación de exploits válidos para hacer un jailbreak a los dispositivos de la compañía. Y ahora parece que se habla de que Apple tiene hasta infiltrados en los grupos de hacking

Todo comenzó con la aparición de iOS 4.3 y una clara apuesta de Apple por poner las cosas más difíciles a los exploiters añadiendo ASLR y parcheando todos los bugs conocidos. Sin embargo, Stefan Esser, conocido como i0n1c, publicó un vídeo en el que se veía que tenía un iPad con iOS 4.3 con el jailbreak realizado en modo untethered, es decir, de forma permanente.

Sospechosamente, y de forma apresurada, Apple saca el viernes pasado iOS 4.3.1, una minor update que soluciona pequeños fallos de seguridad y hacía presuponer que iba tras un bug que estaba siendo utilizado para hacer ese jailbreak.
.
Por supuesto, dejando a todos anonadados, parchea el bug de comex, que existía desde la versión de  iOS 4.0.2, sin que nadie le hubiera dado ninguna información y que estaba siendo utilizado para el untethered jailbreak.

¿Cómo descubrió la información? Muchas son las posibilidades, que pueden ir desde una revisión rutinaria - a la que se le da credibilidad menos 3 -, a un chivatazo interno, que es lo que se sospecha. Se ha llegado a decir públicamente que existe la posibilidad que en el iPhone Dev Team se haya infiltrado alguien de Apple.


Mientras tanto la comunidad hacker continúa trabajando en nuevos exploits y herramientas, en Redmond Pie han publicado un tutorial de cómo hacer un tethered jailbreak a los dispositivos con iOS 4.3.1, utilizando PwnageTool, gracias al trabajo del hacker DjayB6.

martes, 29 de marzo de 2011

MacBook Pro: 1.000 €. Prey: Gratis. Pillar al ladrón que te ha robado el portátil haciendo el subnormal: Priceless

Divertidísima historia la que recibo por el lector RSS,  tanto que me animo a escribírla aquí para que tengáis ese par de minutos al día de distensión y relajación mental, aprovechando al mismo tiempo para recomendaros el uso de herramientas de vigilancia/administración remota del equipo, como puede ser Prey, al igual que utilizó "la víctima" de esta historia a la hora de acceder a su computadora portátil robada.  Vamos con la historia.

Presentación

Recientemente le robaron la computadora portátil a Mark Bao, joven empresario de tan 18 años que en su día ganó notoriedad cuando vendió Threewords.me. Bien, ese fin de semana, Mark Bao consiguió acceder de forma remota al disco duro de su ordenador robado y encontró un video vergonzoso del culpable del hurto haciendo el gañan con un baile que no tiene desperdicio.

Video 1: El video del gañan que le robó el portátil haciendo el toli

Trama

Ahora, lo que más me ha divertido es lo que viene a continuación: Mark Bao decidió publicar el vídeo en YouTube, titulándolo: "No robes computadores que pertenezcan personas que sepan cómo usarlos." 

Seguidamente, Mark Bao envió el vídeo a Reddit (sitio web de marcadores sociales donde los usuarios pueden dejar enlaces a contenidos web y otros usuarios pueden votar a favor o en contra de los enlaces, haciendo que aparezcan más o menos destacados) en un post titulado “Este idiota robó el portátil de alguien, se hizo un video y el propietario accedió a su disco de forma remota y pudo recuperar el video del culpable." 

"Creo que publicar aquí ayudará a maximizar la vergüenza del tonto del culo”, dejando a continuación el siguiente comentario: “Wow Jajaja, este es mi video! Uh, es decir, yo soy el tipo qal que robaron la computadora. (No el tipo de baile.) “

Imagen 1: Comentario de Mark Bao notificando la recuperación del portátil

Desenlace

La policía localizó al sospechoso y cuando se encontraban preparando la orden judicial,el ladrón devolvió el portátil ese mismo día a las 2 am. El calamidad ya ha sido expulsado de la Universidad de Bentley (Waltham, Massachusetts) donde Mark Bao es un estudiante de primer año. Todo esto es sabido por una nota de arrepentimiento que publicó el ladrón pidiéndole perdón a Mark Bao y, lo que es más importante, que por favor, retirara su video donde aparece haciendo el gañan de YouTube.

Imagen 2: Nota de arrepentimiento tardío del ladrón

La respuesta de Mark Bao ha sido: "No lo voy a hacer" - "No está en condiciones de negociar." ¿Y tú qué hubieras hecho?

Update: En esta historia no se utilizó Prey, sino una herramienta de administración de backups.

lunes, 28 de marzo de 2011

Fallos y rarezas en MacBook Pro con Turbo Boost

Hace unos días nos enteramos que Apple, con el afán de no perder el ritmo tecnológico al que evolucionan los procesadores de Intel, ha estado probando la nueva arquitectura Sandy bridge con la idea en mente de implantarlos en un futuro a corto plazo en sus ordenadores portátiles.

La arquitectura Sandy Bridge proporciona integración AES (Advanced Encryption Standard), HT (Hyper-Threading), VMX (Virtualization Machine Extensións), AVE (Advanced Vector Extensions) pero principalmente una de las características que la identifican es un procesador gráfico integrado en la unidad de control de proceso (IGP + CPU), esto es, que integra las funciones gráficas en la misma pieza de silicio que el procesador principal con tecnología Turbo Boost 2.0 de forma independiente para cada unidad.

Figura 1: Arquitectura Sandy Bridge

La idea de la tecnología Intel Turbo Boost 2.0 es la de incrementar de forma automática la velocidad de procesamiento de los núcleos por encima de la frecuencia operativa básica si no se alcanzan los límites especificados de energía, corriente y temperatura. Turbo Boost 2.0 se activa mediante mandato del sistema operativo para activar el máximo desempeño del procesador. La frecuencia máxima alcanzada dependerá de la cantidad de núcleos activos.

La tecnología Intel Turbo Boost 2.0 se activa cuando el sistema operativo (SO) solicita el estado de máximo desempeño del procesador (P0). La frecuencia máxima de la tecnología Intel Turbo Boost 2.0 depende de la cantidad de núcleos activos. El tiempo durante el cual el procesador se mantiene en el estado de la tecnología Intel Turbo Boost 2.0 depende de la carga de trabajo y del entorno operativo.

El techo para Turbo Boost 2.0 (el tiempo máximo que se encuentra activa dicha tecnología) para una determinada carga de trabajo puede venir establecido por cualquiera de los siguientes factores:

• Cantidad de núcleos activos
• Consumo estimado de corriente
• Consumo estimado de energía
• Temperatura del procesador

Cuando el procesador funciona por debajo de estos límites y la carga de trabajo del usuario exige mayor desempeño, la frecuencia del procesador aumenta de forma dinámica hasta alcanzar su límite superior.

Figura 2: Turbo Boost en el mítico Kit
Bien, aquí es donde la cosa se pone interesante. Según algunas pruebas realizadas por la revista PCPro, algunos de los resultados devueltos en el testeo de dicho entorno (combinación de portátiles Apple con arquitectura Sand Bridge) demuestran que el Turbo Boost brilla por su ausencia.

Y es que resulta que los análisis realizados para mostrar la tecnología Turbo Boost 2.0 de Sandy Bridge, la cual gestiona de forma dinámica uno, dos o cuatro núcleos en función de la carga de la CPU, parece que demuestran que dicha tecnología no funciona en caso de que las térmicas detecten que su uso pueda afectar negativamente al entorno provocando una subida de temperatura. Es decir, que los factores térmicos de dicha tecnología impiden el uso dinámico de varios núcleos.

Las pruebas, han sido realizadas con procesadores i5 e i7 (ambos con doble núcleo) sobre 13in MacBook Pros ejecutando Windows 7 a través de sistema multi-OS Boot Camp, el cual permite ejecutar versiones compatibles de Microsoft Windows en Mac equipados con Intel, y se ha demostrado que Turbo Boost funciona con el primer núcleo pero no en el segundo.

Esta nefasta noticia ha sido corroborada por Anandtech, que ha confirmado que el procesador i5 planeta dicha problemática tanto en Windows 7 como en Mac OS X, mientras que, como rareza, con el procesador i7 sólo se encuentra mal funcionamiento en sistema operativo Windows.

Ahora sólo queda preguntarnos si Apple ha tenido algo que ver a la hora de establecer el mal funcionamiento de esta tecnología sobre sus Mac Books con sistemas Windows, aunque de seguro (como ya han comentado algunos) desde luego que ayudará a algunos usuarios a que migren de sus sistemas PC a entornos MAC para no perder el uso de dicha tecnología. Mientras tanto, ya sabemos todos cual es el único Turbo Boost que nunca falló cuando se le necesitaba.

domingo, 27 de marzo de 2011

Fue noticia en Seguridad Apple: del 14 al 26 de Marzo

Llegamos al resumen bisemanal de noticias publicadas en Seguridad Apple como cada dos domingos. Durante este periodo se ha lanzado iPad 2 en España y, por supuesto, ya han empezado a proliferar las noticias de herramientas para hacerle jailbreak.

Además, durante este periodo de tiempo, también nos hemos encontrado con actualizaciones de software de software desde Apple y otros fabricantes para arreglar fallos de seguridad, y alguna noticia curiosa relacionada con el cada vez más extenso mundo Apple. Éste es el listado de posts que hemos publicado aquí.

El lunes 14 de Marzo comenzó la semana con el último artículo de la serie dedicada al funcionamiento del troyano Hellraiser, en el que hemos añadido unos vídeos de ejemplo para que se vea rápidamente cómo es el funcionamiento de este troyano. Hay que recordar que Mac OS X Snow Leopard trae una firma para detectarlo dentro del servicio que viene en el equipo de Malware Checker. Además, ese día, volvimos a tener la noticia de nuevos fallos con el cambio horario y los terminales iPhone, que en lugar de adelantar una hora la atrasaban. Hoy es el día del cambio horario en España y habrá que esperar a ver cuantos usuarios se ven afectados.

El martes tuvimos la noticia de la publicación de los fallos descubiertos por VUPEN en Apple Safari durante el concurso Pwn2Own. Hay que recordar que ellos fueron el equipo ganador explotando una MacBook Pro de 64 bits con Mac OS X Snow Leopard 10.6.6 a través de un 0day en Apple Safari 5.0.3. Además, ese día corría por Internet la noticia de un fallo de seguridad Adobe Flash que estaba siendo explotado a través de ficheros Excel en los que se incrustaban los SWF maliciosos.

Durante los días 16, 17 y 18 publicamos una traducción de un interesante artículo publicado por Michael Pietroforte, que posee un galardón como Microsoft Most Valuable Professional (MVP), en el sitio web 4sysops, en el que se muestra Cómo unir un Mac OS X a un Active Directory

Al mismo tiempo que publicamos esa serie, el día 17 nos hacíamos eco del problema de falsos positivos que habían sufrido los usuarios de F-Secure Mac Protection en Beta, que vieron como muchos archivos benignos eran firmados como malware debido a una mala actualización del producto.

El sábado 19 la noticia la guardamos para una curiosa estafa que se está produciendo en la que se usa como gancho un iPad morado. Exista o no algún iPad morado mediante técnicas de modding, la foto deja ver un producto bastante feo que dudamos hasta de su existencia. En cualquier caso los sitios que lo están usando como reclamo son para hacer estafas.

A partir del domingo 20 empezamos a publicar una entrevista en cuatro partes realizada a Charlie Milller y Dino Dai Zovi por la revista Mac & I. Estos dos investigadores de seguridad son, con mucha probabilidad, dos de los más famosos hackers en el mundo Apple.

Durante estas cuatro entregas tituladas Hackers contra Apple,  se despachan sobre todos los temas de seguridad relativos a Mac OS X, Apple Safari, las medidas de seguridad actuales y futuras con Mac OS X Lion, la publicación de exploits y hasta la actitud de la propia Apple ante la seguridad de sus sistemas y las vulnerabilidades descubiertas.

El lunes 21 nos hicimos eco del fallo publicado por Chema Alonso en Apple Safari 5.0.4 que permite engañar a los usuarios con nombres de archivos largos, para que se descarguen programas ejecutables simulando ser vídeos. El truco es un juego de nombres de doble extensión que, debido a la forma en que se muestran estos nombres hace que sea fácil engañar al usuario.

El miércoles 23, con la aparición de Mac OS X 10.6.7 y la actualización de seguridad 2011-1 para Mac OS X Leopard, publicamos un resumen de novedades. Entre ellas, además de los fallos de seguridad y la actualización de Apple Safari a la versión 5.0.4, aparece la actualización de Malware Checker para reconocer un spyware que está afectando a muchos usuarios: OSX.OpnionSpy.


Para terminar las dos semanas, ayer sábado, publicamos la aparición, en viernes y por sorpresa, de iOS 4.3.1, para solventar fallos de seguridad y estabilidad del controvertido iOS 4.3 que tan preocupados ha dejado a todos los usuarios que se han quedado sin actualizaciones de este software.

Y eso ha sido todo, que esperamos que no os haya sabido a poco. Nos vemos en este resumen dentro de dos domingos.

sábado, 26 de marzo de 2011

Apple parchea iOS 4.3 a 4.3.1 ¿Para evitar el jailbreak?

A todo el mundo ha pillado por sorpresa la actualización del sistema operativo de dispositivos móviles iOS de Apple a la versión 4.3.1. Los rumores decían que la versión sería puesta en circulación en dos semanas, así que todo el mundo esperaba que fuese la semana siguiente la que viera salir este update, pero Apple lo dejó ayer disponible para todos.

Poner una actualización de software en viernes es quizá la menos esperada de las decisiones para el mundo empresarial, ya que, con el fin de semana por delante, pensar en actualizar software en viernes es algo que se suele descartar en todas las empresas. Además, en caso de dar un problema, los equipos de soporte están con menos personal, incluido los de Apple. Pero.., ahí está, salió ayer.

En la nueva actualización arregla, según la información disponible en la web

• Soluciona un error gráfico esporádico en el iPod touch (cuarta generación).
• Resuelve problemas relacionados con la activación y conexión a algunas redes móviles.
• Soluciona el parpadeo de la imagen al usar un adaptador de AV digital de Apple con algunos televisores.
• Resuelve un problema al autenticar con algunos servicios web de empresa.

iPad 2 con jailbreak corriendo Cydia
Sin embargo, la aparición del vídeo de Stefan Esser (i0nic), creador de Antid0te, en el que demostraba que había hecho un untethered jailbreak a dispositivos iOS 4.3, y la anunciada herramienta de jailbreak para la semana que viene, quizá ha hecho acelerar el proceso.

Además, se especula con la posibilidad de un parcheo del fallo descubierto por Charlie Miller en la última Pwn2Own en Apple Safari para iOS que, a pesar de que en el concurso fuera explotada en iOS 4.2 y que, como el propio Charlie Miller dijo, sería mucho más difícil de explotar en iOS 4.3 debido al ASLR, podría constituir un riesgo tenerla sin actualizar.

En cualquier caso, sea para lo que fuera, ya está disponible para descarga vía iTunes para que puedas actualizar los dispositivos a versiones parcheadas de iOS 4.3.1.

viernes, 25 de marzo de 2011

Hackers contra Apple: Charlie Miller y Dino Dai Zovi (4 de 4)

=======================================================================
=======================================================================

¿Puede Apple ofrecer sistemas seguros?

Mac & I: resumiéndolo todo, ¿crees que Apple tiene lo que se necesita para hacer informática segura para los usuarios? ¿Sólo necesitarían actualizar sus tecnologías, o es también una cuestión de actitud en su gestión hacia la seguridad?

Charlie Miller "jugando" con un iPhone
Charlie Miller: Apple es, sin duda, capaz de desarrollar un producto seguro, pero no han hecho el esfuerzo aún. Son una empresa de productos. Los nuevos y emocionantes productos se venden y hacen dinero con ellos, sin embargo con la seguridad no. Si examinamos el iPhone original, se vendió espectacularmente, pero la seguridad fue simplemente terrible.

Hay una percepción (que está cambiando lentamente) de que los productos de Apple son seguros. Supongo que Apple dice: ¿por qué gastar dinero en seguridad cuando ya están considerados seguros?. Tendrán que tener una crisis de seguridad como sucedió con Microsoft hace casi diez años para que Apple cambie. La seguridad debe afectar a su línea de flotación.

También se han hecho un poco a un lado porque han venido haciendo publicidad de características de seguridad como ASLR desde que Leopard salió hace cuatro años. ¿Cómo deberían de anunciar una seguridad adicional para Lion? "Lion tiene un ASLR que realmente funciona", o tal vez, "Lion ha cogido a Windows Vista en seguridad"?


Dino Dai Zovi: Si se comparan las características de seguridad de iOS frente a Mac OS X, se puede ver que Apple ha implementado varias funciones de seguridad por el interés en su negocio. Y en iOS, la mayoría de las características de seguridad están destinadas a proteger el modelo de negocio de Apple (iTunes Store) en lugar de los datos del usuario. Por supuesto, esto no es sólo de Apple, cada fabricante de software comercial hace lo mismo. La seguridad no les hace ganar dinero, la venta de productos si, por lo que sólo proporcionan el nivel mínimo de seguridad necesario para mantener a los clientes y que sigan comprando sus productos. No hay necesariamente nada de malo en ello.

Si miramos a los navegadores web, Google invierte el mayor esfuerzo en la seguridad de su navegador, Chrome. El modelo de negocio de Google es que se siga utilizando la Web, lo que requiere que los usuarios sigan confiando en la web con su tiempo y sus datos.

Dino Dai Zovi en una foto divertida
Como ellos son los que más pierden si los consumidores pierden la confianza en la Web, entonces gastan más dinero para garantizar que sea lo más seguro posible. La mayor parte de los esfuerzos de Google se emplean en las versiones Windows y Linux de Chrome, mientras que la versión de Mac OS X se beneficia de muchos de esos esfuerzos gratuitamente.

Mientras que Apple tenga como clientes principales a los usuarios de casa, y mientras estos estén a salvo del malware masivo dirigido a los consumidores para robarles la identidad y los datos bancarios, no hay mucho más que Apple necesite hacer.


Mac & I: Por cierto, cuando vas a buscar una vulnerabilidad en OS X, ¿tienes herramientas especiales a tu disposición, o tus "armas" están disponibles para los malos también?

Charlie Miller: Parte de la motivación de escribir el “Manual del Hacker de Mac” fue sacar toda nuestra experiencia al mundo, especialmente los buenos. Los malos tienden a saber esto ya. Nosotros damos charlas regularmente sobre cómo encontrar y explotar los errores, a menos que Dino tenga alguna salsa secreta que yo no sepa, todo nuestro conocimiento es público.

Dino Dai Zovi en una charla
Dino Dai Zovi: No hay realmente una magia o salsa secreta que se necesite para detectar las vulnerabilidades de seguridad de Mac. El "Manual del Hacker de Mac" muestra varias formas fructíferas: fuzzing, mirando los registros de cambio de software de terceros e ingeniería inversa. Personalmente, prefiero pasar mi tiempo de calidad en IDA Pro escribiendo fuzzers. Y ni siquiera tengo scripts mágicos que pueda utilizar, solo un proceso manual y metódico de lectura de binarios, renombrado de variables y funciones y desarrollar mi entendimiento de cómo funciona todo.

Además del libro que escribí con Charlie, también doy formación de hacking de Macs en las conferencias BlackHat con Vincenzo Lozzo. Cualquier persona interesada en aprender cómo encontrar vulnerabilidades en Mac OS X es bienvenido a nuestras clases.


Mac & I: …Parece que el hacking moderno es todavía un trabajo manual, como en los viejos tiempos. Todavía recuerdo como cambiar mi Apple//e's OS para aceptar comandos en minúsculas... Bueno, vamos a terminar esta entrevista con algo serio de verdad. ¿Por qué no participar en el desafío de Firefox como un equipo?

Dino Dai Zovi: Creo que Charlie ha demostrado bastante bien que él no necesita ninguna ayuda a ganar PWN2OWN ;). Me gusta ser el primero en conseguir un objetivo concreto en Pwn2Own. Fui el primero en adueñarme de un Mac en el Pwn2Own de 2007, así que no me siento como que necesito hacerlo otra vez. Me hubiera gustado haber sido el primero en adueñarse de un iPhone allí, pero Ralf-Philipp Weinmann y Vincenzo Lozzo ya me ganaron en esa pelea. Tal vez un año de estos aparezco con una sorpresa bajo la manga, pero no me esperen.

Charlie Miller: Ahora ¿por qué querría dar la mitad de mi dinero a Dino?

Mac & I: La última pregunta va para Charlie - Probablemente la pregunta que más te hacen: Lo harás de nuevo en Pwn2Own 2011, y si es así, ¿ya tienes un error que explotar? ¿Tal vez Safari 5?

Charlie Miller: No estoy seguro. Es realmente mucho esfuerzo y presión para un premio no demasiado grande. Creo que he probado las dos cosas que me dispuse a probar: que los productos de Apple no son perfectos en seguridad y que puedo escribir exploits.

El problema es que puedes tener un exploit y se puede haber parcheado una semana antes de la competición o alguien puede mostrarlo antes que el tuyo y no obtienes nada. Supongo que depende de las reglas de este año. Es una gran competición y se pasa muy bien. Y que si tengo un exploit en mi bolsillo, pues un caballero no discute de esas cosas, pero como yo no soy un caballero, entonces sí.

Nota de la traducción: En el Pwn2Onw ganó el equipo de Vupen con un exploit para Apple Safari 5.0.3 sobre Mac OS X Snow Leopard de 64 bits. Charlie Miller explotó con éxito una vulnerabilidad en iPhone con iOS 4.2 que le permitió ganar un premio.

=======================================================================
=======================================================================

jueves, 24 de marzo de 2011

Hackers contra Apple: Charlie Miller y Dino Dai Zovi (3 de 4)

=======================================================================

OS X sandboxes y seatbelts

Mac & I: Apple ha demostrado con iOS que hay formas de, al menos, hacer mucho más difícil para los atacantes explotar un agujero de seguridad. ¿Es esta (aparente) dependencia de código antiguo que has mencionado antes, también la razón de porqué Apple no defiende más en el uso de políticas sandbox y seatbelt en OS X? Las extensiones de Safari parecen estar aisladas (sandboxed), pero Safari como tal parece esar desprotegido.

Dino Dai Zovi: Creo que la seguridad mejorada y única de iOS (por ejemplo, la cadena de confianza de arranque, el uso integrado de sandbox, las políticas de forzado de uso de código firmado) ha sido diseñada principalmente para proteger el modelo de negocio de Apple, más que los datos de los usuarios. Esto proporciona a Apple un incentivo económico para trabajar duro en ello. Sin embargo el retorno de inversión de la protección de los datos de los usuarios es menor en cuantía económica. También, uno debe tener en mente que las amenazas de malware contra Mac OS X son todavía muy raras. A medida que el mercado de Mac crece, Apple debería implementar características de seguridad mejoradas para estar por delante de las amenazas.

Charlie Miller
Charlie Miller: Apple claro que podría aislar algunas de sus aplicaciones para hacerlas más robustas ante ataques, o al menos establecer una opción para esto (por ejemplo, una opción para ejecutar Safari en modo de seguridad alto o algo así). El problema cuando ves una aplicación como Safari es que está diseñada para hacer tantas cosas que es difícil crear reglas de aislamiento que limiten la acción del malware. 

Safari puede “Abrir”, o “Guardar” archivos, así que los exploits o malware serán capaces de hacerlo también. Así que es difícil establecer un aislamiento genérico para Safari. Se todas formas, algo como el complemento Flash de Safari se podría aislar fácilmente (se ejecuta en un proceso separado) y no sé por qué no lo han hecho ya.

Mac & I: De hecho, parece que Flash tiene un serio problema de estabilidad y debería de aislarse. – Tengo Safari en mi MacBook y se congela continuamente por culpa de Flash. Supongamos que esto no lo hace Apple a propósito… mientras tanto, el navegador de Google aísla todos sus procesos, así que es claramente factible. Además, pagan desde unos pocos dólares hasta miles de dólares por vulnerabilidades en Chrome. ¿Tiene Apple una política similar de recompensas por el trabajo de especialistas de seguridad?

Dino Dai Zovi: Safari ejecuta un número de aplicaciones heredadas de 32 bits, incluyendo Flash y Quicktime, cuando Safari se ejecuta en procesos de 64 bits en Snow Leopard. Esto se ha hecho principalmente por compatibilidad, pero tiene también algunos beneficios de estabilidad ya que un complemento que falla no se lleva por delante el resto del navegador. El navegador de Google ha sido diseñado desde cero con un modelo de multi proceso para aislar los procesos render y los complementos entre sí, y también para soportar sandbox. Es un trabajo significativo migrar el código base de un navegador existente (por ejemplo, Safari, Firefox o Internet Explorer) a un modelo completo multi proceso. 

Google ha sido bastante progresista en el uso de programas de recompensa de detección de errores para incentivar financieramente a investigadores externos a que echen un vistazo a varios de sus productos e informar de sus conclusiones. Apple contrata ingenieros de seguridad y consultores, pero no tienen un programa similar para recompensar a los investigadores externos que hagan informes de vulnerabilidades voluntariamente.

Alex Sotirov (izquierda) y Dino Dai Zovi (derecha) con un cartel de "No más bugs gratis"

Charlie Miller: No, Apple no paga a investigadores. Apple tiene la visión de que ellos no tienen un problema de seguridad y no necesitan trabajar con investigadores. Compara esto con Microsoft, que apoya conferencias de seguridad, trae a los investigadores para que hablen con su gente, hace reuniones para investigadores y tiene un equipo de investigación de seguridad que libera documentación técnica y herramientas. Apple no hace nada de esto y tiene muy poca comunicación con los investigadores de seguridad. No creo que nunca hayamos recibido un correo o una llamada de teléfono de Apple como respuesta a algo que le hemos enviado. Este no es el caso con otras compañías como Microsoft o Adobe, que abiertamente se comunican conmigo para ver en que estoy trabajando y si tengo ideas que les ayuden, etcétera.

Jacob Appelbaum
Mac & I: La compatibilidad con el código existente es ciertamente una espada de doble filo. Mientras que se hace por los usuarios, esto mismo puede impedir el progreso y la innovación, lo cual no siempre es bueno cuando se habla de software - y probablemente es un poco inesperado cuando se habla de Apple, uno de los principales innovadores de la industria.

Jacob Appelbaum, conocido por sus ataque de arranque en frío (cold boot), una vez comentó que había enviado un informe de un error de visibilidad de contraseña en loginwindows.app y resulta que era un duplicado, dos millones y medio de errores después

Hemos oído que el error podría esta todavía abierto. – ¿Dirías que esto es sintomático del objetivo de seguridad de Apple o probablemente solo un episodio desafortunado?

The Mac Hackers's Handbook
Charlie Miller: He encontrado la seguridad de Apple bastante sensible a los errores de los que he informado, pero de nuevo, tiendo a pensar que obtengo de ellos mejor servicio que la media :). En una cuestión relacionada, Apple ha tenido algunos problemas para mantener actualizados algunos componentes de código abierto de su sistema operativo. Algunos ejemplos que me vienen a la mente son PCRE, Samba y Java. Existen vulnerabilidades generalmente bien conocidas, a veces con exploits conocidos, para estos paquetes que no están actualizados en OS X.

Dino Dai Zovi: Apple también ha respondido bastante bien a mis envíos de errores como dice Charlie, y además me he dado cuenta que el construir una reputación con ellos a lo largo del tiempo mediante el envío de vulnerabilidades bien analizadas es sin duda de gran ayuda. Incluso así, la comunicación siempre es unidireccional y se ponen en contacto contigo sólo si necesitan más información, si no, son bastante silenciosos. Estos días, más bien prefiero enviar mis conclusiones a alguien como ZDI y dejarles que gestionen la comunicación con el fabricante por mí, así puedo continuar con mi vida.

=======================================================================

miércoles, 23 de marzo de 2011

Mac OS X 10.6.7 Fixes, updates y antispyware

El pasado día 21 de Marzo, Apple lanzó una nueva actualización de su sistema operativo Mac OS X 10.6 Snow Leopard en concreto la actualización 10.6.7 al mismo tiempo que sacaba actualizaciones de seguridad para Mac OS X Leopard, tanto en la versión servidor como en la de clientes.

Figura 1: Actualización de Mac OS X 10.6.7

¿Qué trae Mac OS X 10.6.7?

En primer lugar esta actualización viene a resolver muchos de los problemas de estabilidad de los que se quejan muchos usuarios en los nuevos Mac Book Pro. Entre otros, los fallos con los nuevos microprocesadores de Intel que tienen descolocados a los usuarios debido a la increíble aleatoriedad de los fallos que producen.

En segundo lugar, hay que recordar que cada actualización del producto corrige fallos de seguridad descubiertos, por lo que se hace importante siempre actualizar lo antes posible. No se debe dejar pasar que, para un creador de exploits, siempre es más fácil realizar el programa que saque partido de un fallo cuando existe el parche, ya que, realizando comparación de los binarios afectados antes y después de parchear – usando técnicas de bindiff – es posible encontrar el fallo en la versión sin parchear rápidamente.

En esta ocasión, por supuesto, también es así, por lo que se han corregido una lista de 56 vulnerabilidades, todas ellos con su CVE correspondiente para poder analizarlas. Estos fallos de seguridad afectan a partes tan accesorias – o no, según se mire – como las librerías bzip o Quick Time – pero también a partes tan importantes como el kernel o el motor PHP en la versión servidora. Puedes ver todos los expedientes de seguridad en el siguiente enlace: Security Updates en Mac OS X 10.6.7

Además, no hay que olvidar que Apple introduce en esta actualización Apple Safari 5.0.4, es decir, que se verá actualizado el navegador corrigiendo los fallos de seguridad descubiertos, y ya publicados previamente – incluso los del Pwn2onw -, en la versión 5.0.3.

Respecto al malware, a Apple le cuesta poco a poco ir reconociendo que tiene que tiene que dar una solución antimalware a sus usuarios, y el servicio que trae Mac OS X Snow Leopard de Malware Checker. Anteriormente había actualizado las firmas para Hellraiser, pero no lo había anunciado, ahora, en esta ocasión, actualiza las firmas para detectar el Spyware OSX.OpinionSpy, que se ha visto instalado en muchas máquinas.

Figura 2: Malware checker detecta OSX.OpinionSy para Mac OS X

Por último, con esta actualización también vienen nuevas cosas, en concreto se añaden cambios en la Mac Store y pequeñas modificaciones en las herramientas multimedia para mejorar situaciones de estabilidad.

Actualizaciones de Mac OS X Leopard

También se han actualizado las versiones de Mac OS X 10.5, con sendas descargas para las versiones servidora y cliente. En este caso aparecen como Security Update 2011-1, pero son exactamente los mismos cambios y parches de Mac OS X 10.6.7 citados con anterioridad – los que aplican, evidentemente – pero adaptados a la versión de Leopard. Tienes más información en la siguiente URL: Security Update 2011-1

Figura 3: Security Update 2011-1 para Mac OS X Leopard Server & Client

martes, 22 de marzo de 2011

Hackers contra Apple: Charlie Miller y Dino Dai Zovi (2 de 4)

=======================================================================
=======================================================================

Actualizaciones de Safari y WebKit

Mac & I: ¿Y qué pasa con el motor de procesamiento de WebKit, lo mantienen actualizado en Safari?

Charlie Miller: Creo que lo están haciendo bien en este sentido. Considera los problemas de tener un navegador basado en WebKit. Otros proyectos, como pueden ser los de Google Chrome y Android también lo están utilizando.

Así que, cuando se informa de un error a los desarrolladores de WebKit, en un entorno ideal, todos los proyectos de código abierto que lo utilizan, como son Google Chrome, Android, Apple Safari o Mobile Safari, deberían de aplicar los parches el mismo día de forma coordinada.


Por supuesto, esto nunca sucede. Por ejemplo, cuando un error de WebKit se parchea en OS X, probablemente el error continúe en Safari Mobile hasta la siguiente actualización del iPhone o viceversa. Si no se parchean OS X y iPhone al unísono, cosa que no se hace, al igual que con otros proyectos de código abierto, normalmente siempre habrá errores conocidos en los navegadores.

Charlie Miller y iPhone. Su exploit con SMSs dio la vuelta al mundo

Dino Dai Zovi: Es una situación similar a las distribuciones de Linux y el kernel "vanilla" de Linux. Todo el desarrollo se produce en el proyecto de código abierto (incluyendo las revisiones de seguridad), mientras que los proyectos comerciales extraen de ellos el código según sea apropiado para sus calendarios de lanzamiento. Los proyectos comerciales están más preocupados por el soporte y la estabilidad del producto, por lo que no pueden tener el nivel de renovación de código que tienen los proyectos de código abierto.

Mac & I: …pero aún así, ¿esta dependencia en el proyecto WebKit da a los atacantes algunos días o incluso semanas para explotar vulnerabilidades potencialmente críticas en Safari, no es cierto?

Charlie Miller: La utilización de WebKit no es malo en sí. Apple sólo necesita liberar los parches a medida que estén disponibles en el repositorio de código abierto. Hasta ahora, no han podido hacerlo sistemáticamente, o al menos no les ha preocupado el hacerlo.

Dino Dai Zovi: Eso es cierto. El proyecto WebKit intenta mantener las revisiones de seguridad en secreto hasta que se lanzan, pero inevitablemente Chrome, Safari, iOS y quien utilice WebKit no tendrá una programación de seguridad sincronizada. Chrome tiende a llevar la batuta, por lo que Safari y iOS inevitablemente van siempre por detrás.

Desde el principio, en Chrome se desarrolló la capacidad de actualizarse de forma frecuente y transparente en el propio navegador, por lo que se pueden lanzar nuevas versiones muy fácilmente. Probablemente es más difícil el hacer una actualización de Safari y aún más el sacar una actualización iOS. En software y en ingeniería de redes, es recomendable siempre crear de una forma u otra un mecanismo que facilite las actualizaciones frecuentes desde el principio.

Mac & I: Apple lanzó su Mac App Store en enero. ¿Crees que esto impulsará la seguridad? Los desarrolladores tendrán que firmar sus aplicaciones, supongo.

Charlie Miller: Bien, puede ofrecer cierta protección de malware para los usuarios finales. Esto no es realmente un problema, pero podría convertirse en uno. Tener una ubicación central para todas las aplicaciones, las cuales de alguna manera son controladas por Apple hace que sea más difícil para los autores de malware el desplegar su código si los usuarios empiezan a usar sólo la Mac App Store para sus descargas.

Dino Dai Zovi
Dino Dai Zovi:: Hasta ahora, las amenazas de malware más grandes para los usuarios de Mac han sido a través de los caballos de Troya que vienen en software descargado (normalmente pirata) o desde sitios web que engañan a los usuarios para que se instalen codecs de vídeo malintencionados. La mejora de la autenticidad del software de terceros en el Mac y el hacer más fácil la descarga de software auténtico tendrá un beneficio en la seguridad. También, como la firma de código utilizado por iOS también existe en Mac OS X, el disponer de software de terceros firmado puede hacer que Apple finalmente fuerce el uso de código firmado también en Mac OS X. La firma de código en las aplicaciones es la tecnología más efectiva de defensa de seguridad en iOS.

Mac & I: La versión OS X 10.7, Lion, resolverá algunas de las deficiencias de Snow Leopard como los de ASLR y DEP que has mencionado? ¿Habrá otras mejoras de seguridad?

Charlie Miller: Esa es la pregunta del millón de dólares y solo Apple sabe la respuesta. Tendremos que esperar como todo el mundo para ver qué sucede. ¡Eso espero!

Dino Dai Zovi: Dado que Apple tiene un acuerdo NDA muy estricto en sus sistemas operativos preliminares, prefiero mantenerme alejado de ellos para no meter la pata y filtrar lo que se dé una futura característica.

Mi carta de deseos de seguridad para Lion sería que hubiera un ASLR real y una política de firma de código similar a la que tiene iOS.


(Nota: Desde que se hizo esta entrevista, Apple ha invitado a Charlie Miller y Dino Dai Zovi a examinar la seguridad de Mac OS X 10.7 Lion)

=======================================================================
=======================================================================

lunes, 21 de marzo de 2011

Apple Safari 5.0.4 vulnerable a engaños de doble extensión

En el blog de Un informático en el lado del mal se ha publicado una curiosa característica de Apple Safari 5.0.4 que puede ayudar a los atacantes a engañar a un usuario para logra la ejecución del malware en el sistema mediante técnicas de ingeniería social. El problema se produce cuando una aplicación web entrega un nombre de fichero demasiado grande para ser mostrado en el cuadro de diálogo

Figura 1: Doble extensión en Chrome
Ante esa situación, todos los navegadores modernos en sus últimas versiones, tienen especial cuidado en mostrar la extensión del fichero descargado, acortando el nombre del fichero que se muestra al usuario, tal y como se puede ver en este ejemplo con una descarga en Google Chrome en el que el archivo simula ser un vídeo, y es un ejecutable.

Sin embargo, Apple Safari 5.0.4 no tiene esta precaución, y corta el nombre del fichero, dejando la extensión del mismo fuera de la vista de la víctima. Una web maliciosa podría enviar un fichero con un nombre especialmente preparado para sacar partido de este fallo, haciendo simular al usuario que se está descargando un vídeo, cuando realmente es un troyano. Para eso, basta con que tenga una longitud específica y utilice un truco de doble extensión, tal y como se puede ver en la siguiente captura de la respuesta del servidor.

Figura 2: Nombre largo con doble extensión, simulando ser un vídeo

El usuario de Apple Safari 5.0.4 solo verá una parte del nombre y podrá ser engañado al parecer que la extensión es AVI. Safari solamente muestra unos pequeños puntos suspensivos indicando que el nombre es más largo, pero es fácil que el usuario sea engañado.

Figura 3: Cuadro de dialogo que verá el usuario en Apple Safari 5.0.4

Contramedidas

Aunque el estar informado de esta situación es una de las mejores contramedidas, no obstante, antes de descargar ficheros de Internet, se recomienda tomar especial cuidado del nombre y la extensión del archivo, evitar la ejecución inmediata desde el navegador y pasar el fichero por una solución antimalware. Para ello, es mejor descargar el fichero en el disco, después analizar las propiedades, donde ya se podría ver claramente el engaño, y por último pasarlo por una solución antimalware o directamente por Virus Total.

domingo, 20 de marzo de 2011

Hackers contra Apple: Charlie Miller y Dino Dai Zovi (1 de 4)

=======================================================================

La revista Mac & I (Mac y yo) recientemente ha entrevistado a Charlie Miller y Dino Dai Zovi, los cuales son coautores del libro “Mac Hacker’s Handbook”  - El manual del hacker de Mac - que trata de la seguridad en sistemas operativos Apple y como comprometerla y ha sido publicada en original - inglés - en el medio The H Online, bajo el título de Hackers Contra Apple.

Ambos son muy conocidos por sus exploits contra software de entornos Apple Mac. Charlie Miller es un investigador que actualmente trabaja para la consultora de seguridad “Independent Security Evaluators”. Previamente había trabajado para la NSA (National Security Agency) y ha ganado premios por sus exploits en los concursos Pwn2Own.

Dai Zovi también es un habitual de Pwn2Own, siendo el primero en hackear un MacBook Pro mediante una vulnerabilidad de QuickTime en CanSecWest 2007. Le han clasificado en la revista eWeek como una de las 15 personas más influyentes en materia de seguridad. Actualmente trabaja como consultor independiente, autor de libros y conferenciante.

La entrevista es de una calidad altísima y en ella ambos desgranan los pormenores de la seguridad en los principales productos de Apple Vamos a publicarla en cuatro partes, segmentando los principales puntos de ella.

Mac & I: Si hubiera algo como el “hacker estrella de Mac”, el titulo probablemente sería tuyo. ¿Por qué estas todavía hackeando sistemas?

Charlie Miller: Hay un par de razones. Una es, como has mencionado antes, utilizo una variedad de productos Apple y estoy muy interesado en verlos lo más seguros posible. La otra razón es hacer que los usuarios de Mac conozcan los verdaderos riesgos. Si solo escuchas a Apple (o fans de Mac), creerás que los Macs son imposibles de hackear, y no es el caso. Si le cuento a la gente los riesgos de una forma real y directa, espero que tomen decisiones informadas acerca de cómo utilizan sus dispositivos Apple.

Dino Dai Zovi: Comencé a utilizar Macs por la misma razón que comencé a hackearlos, pienso que son una tecnología muy interesante. Me gusta coger una pieza de software y ver cómo funciona y/o falla, así que desde que tengo un Mac conmigo paso habitualmente mi tiempo libre leyendo código fuente de Mac OS X o binarios para ver cómo está implementado algo. También me gusta conocer de primera mano el nivel de seguridad que ofrece un software que yo utilizo y a menudo intento pasar algún tiempo “tirando del hilo”.

Mac & I: En la página de seguridad de OS X, Apple mantiene que “OS X nos tiene protegidos”. Cuando comparas eso a Windows 7, ¿qué tan seguro es OS X con Snow Leopard? ¿Cuáles son las principales diferencias de seguridad entre ambos Sistemas Operativos?

Dino Dai Zovi: Comparar el nivel de seguridad de ambos sistemas es difícil y solo es una parte de la foto. Se necesita conocer de quien te estas defendiendo, y cuáles son los vectores de ataque. Para la mayoría de los lectores de esta revista, su principal preocupación debería ser defenderse del malware mientras navegan por Internet. Actualmente, un Mac con Snow Leopard es la opción más segura, principalmente debido a que su mercado es mucho menor que el de Windows 7. Desde un punto de vista de ataque focalizado, sin embargo, mi experiencia es que encontrar y explotar vulnerabilidades en Mac OS X es significativamente más fácil que en sistemas operativos modernos (Vista y Windows 7). De todas formas, los complementos de terceros instalados en la mayoría de los navegadores de los usuarios hacen que los ataques incluso a las últimas versiones de Windows sean significativamente más fáciles. Yo recomiendo que los usuarios naveguen con Google Chrome, deshabiliten complementos innecesarios y utilicen la seguridad basada en sitios para los complementos que si necesitan.

Charlie Miller Pwn2own 2009
Charlie Miller: Hay dos problemas fundamentales con la “seguridad”. Una es cuantas vulnerabilidades tiene una plataforma. La otra es que tan difícil es que esas vulnerabilidades se conviertan en exploits. Es difícil medir cuantos errores tienen el sistema operativo y sus aplicaciones predeterminadas. Sin embargo, la experiencia me muestra que OS X probablemente tiene más errores que un navegador de Windows. Cada vulnerabilidad de QuickTime es accesible mediante el navegador, ¡y hay muchas!

Desde el punto de vista de la dificultad de explotación, Mac OS X también es más débil que Windows 7. El estándar de industria para parar los exploits es ASLR (Address Space Layout Randomization) y DEP (Data Execution Prevention). Aunque son términos altamente técnicos, el hecho es que Windows, desde Vista hace un uso completo de ASRL y DEP, mientras que OS X solo hace aleatorias algunas porciones de la memoria, por lo tanto no tiene un soporte completo de ASLR y su implementación DEP está limitado solo a procesos de 64 bits como Safari, pero no afecta a procesos de 32 bits como Flash.

Snow Leopard, ASLR y DEP

Mac & I: …y teníamos muchas esperanzas en que la versión 10.6 mejorara en ASRL, pero de alguna forma parece que se han olvidado el enlazador dinámico (Dynamic Linker). En la versión 10.5 el bit de ejecución (Execute Disable Bit) para la pila, de la cual depende DEP en procesadores Intel, se podía incluso deshabilitar por un programador avispado con una llamada a mprotect. ¿Apple ha cambiado al menos esto en Snow Leopard? ¿Se pueden considerar el montículo y la pila seguros en este sentido?

Charlie Miller: El ASLR en la versión 10.5 es idéntico al de la versión 10.6, no se han hecho mejoras. Hay todavía muchas cosas que no se hacen de forma aleatoria, como la localización del enlazador dinámico (dynamic linker), la página de comunicación (comm page) y el ejecutable como tal, también la pila y el montículo. En Snow Leopard se ha añadido DEP para el montículo (para procesos de 64 bits), lo cual es una gran mejora. De todas formas, como los complementos de QuickTime y Flash para el navegador y los que son anteriores a 2007 no soportan procesos de 64 bits, entonces DEP no existe en ninguno de estos procesos. Compara esto con Windows donde tienen soporte completo de ASLR (todo es aleatorio) y DEP.

Dino Dai Zovi: En casi todos los sistemas con memoria no ejecutable, las llamadas del sistema para hacer páginas de memoria ejecutables (mprotect, vm_protect, VirtualProtect, etc), están todavía permitidas. Los parches grsec para Linux pueden deshabilitar este comportamiento mientras tanto en iOS se previene mediante la obligación de firma de código. La desventaja de ASLR es que hace más fácil que los atacantes puedan buscar bits de código que puedan reutilizar para efectuar llamadas al sistema que hagan que la memoria que contiene su shellcode sea ejecutable (si no lo es ya).

Mac & I: Hablando de soporte de 64 bits, Apple dice que, aparte de DEP, la tecnología de 64 Bits ofrece funciones más seguras en los métodos de paso de argumentos y “verificaciones fortificadas para los montículos del sistema”. ¿Son estas tecnologías de Apple, o sólo los beneficios extras de utilizar procesadores Intel actuales o versiones de compilador?

Charlie Miller: La arquitectura de 64 bits hace que ciertos tipos de ataques que hacen uso de la programación orientada a retorno (return oriented programming), que se salta DEP, sean más difíciles. Pero, por ejemplo, justo ayer di una charla en una conferencia en Corea que muestra exactamente cómo hacer programación orientada a retorno en procesos de 64 bits ya que se conoce la localización del enlazador dinámico (dynamic linker). En cuanto a las comprobaciones de suma del montículo, se ha mejorado mucho también, así que es bueno y añade otra barrera más, aunque pequeña, a los ataques.

Dino Dai Zovi: El hecho de que el código de 64 bits pase los argumentos en registros en vez de la pila, simplemente hace que la programación orientada a retorno (ROP) requiera más trabajo, como Charlie ha demostrado recientemente. El código de PowerPC también pasa los argumentos mediante registros y un ataque viable requiere técnicas ROP para resolver los problemas de coherencia de caché, pero esto no ha sido un impedimento para atacar sistemas Mac OS X antiguos. Las comprobaciones de suma de los montículos efectivamente mitigan el riesgo de ataque mediante bloques de metadatos corruptos, sin embargo los datos específicos de aplicación (como vtables de C++) son un objetivo mucho más popular estos días y las comprobaciones de suma no hacen nada para prevenir el ataque.

Mac & I: Ya veo. – Buenas repuestas, por cierto. Hablemos de otra técnica de mitigación. Apple ha dotado a Safari con protección de canary bits. ¿No sería interesante compilar todas las aplicaciones con protección de pila con canary bits? Vimos rápidamente que la aplicación iPhoto parece una de esas aplicaciones que todavía no utiliza esta característica de compilación.

Dino Dai Zovi: Hacer uso de las nuevas protecciones basadas en compilador a menudo requiere la migración de un proyecto de desarrollo completo a una nueva versión de compilador. Es común que grandes y antiguos proyectos continúen haciendo uso de compiladores antiguos, ya que migrar a una nueva versión puede requerir cambios significativos en el código fuente (por ejemplo, interfaces STL de C++). Mientras que la mayor parte de Snow Leopard está compilado haciendo uso de stack canaries, es muy probable que existan aplicaciones de terceros que estén compiladas con antiguos compiladores. Parece que iLife puede ser una de ellas.

Charlie Miller: Creo que las aplicaciones con riesgos de seguridad significativos se compilan de esta forma. No hay tanto riesgo en que iPhoto pueda analizar una imagen maliciosa como en que lo haga Safari o Mail.

=======================================================================
Artículos relacionados

Otras historias relacionadas

Entradas populares