El incidente en que CrowdStrike también dañó Debian y Rocky Linux hace meses

• Aparte de la gran falla de BSOD en Windows, ya había habido casos en los que una actualización de CrowdStrike provocó caídas de servidores en entornos Debian y Rocky Linux
• En abril, en un civic tech lab, todos los servidores Debian Linux se bloquearon al mismo tiempo justo después de la actualización y se negaron a arrancar; solo fue posible recuperarlos tras quitar CrowdStrike
• Esa configuración de Debian se consideraba compatible, pero no era compatible con la versión estable más reciente de Debian, y en el análisis de causa raíz se confirmó una omisión en la matriz de pruebas
• Usuarios de Rocky Linux también informaron que, tras actualizar a RockyLinux 9.4, los servidores con CrowdStrike se bloqueaban por un bug del kernel, y el equipo de soporte de CrowdStrike también reconoció el problema
• Las organizaciones que dependen de CrowdStrike deben manejar con más cautela la aplicación de actualizaciones y contar con un plan de contingencia ante fallas

---

Casos de interrupción en Linux antes de la falla en Windows

• El problema generalizado de Blue Screen of Death en PCs con Windows interrumpió operaciones en varios sectores, como aerolíneas, bancos y proveedores de salud
  • La causa fue un channel file defectuoso que CrowdStrike distribuyó mediante una actualización
  • CrowdStrike confirmó que este bloqueo no afectó a PCs Mac ni Linux
• Sin embargo, usuarios de Debian y Rocky Linux también sufrieron interrupciones importantes por actualizaciones de CrowdStrike, lo que generó preocupación sobre los procedimientos de actualización y pruebas
  • Esto puede representar un riesgo potencial para clientes que dependen a diario de los productos de CrowdStrike

Problemas confirmados en Debian y Rocky Linux

• Bloqueo simultáneo de servidores Debian

  • En abril, en un civic tech lab, una actualización de CrowdStrike hizo que todos los servidores Debian Linux se bloquearan al mismo tiempo y dejaran de arrancar
  • Esa actualización no era compatible con la versión estable más reciente de Debian, aunque se consideraba que esa configuración de Linux era compatible
  • El equipo de TI confirmó que las máquinas arrancaban al eliminar CrowdStrike y reportó el incidente

• Respuesta tardía y falta de pruebas

  • Un integrante del equipo involucrado en el incidente expresó su descontento por la demora en la respuesta de CrowdStrike
  • CrowdStrike reconoció el problema un día después, pero pasaron varias semanas antes de entregar un análisis de causa raíz
  • El análisis mostró que la configuración de Debian Linux no estaba incluida en la matriz de pruebas de CrowdStrike
  • El integrante del equipo criticó: “El modelo de CrowdStrike parece ser empujar software a sus máquinas cuando ellos quieren, sin importar si es urgente o si fue probado”

• Bloqueos tras la actualización a Rocky Linux 9.4

  • Usuarios de Rocky Linux informaron que, después de actualizar a RockyLinux 9.4, los servidores que usaban CrowdStrike se bloqueaban por un bug del kernel
  • El equipo de soporte de CrowdStrike reconoció este problema
  • La repetición de problemas de compatibilidad en distintos sistemas operativos deja ver un patrón de falta de pruebas y de cuidado

Lo que las organizaciones deben preparar

• Para reducir problemas similares en el futuro, CrowdStrike debe priorizar pruebas más estrictas en todas las configuraciones compatibles
• Las organizaciones deben aplicar con cautela las actualizaciones de CrowdStrike y preparar un plan de contingencia para mitigar posibles interrupciones
• Fuentes relacionadas
  • Ycombinator
  • RockyLinux

[click]

Parece que la IA resumió el anuncio en lugar del contenido principal.

[xguru]

El sitio de Neowin tiene una estructura HTML extraña, así que todos los anuncios de la barra superior se reconocen como parte del cuerpo del texto. Ya lo corregí.

[GN⁺]

Opiniones en Hacker News

