Menú principal

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)

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

1 comentario:

  1. En el título pusieron 3 de 4...y la segunda parte de la entrevista ¿? Muy buena por cierto!! ;)

    ResponderEliminar

Entrada destacada

Proteger tu cuenta de Google y de Gmail con Latch Cloud TOTP #Latch #Gmail #Google

La semana pasada se liberó la nueva versión de Latch y nuestro compañero Chema Alonso hizo un repaso de todo ello en su artículo Latch...

Otras historias relacionadas

Entradas populares