Al fin conocemos más detalles sobre Stagefright, esa vulnerabilidad de la que los chicos de Zimperium habían alertado la semana pasada, en espera de ser presentada públicamente en la DefCon de estos días.
El quid de la cuestión radica en el sistema de memoria que maneja Android. Puesto que hablamos de un sistema crítico (si controlas la memoria, puedes cambiar rutinas para ejecutar uno u otro proceso), en su día se decidió implantar un control de aleatoriedad con permisos muy restrictivos llamado ASLR (EN).
Address Space Layout Randomization es una suerte de caos controlado, en el que el mapa de memoria luce totalmente desordenado, y solo los elementos críticos del sistema pueden conocer cuál es la siguiente línea a ejecutar.
Gracias a Stagefright, es posible acceder al mapa de memoria con los permisos suficientes como para conocer su orden y poder entonces modificarlo. Un problema que podría pasar de anecdótico si no fuera por la ideosincrasia del sistema de distribución de Android.
De hecho, me adelantaba al definir Stagefright como el ejemplo perfecto de la mayor debilidad que tiene Android en la actualidad, y que no se trata de esa ruptura del sandbox, o del escalado de privilegios que permitía mediante este ataque llegar incluso a controlar todo el dispositivo, sino algo mucho más complejo de solucionar: la dependencia absoluta de terceros.
La fragmentación es el telón de Aquiles de Android… y también de Windows
Que un año después de la salida de Android 5.0, tan solo el 20% de los usuarios estén disfrutando de esta versión, dice mucho. Pero dice más que KitKat siga presente en el 40% de terminales, y que Jelly Bean acapare aún el 35%.
Si nos vamos a entornos Windows, llama la atención que al menos hasta el mes pasado (me faltan datos de la implantación de Windows 10 en la semana que lleva disponible) Windows XP, con más de 12 años de vida, estuviera aún por delante de Windows 8, y que hubiera más Windows 7 en el mercado que las últimas versiones.
Y es paradójico porque hablamos de dos modelos diametralmente opuestos. Mientras Android se basa en un modelo de distribución abierta (quien hace llegar las actualizaciones al terminal, salvando casos específicos como en el Nexus, no es Google, sino nuestro fabricante y/o operador), Windows mantiene un modelo cerrado mediante pago por licencia (hasta ahora) en el que son ellos los que lo liberan.
Bien es verdad que con el paso a un WaaS (Windows as a Service) es de esperar que esa fragmentación disminuya considerablemente y mantenga cánones semejantes a los que podemos observar en OS X y iOS. El que la liberación de una actualización tenga que pasar por varias manos (Android) o fuera de pago (Windows) ha demostrado ser un lastre que conlleva problemas de fragmentación en el futuro. Y aunque en su momento se presentaba como una alternativa aceptable, estamos llegando a ese punto de inflexión en el que se hace necesario un cambio de paradigma.
El mercado responde: cambios de ciclo de desarrollo y rolling release
Si de algo ha servido Stagefright es para poner en la mesa los riesgos de que en pleno 2015, dos de los sistemas operativos más presentes en el mundo sigan siendo tan vulnerables a exploits de día 0. Esto en un problema que no solo afecta a PCs, tablets y portátiles, sino con aún mayor intensidad en el Internet de las Cosas.
Ya sabemos que la industria aprende a base de hostias, y en este caso, parece que el surgimiento de esta vulnerabilidad ha sido el detonante necesario para que tanto Google como Samsung se comprometan a cambiar la situación en Android:
- El primero (EN), mediante el compromiso de liberar mensualmente actualizaciones para su gama Nexus, al menos durante los tres primeros años.
- El segundo (EN), mediante la revisión de su política de actualizaciones, que parece que recibirá un lavado de cara, y previsiblemente hará llegar a sus clientes actualizaciones críticas cuando tienen que llegar, y no cuando el roadmap lo marque.
Y estas decisiones van de la mano de la política que ya manejan algunos fabricantes como Xiaomi, que libera continuamente actualizaciones para sus dispositivos, o incluso de forks de Android como Cyanogen, auténtica referencia para usuarios que desean estar al día en cuanto a parches.
Si nos vamos a entornos Windows, el paso a un Windows como servicio conlleva dos cambios sustanciales:
- Por un lado, se rompe la barrera del pago por actualización; Cualquiera con un Windows 7, 8 o 8.1 licenciado recibirá gratuitamente Windows 10.
- Y por otro, se especula, a raíz de las declaraciones de Jerry Nixon en la conferencia Ingnite, y secundado más tarde por Microsoft en The Verge (EN), que Windows 10 pasaría a ser un sistema con un ciclo de actualizaciones modular, quizás cercano al paradigma de las rolling release.
¿Qué quiere decir esto? Hasta ahora, la mayoría de sistemas operativos se basan en un ciclo de actualizaciones regulares. Cada X tiempo (años, meses,..) se libera una nueva actualización, que conlleva unos cambios sustanciales en todos o la mayoría de los aspectos del sistema (nuevas funcionalidades, nueva interfaz, nueva interacción, nuevos programas,…).
Tiene dos ventajas principales:
- Minimiza el impacto global de las actualizaciones a cambio de mayor criticidad: Cualquier actualización, por pequeña que sea, conlleva una ruptura de la estabilidad esperable en el sistema. Y aplazando todas a un mismo punto, hace que en el resto del ciclo de vida, al no haber cambios sustanciales, no haya riesgo a nuevos problemas. Eso sí, en el momento de actualizar a la nueva versión, los problemas pueden ser críticos, al cambiar esta actualización la mayoría de elementos que lo componen.
- Sirve como gancho marketiniando para crear expectación (e interés): Los meses anteriores a una nueva versión del sistema son oportunidades para renovar el interés de los clientes (y potenciales clientes) en nuestro producto. Ocurre de hecho también en el mercado de la ciberdelincuencia, con el branding de vulnerabilidades. Resulta más atractivo saber que a partir de X día tendremos X nuevas features (o que estamos expuestos a X vulnerabilidad), a que todo esto se pierda en una maraña de noticias diseminadas a lo largo del tiempo.
Frente a este modelo surge el de la liberación continua o rolling release, presente en algunos sistemas operativos como Arch Linux, y en el que no existe una actualización marcada en el timing de actualizaciones, sino que estas se suceden continuamente. Para ello, el sistema se subdivide en varios módulos, que son los que en verdad se actualizan siguiendo un roadmap clásico. Pero el usuario final tiene la impresión de estar continuamente recibiendo actualizaciones.
Gracias ello:
- El sistema es más seguro: Sin tener que esperar a una fecha específica para actualizar todo el sistema, un ciclo de desarrollo rolling release actualiza el módulo específico tan pronto se desarrolla el parche necesario para protegerse de la vulnerabilidad, lo que hace que a efectos prácticos estés ante un sistema más fiable.
- Siempre tendrás la última versión: Tan pronto un componente ha sido suficientemente testado, se lanza a producción, por lo que siempre tienes la última versión de todo. A cambio, eso sí, de mayor inestabilidad (actualizaciones recurrentes = posibles incompatibilidades o problemas), y por otro lado, menor riesgo de daño crítico (al ser actualizaciones pequeñas, el riesgo de un problema crítico se minimiza).
La cuestión es que un ciclo de liberación continua arroja a priori un escenario más adecuado para el momento que estamos viviendo. Con toda esta industria del cibercrimen uno o dos pasos por delante, el mantener el sistema actualizado siempre a lo último pasa de recomendable a obligatorio.
[Tweet «.@PYDotCom: ‘El mantener el sistema actualizado siempre pasa de recomendable a obligatorio'»]
Ahora claro, a ver quien es el guapo que da el paso, perdiendo por el camino la capacidad de lanzar una campaña de marketing con cada nueva versión y atraer con ello a más clientes (o recuperar el entusiasmo de los que ya lo son). Un marketing que quizás entonces ya no sea estacional sino también líquido.
No se puede tener todo en este mundo, y esperemos que al final (como parece que está ocurriendo) se anteponga la necesidad al negocio. Al negocio de toda la vida. Ese que ha estado funcionado las últimas décadas, y cuyo kernel se tambalea.
Uhm.
Existen costumbres que son difíciles de quitar. Y es difícil quitar el miedo a que deje de funcionar.
Usuarios Windows: suelen quitar las actualizaciones automáticas o no hacen caso, por miedo a quedarse sin la versión pirata de…o les vaya más lento el ordenador. Por ejemplo, por la red comentan que prefieren el w7 al w10 y eso sin probarla. No actualizarán y eso no se entiende.
Y esa costumbre hace que si tienen Android y ven actualizaciones, no las hagan tampoco por costumbre. Y de esos he visto a muchos a mi alrededor que no quieren actualizar, porque tienen miedo.
Aparte que la red está llena de preguntas como: ayuda, después de actualizar X sistema operativo, tengo un problema…; que genera una tremenda desconfianza.
En gnu/linux ya está más habituado el usuario y se deja actualizar, aunque se le presenten problemas, lo asume y sabe que se arregla rápido.
Saludos
Tienes toda la razón. Es como todo, que siempre hay talibanes que creen que la informática de estos años es igual a lo que había hace 15.
En fin, afortunadamente vamos a mejor. Ya no tienes que ser técnico para actualizar un sistema, lo cual es un alivio. Por mucho que me guste solucionar problemas, prefiero mil veces que las cosas funcionen.
Y las cosas ahora funcionan cuando están actualizadas, no al contrario :).
+10000
A modo anecdótico actualize a Windows 10 y mi laptop fue un desastre. Fallos y mas fallos. Así que cree otra partición con windows 7 y es la que uso.
Pero en Android jamas he tenido problemas con una actualización. Sin embargo Windows ha metido el miedo a las actualizaciones a muchos usuarios.
Es una pena, la verdad. Entiendo que debe ser un verdadero quebradero de cabeza hacer algo que debe ser compatible con distribuciones de hardware de lo más variopintas, pero oye, que es su negocio…
Hombre tampoco los llamaría talibanes, cuando todavía es un proceso crítico del sistema y existen fallos tan grandes en la actualidad.
Todavía se tiene en mente los graves problemas sufridos por los usuarios de Apple con sus actualización reciente del sistema. Y la de Android con la actualización de versión que por ejemplo, mi sobrina con su samsung le dio problemas hasta llevarlo a una tienda física de la marca para que se lo corrigiesen (suerte que tenemos una cerca y se lo corrigieron al momento).
Y eso es duro para el usuario y genera mucha desconfianza con las actualizaciones. Porque te gastas 600 euros en un producto tecnológico y en un día deja de funcionar.
Por no decir del caso de Panda, que con una actualización generó problemas de pérdida de datos.
El usuario tiene malas costumbres, pero tampoco nadie les da una garantía de ser un proceso seguro. Y se avanza muy rápido en algunas cosas, pero en lo importante…saludos
Ya, quizás me he pasado jajaj.
Escribía mientras tenía en mente la típica persona que, 12 años después, tiene Windows XP porque es lo mejor que hay.
Una cosa muy distinta es correr el primer día como he hecho yo a instalarlo en producción. Y si hablamos de una empresa ya es que es para matarles.
Pero hombre… Pasan unas semanas, liberan los parches oportunos… Digo yo que no habrá que esperar unos meses o años a que la cosa cuaje, jajajaj.
Es más, al final precisamente son esas decisiones las que acaban afectando negativamente. Porque un sistema no actualizado es un sistema vulnerable. Tan sencillo como eso. Hay más riesgo no actualizando que actualizando a lo último.
Si, esperar un tiempo pueda llegar a dar más confianza. Pero fíjate en el término rolling release que tratas en la publicación, y ese método tiene incluso muchas interrogantes con servidores productivos.
Por eso, creo que se debe mejorar bastante en las actualizaciones y posiblemente el método que se desarrolla a base de contenedores puede ser un nuevo princio, aplicable a los sistemas operativos. Saludos
Saludos,
ni una cosa ni otra, en entornos de producción, al menos en los bien administrados no se parchea directamente. Antes de tocar nada se testean las cosas para descartar posibles problemas de compatibilidad y la virtualización como dice javi ayuda mucho ya que aunque se produzca el error fatal se puede poner a funcionar una version estable sin parchear en segundos.
El tema del usuario casero es un mundo aparte, somos animales de costumbres y para el que no depende de tiempos es mucho más facil usar lo que conoce que no adaptarse a algo nuevo mucho mejor pero que requiere aprender a manejarse.