• Sorprende que el ecosistema OSS/Linux, aunque tiene muchos montones de código pegados gratuitamente por grupos independientes y coordinados de forma laxa, a menudo sea más robusto que el software creado por empresas de miles de millones de dólares.
  Una de las razones podría ser que los programadores de sistemas OSS lavan la ropa sucia en público. No es tanto “con muchos ojos, todos los bugs son superficiales”, sino más bien “si alguien puede verlo, el mal código da vergüenza”.
  Estoy por publicar como open source un proyecto comercial, y antes de abrir el código fuente tengo que hacer bastante limpieza: mejorar documentación, ordenar TODO/FIXME, verificar comentarios, etc. Pero dentro de bases de código comerciales cerradas he visto cosas mucho peores, y sospecho que la mayoría del software enterprise está en un nivel parecido.

  • El software OSS casi no tiene motivación de lucro, así que se escribe más para “hacer que funcione” que para “vender” algo.
    También hay menos presión de tiempo, así que si un lanzamiento se retrasa no afecta los resultados trimestrales. Veo el software comercial más como un trabajo de marketing que como trabajo de ingeniería.
  • Linus no estaría de acuerdo, y hay una razón por la que el kernel siempre mantiene enormes barreras. Él rechazaría con razón la mayor parte del código de espacio de usuario.
    Que lo que está fuera del kernel funcione ya es un milagro, y eso se nota en lo seguido que se rompe con cada actualización de distribución y en lo común que es tener que recompilar todo para que vuelva a funcionar. En producción, actualizar es un procedimiento tremendamente estresante.
    Ni siquiera he mencionado audio y video; si además le sumas Wayland, es una pesadilla aparte. Por eso, en muchos sentidos, veo a Windows como algo cercano al estándar: lo tratan con dureza desde todos lados y aun así realiza tareas importantes todos los días en muchísimas máquinas.
    Que haya compensación económica o no no es lo importante; la profundidad de toma de decisiones que se ve en los textos de Raymond Chen y otros es muy rara incluso en el mundo OSS.
  • Las cosas hechas por dinero, pero con MBAs tomando las decisiones finales, muchas veces son pésimas comparadas con proyectos de hobby o de pasión.
    No creo que esta situación sea solo mía, y espero que siga habiendo comunidades que construyan cosas útiles y herramientas que ellas mismas puedan controlar.
  • Los plazos de entrega probablemente también sean un factor importante. Muchos desarrolladores OSS crean proyectos en su tiempo libre para ellos y para otros, y si es un proyecto de pasión pueden sentir más orgullo por su trabajo.
    El software comercial muchas veces se siente como algo unido con cinta adhesiva para cumplir con la fecha límite de un gerente; termina siendo “qué más da” y basta con haberlo terminado.
  • No creo que llamar amateurs a quienes escriben el código sea una buena descripción. La mayoría probablemente sean personas con mucha experiencia y un perfil muy técnico, y lo de “coordinación laxa” también aplica a muchas empresas.
    En open source, lo importante es que quienes programan suelen hacerlo porque les interesa. Si quieres hacer algo bueno, que funcione bien e ingenioso, tienes más posibilidades de lograrlo que si lo haces simplemente porque te pagan o para evitar pasar vergüenza.

• Comentario relacionado del gran hilo de ayer sobre CrowdStrike: “CrowdStrike le hizo esto a nuestra flota Linux de producción el 19 de abril, y desde entonces tengo ganas de desahogarme” [1]
  Después siguen varios párrafos de desahogo.
  [1] https://news.ycombinator.com/item?id=41005936

  • En el análisis de causa raíz publicado unas semanas después, el escenario que usábamos ni siquiera estaba en la matriz de pruebas. Eso pese a que parecía una configuración soportada ejecutando la versión n-1 en Debian stable.
    Incluso en su propio post mortem no había ninguna forma real de evitar que lo mismo volviera a pasar, porque la estructura era: “metemos software en tus máquinas cuando queramos, sin importar si es urgente o no, y sin pruebas”.
  • No parece ser simplemente un comentario relacionado; este hilo de HN parece haber sido usado como fuente principal del artículo.

• Cuando trabajaba en este campo, siempre me perseguía la duda: “¿estas cosas realmente sirven para algo?”.
  Es una pregunta difícil de responder, pero me pregunto si hay estudios de terceros que hayan verificado la efectividad de productos como CrowdStrike. O si, en realidad, todos están empeorando la vida por teatro de seguridad.

  • Es parecido a intentar estudiar la efectividad de los antivirus. Aun así, en cierto modo ya diste la respuesta: se considera que tienen valor con tal de producir métricas que la dirección pueda digerir.
    Me pregunto cómo tiene sentido agregar algo tan invasivo. En los 90, las empresas de antivirus incluso creaban virus, y mientras propagaban por la red lo que ellas mismas habían creado, a sus suscriptores mágicamente les impedían infectarse.
  • Me pregunto si alguien alguna vez vio que realmente bloquearan algo. La empresa que fabrica esa herramienta obviamente también habría usado su propio producto.
    Si le preguntas a toda la web “¿alguien lo vio?”, seguramente aparecerá alguien, pero hay muchísimas personas que sufrieron vulnerabilidades de seguridad por estas herramientas, y quienes sufrieron problemas de estabilidad y disponibilidad son prácticamente tantas como las personas que las usan.

