El problema del BSOD se debe a una combinación de datos binarios incorrectos y un parser mal escrito
Según la experiencia de los últimos 10 años, la mayoría de los CVE, fallas, bugs y problemas de lentitud ocurren durante el proceso de deserializar datos binarios en estructuras de datos legibles por máquina
Esto aplica a diversos campos, como algoritmos de compresión, lectores de contornos de fuentes, parsers de imágenes/video/audio, parsers de datos de videojuegos, parsers de XML/HTML y parsers de certificados/firmas/claves de OpenSSL, entre otros
El parser de contenido del programa EDR de CrowdStrike no es una excepción
Segundo comentario
Las soluciones de código abierto podrían ser más éticas que el software de monitoreo de endpoints basado en rootkits
Las herramientas de código abierto operan de forma transparente y pueden garantizar que no haya puertas traseras ni bugs graves
Pueden ser auditadas públicamente y podrían operar con un modelo de negocio en el que el equipo de seguridad suministre firmas de malware
Tercer comentario
Microsoft tiene responsabilidad en la caída provocada por CrowdStrike
Microsoft ocupa una posición de monopolio de facto en el espacio de computación de estaciones de trabajo y tiene la obligación de garantizar la seguridad/confiabilidad/funcionalidad de sus productos
Como no hay competencia, la innovación en Windows se está retrasando
Por ejemplo, CrowdStrike se ejecuta en espacio de usuario en macOS y Linux, pero no en Windows
Se necesita innovación en sandboxing de aplicaciones
Microsoft tiene en sus manos las llaves de la infraestructura informática mundial y casi no está supervisado
Aunque la proporción de ingresos de Windows ha disminuido, sigue siendo un producto que opera infraestructura crítica, por lo que se requiere mayor responsabilidad
Los gobiernos deberían fomentar la competencia en el mercado de workspaces de escritorio o regular el producto Windows de Microsoft
Cuarto comentario
No se entiende por qué el alcance del impacto fue tan grande
En los servicios críticos, lo habitual es hacer despliegues lentos con monitoreo automático y funciones de rollback
Lo normal es desplegar primero en beta sin tráfico de clientes y, si no hay problemas, ampliar gradualmente
Este tipo de enfoque habría permitido detener el problema de inmediato
Quinto comentario
No uso CrowdStrike, pero parece que el driver de CS se instala primero y está diseñado para que no se pueda eliminar
El driver carga archivos de datos no firmados, y el usuario puede borrarlos arbitrariamente
Un usuario malicioso podría crear un archivo de datos malicioso y hacer que el driver funcione mal
Existe el riesgo de obtener privilegios de kernel
Sexto comentario
Me pregunto por qué no detectaron el problema en el despliegue de pruebas
Cuesta creer que no hayan hecho pruebas antes del despliegue
Todas las empresas deberían tener un entorno de pruebas antes de desplegar
Es común instalar durante el desarrollo paquetes que fallan o causan problemas, pero no es buena idea desplegarlos directamente en producción
Séptimo comentario
Me pregunto si los clientes de CrowdStrike pueden opinar sobre las actualizaciones
Me cuestiono si todos los clientes le otorgan a CrowdStrike permisos completos de ejecución remota de código
Ojalá las autoridades de certificación y los expertos en criptografía puedan bloquear este tipo de actualizaciones en los sistemas
Octavo comentario
Me pregunto si el "archivo de canal" está firmado y verificado por el driver de CS
Si no es así, podría tratarse de una gran vulnerabilidad del rootkit
Las entradas que se ejecutan con privilegios elevados deberían pasar al menos una verificación de integridad
El hecho de que el archivo de canal pueda simplemente borrarse sugiere que no existe un mecanismo anti-detección
1 comentarios
Comentarios en Hacker News
Primer comentario
Segundo comentario
Tercer comentario
Cuarto comentario
Quinto comentario
Sexto comentario
Séptimo comentario
Octavo comentario