Portada
mis comunidades
otras secciones
#2:
Medio mundo parado por una excepción mal manejada
que salta de un fichero mínimamente incorrecto
que no se detecta por un bug en un "Content Validator"
que ha pasado unos tests que justamente no comprobaban lo que falló.
Ya, pero eso no sirve como excusa, porque no es un fallo que el efecto fuera algo muy raro, o que necesitara una interacción con otro software para funcionar. Es un software que tumba la maquina. Que menos que hacer una prueba que coja una maquina fresca, instale el software, y verifique que funciona. Yo trabajo en software critico desplegado en muchos millones de maquinas y siempre se puede colar un bug, nadie es perfecto, pero uno que haga que no funcione nada? Ahí faltan unos sanity checks básicos.
que salta de un fichero mínimamente incorrecto
que no se detecta por un bug en un "Content Validator"
que ha pasado unos tests que justamente no comprobaban lo que falló.
Ya, pero eso no sirve como excusa, porque no es un fallo que el efecto fuera algo muy raro, o que necesitara una interacción con otro software para funcionar. Es un software que tumba la maquina. Que menos que hacer una prueba que coja una maquina fresca, instale el software, y verifique que funciona. Yo trabajo en software critico desplegado en muchos millones de maquinas y siempre se puede colar un bug, nadie es perfecto, pero uno que haga que no funcione nada? Ahí faltan unos sanity checks básicos.
#5:
No me he leído todo el tocho, pero parece una excusa. Una cosa es que un parche fallé en una o dos máquinas, pero ¿que falle en muchas? Mínimamente tendría que tener unos cuantos ambiente de staging y producción para hacer pruebas en ambiente lo más cercanos a los reales.
Edito: En Reddit lo explican mejor, y sí, parece que los tarados no hicieron suficientes pruebas https://www.reddit.com/r/crowdstrike/comments/1easbmf/preliminary_post_incident_review_pir_content/
Edito: En Reddit lo explican mejor, y sí, parece que los tarados no hicieron suficientes pruebas https://www.reddit.com/r/crowdstrike/comments/1easbmf/preliminary_post_incident_review_pir_content/
Comentarios
Medio mundo parado por una excepción mal manejada
que salta de un fichero mínimamente incorrecto
que no se detecta por un bug en un "Content Validator"
que ha pasado unos tests que justamente no comprobaban lo que falló.
Ya, pero eso no sirve como excusa, porque no es un fallo que el efecto fuera algo muy raro, o que necesitara una interacción con otro software para funcionar. Es un software que tumba la maquina. Que menos que hacer una prueba que coja una maquina fresca, instale el software, y verifique que funciona. Yo trabajo en software critico desplegado en muchos millones de maquinas y siempre se puede colar un bug, nadie es perfecto, pero uno que haga que no funcione nada? Ahí faltan unos sanity checks básicos.
#2 Y una mínima atención a los clientes y revertir rápidamente en cuanto sepas del fallo. Si retiran la actualización rápidamente esto no pasa
#6 Esto me cuesta más creerlo. Si hubieran podido hacer un hotfix lo habrían hecho 5 minutos después.
Igual sí que retiraron la versión pero los servidores actualizados ya no podían arrancar de cero para actualizarse.
De hecho, los servidores.afectados podrían haber levantado máquinas con copias de seguridad en las que se deshabilitaba Crowdstrike. Que no se hiciera tendrá un motivo, porque es raro.
De hecho hace dos semanas toqueteando sin tener cuidado lo que no tenía que tocar cerré el puerto 80 de un servidor de producción por error sin darme cuenta y me lo cargué todo. En 30 minutos habíamos cargado la imagen de la noche anterior para dar servicio. En 3-4 horas cualquier servicio debería estar otra vez de pie.
#6 Para eso hace falta metering de updates con margen de tiempo, y aqui no parece haberlo habido.
#2 Cualquier empresa que haga software crítico tiene un equipo de testers.
Seguramente los tengan, pero ni un solo tester probó la versión final.
Por imaginar, me suena a "tú cuela esta nueva funcionalidad para el despliegue de mañana que no va a romper nada"
#2 Ademas de eso que dicen ahora, esos dos bugs ( y no se, pero lo del validador... que expliquen porque un fichero de definiciones esta lleno de 00s, que es ese sys que hace que haya un problema al procesarse y se acceda a memoria no valida; joder, eso no es solo en testeo, el propio antivurus deberia tener unos minimos sanity checks de que un fichero que cargas no este todo a 00s -o en realidad que no tenga una validez donde se chequeen magics, tamaños y checksums/hashes- ):
- no tienen un sistema de deploy con metrado ( no se como traducir metering ) ? En las 2 anteriores empresas que he currado ( y diria que las anteriores tambien ) el despliegue de actualizaciones estaba segmentado: al principio se manda el update a unos pocos cientos, luego a unos miles y luego ya a todos. Raro es que algo tenga una urgencia brutal para acelerar o atajar esto ( si, en presencia de algo como un sql slammer, blaster o sasser, puede ser, pero ahi tienes que ir aun con mas pies de plomo, precisamente porque envias updates con urgencia ). Entre estos segmentos de updates hay unas horas y un seguimiento para detectar cosas gordas, gordas como esto de CrowdStrike.
- Y esto... no lo tienen los AVs pero deberiamos empezar a implementar algo asi todos: un sistema que detecte que en los ultimos dos, tres... n ( como si es uno solo ) arranques no se ha terminado de cargar el sistema con exito y, en ese caso, evite hacer nada o reduzca su actividad a un minimo basico al cargar. Detectar esto de un arranque fallido es trivial, se puede ser mas o menos estricto en lo que se considera arrancar con exito y como decidir si la culpa es potencialmente de nuestro driver o no, pero es algo que deberiamos hacer. Un BSOD es cosa mala, un BSOD sistematico que no permite arrancar la maquina y exige tanta interaccion manual es MUY MALO. En estos casos, y si se tiene miedo de que algun software malicioso puede instalar algo que provoque BSODs al arrancar para que el AV de turno se autodesactive como digo, se puede optar por un sistema que, detectando esa situacion, saque un prompt que avise al usuario de que se ha tenido que evitar la carga, indicandole durante unos segundos que deberia de consultar con su proveedor de seguridad o lo que sea, incluso se puede hacer al usuario pulsar una tecla para continuar o lo que sea ( interaccion, si, engorroso, si, pero no obligar a, en el mejor de los casos, sin bitlocker, tener que reiniciar, montar la particion en recovery, borrar el .sys,... ). Esto deberia acompañarse con un modulo que al arrancar ya el sistema mirara si ese "me aparto, no cargo" ha pasado y, en tal caso, consultar con los servidores de updates y demas, quiza tambien avisando al usuario que el sistema esta en un modo de proteccion reducida, mandar alertas administrativas a la consola de gestion de turno en instalaciones corporativas, etc.
Tenemos que aprender de esto, todos los desarrolladores de AV/Seguridad.
#2 es que la pregunta del millón es... ¿esta cagada QUIÉN y CÓMO la paga? Porque algo me dice que van a empezar a poner excusitas por allí y por allá para "escurrir el bulto" y que las multinacionales, empresas y administraciones públicas de todo el mundo que tuvieron "gritones" de "trólares" de pérdidas por la caída no van a ver ni un "trólar" de indemnización... y si no, al tiempo...
#26 pues las empresas que están en azure y demás clouds replicarán, duplicarán y harán el sw más defensivo, gastando el doble o el triple, durante un tiempo claro, cuando vean lo que gastan para un caso qie se da cada x meses o años, pasaran de todo otra vez (confiando en test rápidos, test de integración y no probando nunca en su conjunto) porque replicar todo es muy muy caro
#2 pero es que ahora se ha vendido al mundo que hacer desarrollos rápidos en micros y evoluciones pequeñas que pasan unos test super rápidos sirve para todo. Es más, como son tan pequeños es fácil revertirlos, y como todo está replicado y se hace blue Green canary no afectas más que un poquito en el peor de los casos.
Es el martillo de oro aplicado al ci/CD, esto está muy bien para muchas apps, pero para software industrial y software crítico no sirve, repito no sirve.
#2 a mi me hace gracia... esque fue un "pequeño error" en un archivo!... que no se detectó por un "pequeño error" en el content validator, por un "pequeño error" al no comprobar que eso pudiese pasar en QA...
Vamos a ver macho, entonces no es un error. Es un error. Sobre otro error... sobre otro error. 3 errores distintos y consecutivos que lo único que me demuestra es que si se te han colado 3 errores que se han alineado y han causado un BSOD es que probablemente tengas otros 40 errores en tu código que no has visto y que es una bomba de relojería esperando a reventar o que al menos esta todo cogido con alfileres por ahorrarte sueldos y QA en condiciones...
#2 que sanity check, que esta gente despliega los viernes...
No me he leído todo el tocho, pero parece una excusa. Una cosa es que un parche fallé en una o dos máquinas, pero ¿que falle en muchas? Mínimamente tendría que tener unos cuantos ambiente de staging y producción para hacer pruebas en ambiente lo más cercanos a los reales.
Edito: En Reddit lo explican mejor, y sí, parece que los tarados no hicieron suficientes pruebas https://www.reddit.com/r/crowdstrike/comments/1easbmf/preliminary_post_incident_review_pir_content/
#5 Yo no soy programador, pero si todas las máquinas que actualizaron dejaron de funcionar significa que la versión final no la probaron antes de lanzarla. Todo lo demás que me cuenten me parece una explicación de la causa del problema, pero el problema fué que no lo probaron antes de instalarlo en millones de máquinas, es así de simple.
#21 Exacto. Completamente inaceptable
#21 Es exactamente eso.
En muchos servers de empresas importantes las actualizaciones están demoradas un tiempo prudencial (días, semanas) para evitar este tipo de cosas. También pasa para la distribución de actualizaciones en windows con directivas administradas por los de sistemas. ¿Porqué se descargan tan inmediatamente actualizaciones en sistemas críticos?
#7 Porque el que tenía que ponerlo en cuarentena estaba de vacaciones
#7 Joder, y pq no se despliega en maquinas de pruebas para ver q todo funciona?
Q han reventado los SO, no solo se la ha oegado su software...
#7 supongo que para evitar amenazas del tipo 0day
¿Poco pudo hacerse? Si es lo que explica con intentar validar ese contenido erróneo en un entorno de pruebas antes de distribuirlo se tendría que haber detectado el problema.
Si me dices que a un bug de programación se le añade que el "Content Validator" que tenía que validarlo tenía otro bug, que encima la gestión de excepciones tenía otro bug más, y encima el entorno de pruebas no probaba lo que tenía que probar,... ¿eso es una cadena de casualidades, o una suma de deficiencias?
Yo sin tener remotamente idea de lo que hablo, por un envío de linkedin, gran parte del problema fue hacer desarrollos en un sys fuera del kernel para evitar el proceso de certificación de dichas modificaciones. Metieron la pata y como no hubo una detección debido a esa falta de certificación, la liaron parda.
Si hay algún experto en la sala igual lo corrobora, matiza o dice q no tengo ni idea, lo cual sería cierto.
#1 Corroboro que no tienes ni idea, pero matizo que yo tampoco. Espero que te valga.
#16 Ambos han sido corroborados . Atte
#16 #18 Pues nada nuevo entonces...
#27 Pero si tienes la explicación en el envío...
#31 La de crowdstrike, de modo que si ellos son los que dan explicaciones sobre algo que han provocado hay grandes posibilidades de que lo que cuenten no sea cierto del todo. De ahí mi apunte sobre otro apunte, que iba en la misma línea.
Y el beta testing y los despliegues progresivos y escalonados... ya tal
Si crodstrike hubiera hecho el mas mínimo QA, bateria de pruebas automatizadas, desplegando en staging, o desplegado primero en un número pequeño de clientes para luego ir desplegando en tandas, no un viernes, esto no hubiera pasado.
"Go fast, break things..."
Básicamente todo lo que el ceo acaba de prometer que van a hacer a partir de ahora,
Si tiene Windows 10 o Windows 11, vaya por panel de control, luego "Sistema y seguridad", abajo en "Herramientas de Windows", hay un enlace a "Ver registro de eventos", allí ejecuta un programa, vaya a la carpeta "Registros de Windows", hay varios ítems: Aplicación, seguridad, Instalación, Sistema.. si da clic en cualquiera de ellos, la mayoría tienen el icono de información, pero hay varios con "advertencia", "error". Hay una guerra silenciosa en nuestro PC con Windows, hay de "error" que son incomprensibles porque pasan.
Esta muy arraigado en demasiados programadores ignorar los errores o como mucho conducirlos por el camino genérico de las excepciones. Estructuras tipo "try"+"except/catch" no ayudan.
#4 por?
#4 En programacion de drivers, salvo el probing de memoria de apis concretas y en ambito muy reducido, no se usa try-catch, o mejor dicho, no se usa try-except. Y yo, ya desde hace muchos años, tengo mi batalla personal, incluso para modo usuario, contra el try-catch ( yo lo llamo "try-cancer and enjoy it" ). De hecho una de las cosas de ciertos lenguajes que odio es EL BODRIO de las excepciones. NO es una ventaja y, entre otras cosas, genera programadores vagos y despreocupados. Caguen dios, cada API que llames, miras el error JUSTO DESPUES DE LLAMAR, y si, chequeas cada puto codigo de error en cada puta llamada, ALLI DONDE PUEDA OCURRIR, copon, cojones ya.
#22 Por eso no hay excepciones en go.
Ni lo voy a leer.
Ya bastante (poco) estrés tengo con lo mío.
Soy un pinche de DevOps en entornos hiperconvergentes y en S.O. FOSS.
El que use Windows sobre metal, ya sabe lo que le espera. Asumieron el riesgo y cosecharon.
#19 Para los que estais obsesionados con que MS es KK y linux brutal el problema es la empresa que no hace test
Ya la liaron con RHEL 9.4
https://www.reddit.com/r/crowdstrike/comments/1cluxzz/crowdstrike_kernel_panic_rhel_94/
Y tener un server baremetal sin un controlador BMC que te permita un acceso KVM a la maquina incluso apagada es negligente y parece que mucha gente no los usa cuando todos los servers medio decentes los tienen
Vease ILO en HP o iDRAC en Dell....