software modular


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.