edición general
150 meneos
6266 clics
El fallo de Windows. CrowdStrike ha hablado

El fallo de Windows. CrowdStrike ha hablado

Todos pecamos de prisas (yo incluído) y la información vino en tromba. He leído su explicación y te resumo la verdad, breve y sencilla. Hoy, 24 de julio, CrowdStrike publica un PIR (Preliminary Post Incident Review). Es decir, una revisión de un incidente para identificar las causas y planificar acciones.

| etiquetas: crowdstrike , windows , bsod
Comentarios destacados:                              
#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.
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.
#17 Te comento, la metedura de pata la corrigieron sobre las 7:30 de la mañana del viernes, había pasado casi 1:30h desde el despliegue de la actualización afectada. El problema es que todo equipo/servidor que estuviera encendido, se vio afectado, y cuando estaba afectado ya era tarde porque empezaban los reinicios.
Sobre lo que comentas del backup, las VM en Azure que tengan el servicio de Azure backup no permiten arrancar en modo seguro para p ej en las primeras horas arrancarlo y borrar el…   » ver todo el comentario
#61 Qué claro todo. Gracias :-)
#61 muy ingenioso ese parche. ¿Tienes algún enlace donde hablen de él?
#88 Aquí tienes toda la info: www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub
Sobre el parche y su aplicación masiva lo dicen en la parte que comienza por "File Classification Status" en: "the impacted version of the channel file was added to Falcon’s known-bad list in the CrowdStrike Cloud"
#61 Pero no todos... :-D en mi empresa no paso nada porque los capullos bloquean las actualizaciones.

Sin embargo en el JP Morgan les cagaron parte de la flota de las ATMs.
#6 Para eso hace falta metering de updates con margen de tiempo, y aqui no parece haberlo habido.
#6 para eso están los los canary, clientes de confianza o máquinas internas con "permiso" para que puedan fallar.

Pero es que antes, como dice #2 faltan unos test básicos. Y aún antes, añado yo, falta cobertura en esos test.

Que si que se pueden colar cosas pero ya es raro...
#43 según se lee en el hilo, cobertura tenían de la versión anterior. El problema vino después, sacando a producción una nueva versión que no pasó todos los test que debiera. Huele a típicas prisas por sacar algo pasando por alto lo más básico.
#43 Es que mucha gente no hace green-blue ni pollas. Ya se que no es el mismo caso. Pero en banca hay gente que se queja de que por que tienen que tener dos entornos, incluso para sistemas de cara al publico, que eso es un gasto.

Y gente que no tiene ni QA realemente, porque tienen un equipo de "support" que mete cosas en Produccion si que haya habido un tio/a de QA que lo certifique y lo pare, porque son aplicaciones internas. Y estamos hablando de un banco a nivel mundial. El truco es hacerlo a hora raras y si no peta nada... pues no pasa nada.
#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"
#13 "es solo un detallito que no va a afectar a nada"
#13 sí, el típico, "lo que he cambiado no puede romper nada" y siempre siempre se lía.
#13 "Mete esto pero ya que nos están metiendo presión desde arriba, que se quieren coger vacaciones y esto tiene que estar para ya sin falta"
#56 pues se quedaron sin coger vuelos :-) así aprenden.. los de abajo cobrando horas extra y sacando canas, los de arriba lamiéndose las heridas .. y todos, quitándose años de vida 
#13 el típico despliegue a producción del viernes, nunca mejor dicho.
#13 Si y no... como antiguio desarrollador de algo que si se cae, sale en las noticias... hay bancos que se mosquean porque hay uno de QA de la empresa que les hace X sistema y les para el despliegue a Produccion porque no ve claro que el cacharro de los cojones funciona bien o que QA funciona raro.

