Hace varias semanas, la comunidad de Linux fue sacudida por la noticias inquietantes que los investigadores de la Universidad de Minnesota habían desarrollado (pero resultó que no lo habían ejecutado por completo) un método para introducir lo que llamaron “compromisos hipócritas” en el kernel de Linux: la idea era distribuir comportamientos difíciles de detectar, sin sentido en sí mismos , que luego los atacantes podrían alinear para manifestar vulnerabilidades.
Esto fue seguido rápidamente por el anuncio, en algunos sentidos igualmente perturbador, de que se había prohibido a la universidad, al menos temporalmente, contribuir al desarrollo del kernel. A disculpa pública de los investigadores seguidos.
Aunque el desarrollo y la divulgación de exploits a menudo es complicado, ejecutar programas técnicamente complejos del “equipo rojo” contra el proyecto de código abierto más grande e importante del mundo se siente un poco más. Es difícil imaginar a investigadores e instituciones tan ingenuos o negligentes como para no comprender el radio de explosión potencialmente enorme de tal comportamiento.
Igualmente seguro, los mantenedores y la gobernanza del proyecto tienen el deber de hacer cumplir la política y evitar que se pierda el tiempo. El sentido común sugiere (y los usuarios exigen) que se esfuercen por producir versiones de kernel que no contengan exploits. Pero matar al mensajero parece perder al menos parte del punto: que se trataba de una investigación en lugar de pura malicia, y que arroja luz sobre un tipo de vulnerabilidad de software (y organizativa) que pide una mitigación técnica y sistémica.
Los proyectos de la escala y la absoluta criticidad del kernel de Linux no están preparados para lidiar con modelos de amenazas de hiperescala que cambian el juego.
Creo que los contratiempos de los “compromisos hipócritas” son sintomáticos, por todos lados, de tendencias relacionadas que amenazan a todo el ecosistema de código abierto extendido ya sus usuarios. Ese ecosistema ha luchado durante mucho tiempo con problemas de escala, complejidad y la importancia cada vez más crítica del software libre y de código abierto (FOSS) para todo tipo de empresa humana. Veamos ese complejo de problemas:
- Los mayores proyectos de código abierto ahora presentan grandes objetivos.
- Su complejidad y ritmo han crecido más allá de la escala en la que los enfoques tradicionales de “bienes comunes” o incluso modelos de gobernanza más evolucionados pueden hacer frente.
- Están evolucionando para mercantilizarse mutuamente. Por ejemplo, cada vez es más difícil afirmar categóricamente si “Linux” o “Kubernetes” deben tratarse como el “sistema operativo” para las aplicaciones distribuidas. Las organizaciones con fines de lucro han tomado nota de esto y han comenzado a reorganizarse en torno a carteras y narrativas “completas”.
- Al hacerlo, algunas organizaciones con fines de lucro han comenzado a distorsionar los patrones tradicionales de participación en software libre. Se están realizando muchos experimentos. Mientras tanto, la financiación, los compromisos de personal con FOSS y otras métricas parecen estar en declive.
- Los proyectos y ecosistemas de OSS se están adaptando de diversas maneras, lo que a veces dificulta que las organizaciones con fines de lucro se sientan como en casa o se beneficien de la participación.
Mientras tanto, el panorama de amenazas sigue evolucionando:
- Los atacantes son más grandes, más inteligentes, más rápidos y más pacientes, lo que lleva a juegos largos, subversión de la cadena de suministro, etc.
- Los ataques son más rentables financiera, económica y políticamente que nunca.
- Los usuarios son más vulnerables, expuestos a más vectores que nunca.
- El uso cada vez mayor de nubes públicas crea nuevas capas de monocultivos técnicos y organizativos que pueden permitir y justificar los ataques.
- Las complejas soluciones comerciales listas para usar (COTS) ensambladas en parte o en su totalidad a partir de software de código abierto crean superficies de ataque elaboradas cuyos componentes (e interacciones) son accesibles y bien entendidos por los malos actores.
- La componentización del software permite nuevos tipos de ataques a la cadena de suministro.
- Mientras tanto, todo esto está sucediendo a medida que las organizaciones buscan deshacerse de la experiencia no estratégica, cambiar los gastos de capital a los gastos operativos y evolucionar para depender de los proveedores de la nube y otras entidades para hacer el trabajo duro de la seguridad.
El resultado neto es que los proyectos de la escala y la absoluta criticidad del kernel de Linux no están preparados para lidiar con modelos de amenazas de hiperescala que cambian el juego. En el caso específico que estamos examinando aquí, los investigadores pudieron apuntar a sitios de incursión candidatos con un esfuerzo relativamente bajo (utilizando herramientas de análisis estático para evaluar unidades de código ya identificadas que requieren la atención de los colaboradores), proponer “correcciones” de manera informal por correo electrónico y aprovechar muchos factores, incluida su propia reputación establecida como contribuyentes frecuentes y confiables, para llevar el código de explotación al borde de su compromiso.
Esta fue una traición seria, efectivamente por parte de los “iniciados” de un sistema de confianza que históricamente ha funcionado muy bien para producir lanzamientos de kernel robustos y seguros. El abuso de la confianza en sí mismo cambia el juego, y el requisito de seguimiento implícito, reforzar la confianza humana mutua con mitigaciones sistemáticas, cobra gran importancia.
Pero, ¿cómo lidias con amenazas como esta? La verificación formal es efectivamente imposible en la mayoría de los casos. El análisis estático puede no revelar incursiones ingeniosamente diseñadas. Se deben mantener los ritmos del proyecto (después de todo, hay errores conocidos que corregir). Y la amenaza es asimétrica: como dice la línea clásica, el equipo azul necesita protegerse contra todo, el equipo rojo solo necesita tener éxito una vez.
Veo algunas oportunidades de remediación:
- Limita la propagación de los monocultivos. Cosas como Alva Linux y la Distribución abierta de ElasticSearch de AWS son buenas, en parte porque mantienen libres y de código abierto las soluciones FOSS ampliamente utilizadas, pero también porque inyectan diversidad técnica.
- Reevaluar la gobernanza, la organización y la financiación del proyecto con miras a mitigar la dependencia total del factor humano, así como a incentivar a las empresas con fines de lucro para que contribuyan con su experiencia y otros recursos. La mayoría de las empresas con fines de lucro estarían felices de contribuir al código abierto debido a su apertura, y no a pesar de ello, pero dentro de muchas comunidades, esto puede requerir un cambio de cultura para los contribuyentes existentes.
- Acelere la mercantilización simplificando la pila y verificando los componentes. Empuje la responsabilidad apropiada por la seguridad a las capas de la aplicación.
Básicamente, lo que estoy defendiendo aquí es que los orquestadores como Kubernetes deberían importar menos y Linux debería tener menos impacto. Finalmente, debemos proceder lo más rápido que podamos hacia la formalización del uso de cosas como unikernels.
Independientemente, debemos asegurarnos de que tanto las empresas como las personas proporcionen los recursos que el código abierto necesita para continuar.