Hace varias semanas, la comunidad de Linux se vio sacudida por la inquietante noticia de que los investigadores de la Universidad de Minnesota habían desarrollado (pero, de hecho, no completamente ejecutado) un método para introducir lo que llamaron “compromisos hipócritas” en el kernel de Linux: la idea siendo distribuir comportamientos que son 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 la noticia, en algunos sentidos igualmente inquietante, de que se había prohibido a la universidad, al menos temporalmente, contribuir al desarrollo del núcleo. Siguió una disculpa pública de los investigadores.

Si bien 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 parece un poco más complicado. Es difícil imaginar a investigadores e instituciones tan ingenuos o abandonados que no comprendan el radio de explosión potencialmente enorme de tal comportamiento.

Igualmente seguro, los mantenedores y la dirección del proyecto tienen el deber de aplicar la política y evitar perder el tiempo. El sentido común sugiere (y los usuarios lo exigen) que se esfuerzan por producir versiones del kernel que no contengan exploits. Pero matar al mensajero parece perder al menos parte del punto: que fue investigación más que pura malicia, y que destaca algún tipo de vulnerabilidad de software (y organizacional) que requiere mitigación técnica y sistémica.

Los proyectos de la escala y la extrema criticidad del kernel de Linux no están preparados para los modelos de amenazas de hiperescala que cambian el juego.

Creo que el contratiempo que comete el hipócrita es sintomático, por todos lados, de tendencias relacionadas que amenazan a todo el ecosistema extendido de código abierto y a sus usuarios. Este 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 cualquier tipo de empresa humana. Veamos este complejo de problemas:

  • Los proyectos de código abierto más grandes ahora tienen grandes objetivos.
  • Su complejidad y ritmo han superado la escala a la que pueden hacer frente los enfoques tradicionales de “bienes comunes” o incluso modelos de gobernanza más evolucionados.
  • Evolucionan para regatear entre sí. Por ejemplo, es cada vez más difícil decir categóricamente si “Linux” o “Kubernetes” deben tratarse como el “sistema operativo” para las aplicaciones distribuidas. Las organizaciones con fines de lucro tomaron nota y comenzaron a reorganizarse en torno a carteras y narrativas “completas”.
  • Al hacerlo, algunas organizaciones con fines de lucro comenzaron a distorsionar los modelos tradicionales de participación en software libre y de código abierto. Se están realizando muchos experimentos. Mientras tanto, la financiación, los compromisos del personal con el software libre y otras medidas parecen estar disminuyendo.
  • Los proyectos y ecosistemas de OSS se adaptan de diversas formas, lo que a veces dificulta que las organizaciones con fines de lucro se sientan como en casa o se beneficien de la participación.
LEER  UK fintech 10x recauda $ 187 millones para construir nuevos servicios para bancos heredados - TechCrunch

Mientras tanto, el panorama de amenazas continúa evolucionando:

  • Los atacantes son más grandes, más inteligentes, más rápidos y más pacientes, lo que resulta en juegos largos, subversión de la cadena de suministro y más.
  • 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 creciente de nubes públicas está creando nuevas capas de monocultivos técnicos y organizacionales que pueden permitir y justificar ataques.
  • Las soluciones comerciales complejas 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 actores equivocados.
  • El componente de 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 su experiencia no básica, cambiar el gasto de capital a gastos operativos y escalar para depender de los proveedores de nube y otras entidades para realizar el arduo trabajo de la seguridad.
LEER  Los criptoinversores aman tanto Terraform Labs que están comprometiendo $ 150 millones para su "ecosistema" - TechCrunch

El resultado neto es que la escala y la extrema criticidad de los proyectos del kernel de Linux no están listas para los modelos de amenazas de hiperescala que cambian el juego. En el caso específico que estamos viendo aquí, los investigadores pudieron apuntar a sitios de incursión candidatos con relativamente poco esfuerzo (utilizando herramientas de análisis estático para evaluar unidades de código que ya se identificaron como que necesitaban la atención de los colaboradores), ofrecer “arreglos” de manera informal por correo electrónico 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 la validación.

Esto fue una traición seria, de hecho por parte de los “internos” de un sistema confiable que históricamente ha funcionado muy bien en la producción de versiones de kernel robustas y seguras. El abuso de la confianza en sí mismo cambia las reglas del juego, y el requisito de seguimiento implícito – generar confianza humana mutua con medidas de mitigación sistemáticas – cobra gran importancia.

LEER  Google Cloud se asocia con Starlink de SpaceX para la conectividad empresarial en el borde de la red - TechCrunch

Pero, ¿cómo lidiar con tales amenazas? De hecho, la verificación formal es imposible en la mayoría de los casos. El análisis estático puede no revelar incursiones inteligentemente diseñadas. Los ritmos del proyecto deben mantenerse (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 debe protegerse de todo, el equipo rojo solo necesita triunfar una vez.

Veo algunas posibilidades de remediación:

  • Limita la propagación de los monocultivos. Cosas como Alva Linux y la distribución abierta 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, organización y financiación del proyecto con el fin de paliar la dependencia total del factor humano, así como animar a las empresas con ánimo de lucro a aportar 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, no a pesar de ello, pero en muchas comunidades puede requerir un cambio de cultura para los contribuyentes existentes.
  • Acelere la comercialización simplificando la pila y verificando componentes. Empuje la responsabilidad correspondiente de 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 avanzar lo más rápido posible hacia la formalización del uso de cosas como unikernels.

De cualquier manera, debemos asegurarnos de que las empresas y las personas proporcionen los recursos que el código abierto necesita para seguir funcionando.

¡Haz clic para puntuar esta entrada!
(Votos: Promedio: )