Todo el mundo se piensa que un cacharro de estos (y no estoy hablando de un parche al kernel de Windows, que no se ni como va, mas alla de haberme metido hace mucho tiempo en DLLs para hace cositas) es como cambiar la lavadora, y ni eso... que es como cambiar el televisor.
#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…   » ver todo el comentario
#39 Eso y mas, ver #14.
#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... :-P
#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
#30 yap pero... Tú ves a cloudstrike o mocosoft pagando algo a los damnificados....? :roll:
#68 no, de hecho como digo, implicará más gastos a los que quieran "protegerse" de esto
#26 Al final la culpa al becario y a las vacaciones de los senior :shit:
#26 La responsabilidad aqui es un gran arbol con cadenas cliente>proveedor>proveedor>proveedor...>CrowdStrike. Todas acaban en CrowdStrike como nodo raiz. El tema de quienes tengan tiempo y dinero para litigar y demas... y depende de cada pais y los TOS y EULAs y demas... el coste ha sido bestial, el metacoste de intentar recuperar perdidas por via legal... ojo, que puede ser una cola de AÑOS.
#26 depende. En Azure la suscripción de empresa más cara tiene un límite de caída de servicio de 2 minutos al año, si no recuerda mal. El resto un tiempo superior, a medida que pagas menos. Si pasa más tiempo, Amazon tiene que devolverte el dinero.
Luego queda en la mano de cada empresa denunciar las pérdidas y Amazon, Microsoft o el que toque, ya se encargará de tirar la mierda para arriba.
#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.
#28 es que no es lo mismo revertir una imagen de docker que un software desplegado en millones de máquinas. El coste del error no es ni remotamente el mismo.
Estos lo que tienen que hacer es el despliegue de forma escalonada, no todo el mundo a la vez...
#48 normalmente en azure no se hace en todo el mundo a la vez para eso tienen clústers en las regiones
#59 eso es..
#48 Hay gente que no hace green-blue ni pollas... y ya ni hablamos de especificaciones... o QA

He tenido bancos que no entendian por que un despliege blue-green con un sistema de cara al publico.
#28 La beta continua famosa, no inherente al agile pero si estadisticamente muy correlacionado o que "van de la mano", pa temas de sistemas... hmmm... depende, pero la verdad es que las prisas... no son buenas. Aunque si que si dedicas recursos y pocas prisas a una buena base luego ya puedes correr un poco mas, pero siempre con cuidado.
#73 a mi modo de ver, a veces puedes correr y otras tienes que madurarlo. Dicho esto nunca vas a probar todo al 100% porque es imposible en un mundo real. Pero si, todo se arregla ahora con la "beta"
#28 es que las metodologías de planificación robusta y segura, suenan mucho a economia desarrollo planificado, ¿no serás un comunishta de esos? :troll:

con lo molonas, modernas, y veloces que son las ultraliberales "metodologías ágiles"... :troll:
#80 Pues ahora que comentas eso, igual pasa que en ambos mundos no hay un martillo de oro y aveces hay que mezclar ambos métodos
#28 :take: :take:

Como decia el gran Grady Booch (parafraseando): un sistema informatico es un sistema no lineal, asi que los fallos debido a una entrada, no tiene una relacion lineal. Que un pequenio cambio, peta todo.


Los CI/CD esta muy bien, pero es como Agile, introduce la narrativa falsa de los cambios incrementales. Eso esta muy bien si quieres pintar una pared de verde o azul, no si tienes que cambiar los cimientos de un edificio, porque los planos son de un polideportivo en vez de…   » ver todo el comentario
#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... :roll:

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...
#33 error de principiantes... :troll:
#33 Solo los putos amos hacen eso … :troll:
#2 Y que se saltaron los rings de updates, de primero de administración de sistemas, no actualizas todos los equipos a la vez.
#40 ¡Que idea tan revolucionaria! xD