• La calidad de los productos está en caída libre, desde los aviones hasta el software. Hoy todo el mundo solo se preocupa por generar ingresos adicionales, así que la falta de QA se volvió el valor por defecto

  • Hemos minimaximizado nuestra economía para optimizarla en función de las ganancias, y parece que ahora estamos entrando en la etapa de cosechar eso
    Es la misma razón por la que no podemos fabricar suficientes proyectiles de artillería para enviar a Ucrania, no podemos traer la fabricación de chips al país y no podemos construir barcos
  • Otra causa es que cada vez más personas no técnicas toman decisiones, e incluso desarrollan programas técnicos
    Hace 15 años, la mayoría de la gente de la industria realmente quería estar ahí, con pocas excepciones. Ahora se volvió como cualquier otro trabajo: a la mayoría de los desarrolladores no les importa mucho lo que producen y, al final, el resultado también termina siendo un desastre
    En los últimos años casi no me he encontrado con desarrolladores por debajo de senior que realmente prueben su propio código basura
  • El costo económico de hacer las cosas mal es menor que las ganancias que se obtienen. Hasta que eso cambie, nada va a cambiar
  • Esto no es simplemente un problema de calidad del producto
    Es una estructura en la que influencers con olor a marketing, que ni siquiera saben lo que hacen, venden basura a gente que intenta tapar con casillas de cumplimiento la paranoia provocada por los proveedores. No entienden el modelado de amenazas ni cómo funciona un sistema operativo
    Visto desde la tríada CIA, abandonaron por completo la disponibilidad, sacrificaron parte de la confidencialidad al enviar cada movimiento del sistema a alguna empresa de nube, y buscan obtener una falsa sensación de seguridad llamada integridad que el proveedor ni siquiera garantiza. Casi no he visto pruebas de que este producto realmente haga algo dentro de una arquitectura de seguridad correctamente estratificada
    Esto es lo opuesto a una propuesta de seguridad. Es un castillo de naipes construido sobre mentiras e incompetencia, y literalmente se acerca a la definición de malware. Exfiltra datos que no se pueden controlar, puede tirar sistemas mediante funciones remotas de comando y control, y ejecuta código completamente arbitrario en ring 0
    En marzo de 2023 señalé todo esto como un riesgo empresarial crítico, pero la gente de arriba lo impulsó igual. Dejé grabadas mis objeciones y ahora pienso usarlas para devolverles el golpe
    Si la gente lo compra, deja de importar que esté hecho como basura. Y, de hecho, está hecho como basura
  • Es triste. Hay diferencias entre empresas y, personalmente, es la parte que más me gusta de la ingeniería de software, pero muchas grandes compañías recortan QA en cuanto se les presenta la oportunidad

• También hubo reportes de que CrowdStrike inyectaba una DLL con errores en aplicaciones de Windows, lo que podía hacer que se cayeran aunque la aplicación en sí no tuviera la culpa
  https://x.com/molecularmusing/status/1808756095860543916

  • Eso es un asunto completamente distinto. La DLL que se inyecta es una función opcional desactivada por defecto, y a los administradores se les advierte explícitamente que verifiquen la compatibilidad con su flota antes de desplegarla
    Hay cuatro niveles de hooks aplicables, cada vez más inestables, y la UI y la documentación lo advierten repetidamente. Por ejemplo, XUMD carga una biblioteca en procesos en ejecución y engancha varias API de modo usuario para permitir que el sensor monitoree información
    Parte de la telemetría de endpoints solo puede recopilarse mediante hooks en modo usuario. XUMD proporciona información sobre qué API usa un proceso, y esa información se utiliza en varios mecanismos preventivos del sensor con base en el comportamiento acumulado observado
    A diferencia de AUMD, la nube puede cambiar dinámicamente la visibilidad de XUMD sin actualizar el sensor. Las configuraciones son Disabled, Cautious, Moderate, Aggressive y Extra Aggressive; cuanto más avanzadas, mayores son los problemas de rendimiento o compatibilidad de aplicaciones, por lo que no se recomiendan para producción
    Como XUMD se carga en procesos de usuario con los que no fue desarrollado originalmente, pueden producirse fallas, errores de inicio o degradación del rendimiento, especialmente en entornos donde hay otros productos de seguridad instalados. Para ver qué procesos cargaron la DLL de XUMD, se puede ejecutar tasklist /m csxumd* en la línea de comandos

