Análisis de lo de Crowdstrike [ENG]

En resumen: ha sido un puntero a NULL. La memoria de un ordenador no es más que una matriz gigante de números. Representamos estos números aquí como hexadecimal, que es en base 16. ¿El problema? La computadora trató de leer el área de memoria 0x9c (aka 156). Esta es una región de memoria no válida para ningún programa. Cualquier programa que intente leerla será inmediatamente eliminado por Windows.

[#2 Ovlak]

Ha sido el típico error de júnior. Todavía no sé cómo ha podido llegar esa porción de código a producción en una empresa como CS. Es una cagada superlativa y es imposible que hubiera pasado el más mínimo test o control sin que esto hubiera cantado.

[#8 scalvo]

#2 las pruebas en producción. No hacerlo así es de cobardes.

[#16 Supercinexin]

#8 Mock it 'till you make it. Move fast and break things. Let the users be your best feedback. If you are thinking if you should be in the market, it's already too late.

Etcétera etcétera etcétera.

[#14 hablador_pasivo]

#2 seguramente es una situación bastante más compleja que la sobre simplificación del tweet.

[#1 cenutrios_unidos]

Entonces es que lo sacaron sin siquiera probarlo...

[#4 wai]

#1 Pero ni una sola prueba... y ni un test unitario ni nah de nah de nah.

Ahora habría que ver qué arreglaba el hotfix y si era realmente tan importante como para cometer tal cadena de temeridades.

[#13 hablador_pasivo]

#1 seguramente lo probaron pero no se la pruebas era errónea o incompleta.

No tengo ni idea, pero suele ser así.

[#3 ipanies]

Ha sido un ensayo para un próximo apagón por tormenta solar o ataque terrorista... O han subido una actualización sin probarla y eso casi da más miedo que la tormenta solar y el ataque terrorista juntos

[#15 Ovlak]

#12 Sí, doy fe de que así ha sido de primera mano.

[#11 Ovlak]

#10 Ya, pero tienes que respetar la decisión del cliente de no actualizarse a la última versión. Es a su cuenta y riesgo comprometer algo de ciberseguridad a cambio de ganar en estabilidad. Si das esa posibilidad y después no la respetas apaga y vámonos.

[#12 cosmonauta]

#11 Hostia... ¿Me estas diciendo que llegaron a joder sistemas con políticas de deploy retrasadas? Impresionante.

[#17 guillersk]

#12 parece ( hablo de oídas) que lo que puedes retrasar son las actualuzaciones de "definiciones" pero no la del motor, que ed lo que ha cascado.


Como decis, el como pudo llegar ese codigo a prod se debe investigar

[#18 guillersk]

#12 microsoft, por ejemplo tiene parches normales, que puedes retrasar y parches " si o si" que pueden aplicar en caso de una megacagada, o 0-day o similares, me suena que las actualizaciones de certificados raiz van así

[#5 cosmonauta]

Hay que ser muy fino para programar a nivel de kernel.

No tiene sentido que ese código haya llegado a producción. Sospecho que no se probó bien en Windows.

Eso con Rust no habría pasado.

[#6 Ovlak]

#5 Yo sospecho que no se probó nada en absoluto. Por lo que tengo entendido, no ha habido entorno Windows superior a la versión 6.1 en el que no haya fallado. Es un error terrible a nivel de organización, nunca habría tenido que llegar a producción.

[#7 cosmonauta]

#6 No me lo puedo explicar. No puedo entender que una empresa tan grande lleve código sin testear a producción. No es que les quiera exculpar. Es un caso de incompetencia extrema pero quiero creer que si existen esas medidas de calidad pero tuvieron la mala suerte de una cadena de errores no prevista.

Creo que no he visto ni un solo proyecto en 10 años que no tenga un pipeline de CI/CD que no incluya al menos correr unos cuantos tests.

Es que ..estoy pensando ahora mismo...que el propio IDE me avisa si no compruebo en valor de un puntero antes de acceder a el. Y los linters, y los tests, las pruebas manuales, etc, etc... Es inconcebible.

[#9 Ovlak]

#7 Estoy como tú, es tan inverosímil que ya empiezo a plantearme que la posibilidad de un sabotaje por parte de uno o varios empleados descontentos puede hasta tener más sentido que semejante cadena de errores. Es más, a mí hay algo que también me llama mucho la atención: se que el Falcon tiene la posibilidad de definir las políticas de actualización automática del Sensor por grupos de hosts, permitiendo que estos no se actualicen a la última versión inmediatamente sino que se mantengan en la N-1 o N-2 según preferencias. Y, sin embargo, esta actualización coló a todos los hosts de los clientes con independencia de lo que dictara dicha política. Muy raro todo. Crowdstrike todavía debe muchas explicaciones.

[#10 cosmonauta]

#9 Un devops me comentaba ayer que por un lado tienes la presión de hacer el deploy n-1, pero por otro lado, están habiendo muchos ataques recientemente y nadie quiere estar retrasado y salir en las noticias, o sea que ja presión es actualizar ASAP.

[#19 naghodoo]

#9
Por lo que he leído ayer en el hilo de Reddit el problema ha sido con la actualización de un archivo de definiciones que de algún modo se corrompió, por esa razón ha afectado incluso en los casos de empresas con políticas de actualización de versión N-x; la actualización no era del cliente.

Yo no creo que hayan desplegado sin probarlo, seguramente lo han hecho pero simplemente ha ocurrido algo totalmente inesperado. Si realmente ha sido un archivo corrupto probablemente es que el archivo se corrompió en algún punto después de las pruebas.

Lo que sí que no tiene perdón es que no tengan algún modo de comprobar si el archivo es correcto antes de que el cliente se ponga a leerlo, ni de que no tengan algún mecanismo para evitar que falle si un archivo llega corrupto. Y lo que es probablemente peor es que no tengan algún tipo de "canary deployment".

No creo que haga falta ningún tipo de sabotaje para que algo así pase. Lo más probable es que simplemente pequeños errores o carencias en el proceso de paso a producción y de manejo de errores se hayan alineado de modo que el desastre ha sido posible (https://en.wikipedia.org/wiki/Swiss_cheese_model).