Parece mentira que haya que explicar algo tan básico :-(
#2 100% de acuerdo, si antes de sacar nueva release no eres capaz ni de testear en un lab y pasar ese control de calidad.. y no es que un modelo específico de terminal, o un Windows N particular con noseque módulo de Kernel petara.. no, sino que todos los sistemas tontos del planeta se frizaron, vamos anda.. a contar películas al bar.. M$ y CrowdStrike estan buscando la manera de limpiar su imagen, pero sobre todo la segunda, la ha liado parda.. 
Lo que no quita que mañana a Linus Torvalds se le escape un bug en el kernel de Linux, o alguna librería mantenía por un friki (como xy), que te llegan unos lobos con piel de cordero y te tratan de meterte un backdoor así x la cara.. pues eso.. pero Open Source always better than closed shit
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 :troll:
#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...
#11 Su software o bien es un driver, luego es como decir que es una libreria en el kernel, luego ese pete significa pete del kernel, o bien ocurre en un proceso critico del sistema, en una DLL inyectada o similar ( no se sabe, podrian ser ambas incluso, de los 3 tipos de BSOD que yo he visto en las imagenes, 2 de ellos son BSODs de casque en kernel y el otro restante es un BSOD por que un proceso de sistema ha petado a nivel de usuario pero petado al fin y al cabo ).
#7 supongo que para evitar amenazas del tipo 0day
#12 lo cual me lleva a pensar en quien se habra beneficiado del ZeroDay.
#7 Buena política, exceptuando los zero days, es lo razonable.
Porque hacer un canary release a un porcentaje pequeño de las máquinas no se le ha ocurrido a nadie nunca.

Casi imposible de evitar dice el notas.

xD
#37 El comentario más infravalorado del meneo.
QA es necesario. Desplegar en entornos de staging tb, pero quién coño en su sano juicio hace un despliegue masivo sin utilizar una estrategia canary???!!!
#39 porque toda la esencia del sistema que venden es que son los más rápidos en detectar nuevas amenazas, y eso es incompatible con UATs y Canarys…

Por eso han creado el Validator… para dormir más tranquilos…
Incluso yo, que soy un mindundi comparado con esta gente, tengo la política de desplegar de manera segmentada en tres fases, de clientes menos críticos a más críticos, para evitar que un error de este tipo, que efectivamente es muy difícil de predecir, se cargue la disponibilidad de TODOS mis clientes. A mí me hubiera pasado, pero sólo hubiera afectado a la parte menos crítica de mis clientes antes de darme cuenta.

No me vale.
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
www.reddit.com/r/crowdstrike/comments/1cluxzz/crowdstrike_kernel_panic

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....
#53 Para eso estan las ILOM y similares, KVMs como dice #29.
#77 Llevo jubilado un tiempo pero en los últimos años terminé virtualizando toda mi infraestructura, aparte de tener backups en datacenters de diferentes ciudades.
Sé que soy un poco paranoico pero duermo mejor sabiendo que tengo un plan B,C y D, como mínimo.
#29 El primero que ha mencionado Linux has sido tú :troll:
En todo caso, estamos de acuerdo en lo de KVM/ILO :-)
#19 La verdad es que hoy dia, el bare metal en una organización importante es irresponsable.
#19 No soy un fan duro que Linux, pero una cosa es segura: Usar un sistema operativo de escritorio, para un uso que no es de escritorio, no tiene sentido.

Para una simple lista de llegadas y salidas de un aeropuerto (o cualquier cartelería de las cuales he visto con el BSOD en las noticias) puedes poner una máquina con Linux que abra un navegador ocupando el 100% de la pantalla, que abra una web alojada en el servidor que maneje tales datos, y que la única conexión que pueda tener sea…   » ver todo el comentario
#65 Puedes configurar un Windows para que sea un server rollo... vamos, minimo, sin escritorio y tal. Pero bueno, quiza solo por escapar un poco del malware que hay para Windows y demas, sea buena idea tirar de Linux o BSD o tal. Eso si, siempre siendo consciente de que en realidad no es, per se, una cosa que ocurra por ser Windows y no ocurra por ser Linux, es mero rollo... el malware va a lo mas tipico/usado. En Linux te ahorras mucho malware y el antimalware.
¿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.
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 www.reddit.com/r/crowdstrike/comments/1easbmf/preliminary_post_inciden
#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.
#21 No hay que ser programador, solo tener un mínimo de cabeza mp
#21 No se prueba realmente, porque para ello han creado el Content Validator.