• Todo esto ocurre porque las empresas pueden eludir por contrato la responsabilidad por daños consecuenciales
  Así como no se permite excluir por contrato la responsabilidad consecuencial por pérdida de vidas, estas cláusulas también deberían volverse inaplicables o al menos limitarse

  • ¿No era eso lo que intentaba hacer la directiva de ciberseguridad europea? Esa por la que todos se enojaron y que luego terminó con una excepción para FOSS

• Las frases “la actualización no era compatible con la versión estable más reciente de Debian, aunque esa configuración de Linux figuraba como soportada” y “el análisis determinó que la configuración de Debian Linux no estaba en la matriz de pruebas” parecen estar bastante cerca de un fraude real
  Es decir, declaran que soportan la configuración X, pero en realidad no la prueban en absoluto. Es como decir que un auto tiene cinturones de seguridad, pero no verificar en ninguna parte del proceso de fabricación que los cinturones estén instalados y funcionen
  Si una automotriz hiciera eso, creo que la procesarían; no entiendo por qué CrowdStrike no. Es comprensible no soportar cierta versión de Linux, pero si la anuncias como soportada y ni siquiera la pruebas, como mínimo es negligencia intencional y quizá fraude descarado

• Decir “nadie se dio cuenta” suena como una forma tierna de decir que CrowdStrike presionó para que la prensa no se diera cuenta. En el hilo de HN del día del bug había comentarios de gente que decía que venía intentando reportar el problema desde hacía meses
  Incluso el artículo está escrito como si la gente sí hubiera notado el problema. Entonces, ¿quién no se dio cuenta? ¿O es que esos problemas no eran lo bastante famosos como para no ser ignorados?

  • ¿Crees que CrowdStrike suprimió la cobertura de prensa? Me da curiosidad si piensas que le mandaron cheques al NY Times, al WaPo y a las principales cadenas
    A la prensa no le importan unos cuantos servidores caídos, salvo que sea algo visible en el mundo real, como la suspensión de vuelos
  • Recuerdo haber visto algo en ese momento, pero pensé que muy poca gente instalaría ese tipo de software en Linux. Y, de hecho, son muy pocas empresas
    El radio de explosión fue pequeño, probablemente incluso menor que el de un mal driver de Nvidia

• Si hay alguien aquí que use CrowdStrike, me da curiosidad saber qué hace exactamente. Veo que lo llaman “antivirus”, pero al verlo instalado en una laptop de trabajo parece más bien un keylogger y monitor de actividad
  Aunque uno diga “no tengo nada que ocultar”, sigue siendo molesto que los superusuarios de la empresa me estén vigilando

  • Permite conseguir el sello de aprobación de los equipos de seguridad, cumplimiento y legales
  • Hay una mejor solución que llamar malware o spyware a las soluciones antivirus/EDR: no usar el dispositivo de trabajo para asuntos personales.
    Ese dispositivo es propiedad de la empresa y se usa para acceder al entorno corporativo, así que es un punto de responsabilidad que puede causar daños si entra malware real. Si necesitas privacidad, lo correcto es usar otro dispositivo

• En algunas empresas dicen que CrowdStrike está desplegado en todos los endpoints, pero alguien comentó que lo ejecutaba solo dentro de una máquina virtual con recursos limitados y nadie decía nada. También dijo que por esa época vio fallar máquinas virtuales.
  Un excolega de otra gran empresa también me contó que IT simplemente dejó de intentar imponer el cumplimiento en endpoints Linux. Parece que algunos administradores de IT aplican, en la práctica, una política de “no preguntes, no digas”.
  Si tú mismo armas un stack alternativo, no haces ruido ni mientes, te dejan hacer. Si la motivación para imponerlo es mayormente cumplimiento de casillas, tiene bastante sentido.
  Me pregunto qué tan extendida está esta especie de cumplimiento malicioso, y cuánto contribuyó a que el incidente de abril no se convirtiera en una noticia más grande