Esto va de que, como los templates se han de distribuir muy rápido, y no da tiempo de validarlos a mano, a tiempo, colocan el Content Validator a modo de cortafuegos.

El content validator da una (falsa sensación de) seguridad y esto es lo que realmente ha generado el error.

1/ Tenemos que distribuir con premura
2/ Si la liamos tenemos el content validator

Aquí nadie ha vigilado al vigilante (suficientemente) y el bug ha entrado por la puerta grande.

No hay más. Hasta ahora se han forrado de defender de ataques siendo muy muy rápidos… pero la velocidad sin control no sirve de nada #pirelliP6000
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 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?
Y el beta testing y los despliegues progresivos y escalonados... ya tal
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.
#42 Si, para mi son una mala chapuza... pero hago enfasis tambien en que engendran programadores con malos habitos y un tanto descuidados.

El error debe tratarse alli donde ocurre o, en contadas situaciones excepcionales, en un nivel inmediato propagandolos... pero prefiero tratarlos donde ocurren y mandarlos a su vez hacia arriba, donde haga falta, pero ya como error de esa funcion, no de la API llamada que genero el error. O sea, seria un error "nuevo"/"derivado" y de un…   » ver todo el comentario
#47 La mayoría de los fallos que he presenciado en producción, como administrador de sistemas, han sido generados por programas que no trataban correctamente los errores, generalmente abusando de las excepciones. Es un clásico no comprobar si las variables están inicializadas, dimensiones equivocadas en los arreglos, etc.

Y te hablo de entornos con criticidad media como sate en aeropuertos, venta de billetes para sistemas de transporte y cosas así.
#54 Pero es que ademas, los try-catch, sobre todo como se vende que es comodo/bueno usarlos, que es para capturar errores unos cuantos niveles mas arriba, poniendo excusas como "permiten gestionar el error donde tiene sentido hacerlo", "tener un punto comun de tratamiento de errores" y demas BULLSHIT.

Y eso, cuanto el try-catch encierra varios niveles de funciones donde ocurre la excepcion, donde esta dos o tres niveles mas arriba del punto donde ocurren, suele llevar a que…   » ver todo el comentario
#58 "Amplificación del caos" llamo yo a la gestión de errores mediante excepciones. :troll:
#62 "deje, deja que siga para arriba, alguien cogera la patata caliente o... a alguien le explotara" xD
#69 #62 Pero eso es lo que pasa, que a veces no puedes hacer nada... a menos que sea sentarte con los arquitectos y sacar la sierra mecanica.
#58 Positivazo por lo de "un potencial mono con pistolas/cuchillas/younameit,"

:-> :->
#54 :-D

Si alguien no comprueba si una variable no esta inicializada, viene el fantasma de C y te pega con una excepcion en toda la cabeza.
#47 el programador DEBE poder controlarlo todo.

Jajaja NO.

Pero para nada.

El programador tiene q aportar valor al negocio, no hacerse pajas con los punteros.

Q ojo, q lo dogo desde el respeto a C++ y no digo q haya aplicaciones donde C++ tenga sentido, pero NO, NI DE PALO en la mayoria.

Este error;

ESTE ERROR NO HUBIERA OCURRIDO SI EL PROGRAMA ESTUVIERA EN JAVA.

Y ahora si quereis me venis con q el problema son las excepciones, pero java no te deja sin poder arrancar.

Seran las excepciones en C++.
#60 Amigo, JAVA, .NET y otras son juguetes a este respecto; si, funcionan y sirven para lo que sirven, pero estamos hablando de lo que estamos hablando, de codigo de sistemas, donde NO, NO vale eso de que el programador tiene que aportar valor añadido ( ya ala, lo demas... ). Parte del valor añadido de lo que aporta un programador de sistemas, kernel, drivers, etc. es la ESTABILIDAD, la ROBUSTEZ, eso ADEMAS de la funcionalidad ofrecida.

No es "hacerse pajas mentales con punteros".…   » ver todo el comentario
#66 No te metas con mi leguje que he tenido que usar durante 20 anios... en vez de C++, mi amor de verdad.:foreveralone:
#60 De hecho, existen dos niveles de excepciones en la realidad, o sea, en programacion de sistemas ( incluso en modo usuario, esto no es exclusivo de kernel o drivers ). Pero no se si merece la pena ponernos a explicar esto.

De hecho, usar try-catch en algo que no sea java, .net y demas, cuando se hace lejos de la fuente de las excepciones, donde casi todo cristo hace su catch{...} ( o sea, captura todo, lo que sea ), tiene el GRAN riesgo de capturar excepciones de sistema ( fallos de pagina,…   » ver todo el comentario
#71 #60

A ver, teniendo en cuenta que he programado JAVA desde ... 1999 (pero no ahora), pero que mi amor de verdad es C++...

Los programadores de java ven un "ClassDefNotFound" y no saben que viene del linker.

Hace mucho tiempo, 15-20 anios habia un profesor de universidad en EEUU que se quejaba de que las universidades metieran JAVA como lenguaje de iniciacion, en vez de Pascal, C o C++, y el tio contaba esto mismo: lenguajes interpretados no exponen a la gente a como funcionan los compiladores. Y JAVA termina siendo ejecutado en una VM, que termina linkando liberias.

Y tengo mi taza de la JAVA expo del 99 en mi mesa. JAVA no se puede usa para ciertas cosas. Y esta es una.
#71 Pero yo creo que el problema son las putas tecnologias agiles: tu soluciona el error y para el proximo sprint.

No te dejan pararte y cambiar arquitecturas.
#47 A veces tienes frameworks o sistemas que llaman a tus objetos, que no puedes tratar el error asi como asi. Como en mi post anterior explico:

"El problema es que haces con una excepcion en tu clase en un paso de una transaccion, cuando el sistema se la va a comer con patatas porque no se puede caer porque no se puede caer. Si la propagas hacia arriba, llegas a un punto donde te estan usando objetos que tu no controlas, que los ves en codigo porqu es JAVA y lo decompilas, pero lees y…   » ver todo el comentario
#42 Te doy la razón con respecto al comentario que enlazas, y es verdad que cuando llevas muchas horas escribiendo código miras qué hace, qué variables necesita, y qué devuelve, no el tipo de excepciones que pueda dar.

Creo que el único que lenguaje (que yo conozca al menos) que hace esto bien es Rust con su estructura Result (doc.rust-lang.org/rust-by-example/error/result.html) en la que devuelve Ok con un valor dentro en caso de ir todo bien, o Err en caso de error junto al código de error producido.
#55 No es solo Rust, tambien Zig ( y de forma, quiza, mas elegante ), eso son encapsuladores ( mas o menos intrinsecos del lenguaje ) donde hay un enumerativo o booleano adherido al resultado del typo que sea. Enums, Options, Errors,... puedes trabajar incluso en C con construcciones similares. Basicamente donde tienes un:

TypoDeValorADevolver NombreDeFuncion( parametros... )
{
...
}

Pasas a

#define ERRORADDED(type) typedef ERRORADDED_##type { BOOLEAN Error; type Result; }
#define ONERROR(x)…   » ver todo el comentario
#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.
#34 Y en otras... a mi... que me digan lo que quieran, pero con todo ese "rawness" de C... poco le falta y poco le sobra a C.
#34 pero hay panic :-)
#49 Ese es el tema. El mecanismo de excepciones existe pero está escondido deliberadamente. Se ha diseñado así. Podrían haber puesto excepciones pero no quisieron hacerlo
#22 no tengo otra cosa q hacer q andar con esas chorradas:

Si peta la API puede ser por mi culpa (500) o por culpa de quien me llama (400) ya esta, no necesito saber mas.
#64 No se a donde coño vas, pero se ve que de cosas de sistemas... poco.
#22 No estoy de acuerdo del todo... pero veo tu razonamiento... .

En 1999 curraba en un sistema de TID que, entre muchas cosas, servia para connectarse a las centrales de telefonia. Eso no se podia caer, parasar lo que pasara, pero era JAVA. La gente que currabamos eramos un poco paranoicos y comprobabamos TODO. Habia formas de volver al menu principal, de reseatear, si algo fallaba a nivel de conexcion, habia mensajes a los operadores de que habia pasado, explicitamente, porque a un ingeniero…   » ver todo el comentario
#4 Si y no... como anectoda personal, a mi no me tragaba el jefe de proyecto porque me negaba a decir cuando iba a terminar los sprints si encontraba una excepcion. Usabamos un framework/sistema con miles de clases. Nosotros extendiamos clases que corrian y cambiamos el comportamiento por inyeccion.... .

El problema es que haces con una excepcion en tu clase en un paso de una transaccion, cuando el sistema se la va a comer con patatas porque no se puede caer porque no se puede caer. Si la…   » ver todo el comentario
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...:wall:
#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. :-)
#35 hombre, en lo que comenta el twitero, que supongo que habrá sintetizado el comunicado de la empresa, está implícito que han desplegado un cambio sin hacer testing y encima no han hecho un manejo de control de excepciones correcto. Es posible que no sea toda la verdad pero es bastante plausible la causa.
#1 yo no lo he revisado personalmente, pero reversers que conozco, en busca de entrada de algun exploit han comentado que el sistema de crowdstrike se basa en hacer trucos para esquivar el firmado de código, y como tu dices poder así distribuir parches a nivel de kernel sin esperar la firma de Microsoft. Vamos, que la han liado parda y están ahí solos, porque si le echan la más mínima culpa a Windows y su incapacidad de recuperarse de drivers jodidos, Microsoft se les echa encima.
#97 Ya hace mucho que dejer de jugar a hacer exploits, pero eso no es muy peligroso? Te cargas las posiciones de entrada a DLLs, el sistema de (no me acuerdo como cojones se llama) de randomizacion de las entradas a las DLLs, que Mocosoft se saco hace 20 anios para que no nos metieramos en las DLLs.
#99 más peligroso para la salud es programar en J2EE, y ahí está la humanidad aún fustigándose. Aunque hay que admitir que el ASLR duele también bastante xD
#1 Positivo por la referencia: "La lie parda". :-D
Tengo un artículo a medio escribir sobre todo este asunto... y no sé cuando lo acabaré, porque hay mucha tela que cortar... pero este análisis me ha parecido terrible, malísimo.

La conclusión final "siendo sinceros, poco pudo hacerse." es todo lo errónea que podría ser. Sí, se pudo haber hecho mucho para evitar que algo así sucediera, y no me refiero a que esos bugs no sucedieran. Por supuesto que es normal que la gente se equivoque y que haya bugs, pero lo que sucedió no es ni mucho menos el resultado de dos bugs combinados, hay mucho más.
Esos maravillosos canary...que no tienen...
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.
Supongo que el crowdstrike este debe ser un programa externo a windows. Alguien me puede decir que hace ese programa? Escucho hablar de el pero ni idea de para que sirve.
#94 Es un EDR, resumido es un "antivirus" vitaminado
Al final un "antivirus" la ha liado mas, que el peor virus de la historia.
Ya veremos como acaba crowdstrike, se supone que son una empresa de ciberseguridad que viven de vender confianza y que no pasara nada malo y han sido los que lo han provocado... Pinta mal para ellos y no hay excusas que arreglen lo pasado
#95 Merci :->
«12
comentarios cerrados

menéame