Portada
Hace 2 días | Por Ovlak a threadreaderapp.com
Publicado hace 2 días por Ovlak a threadreaderapp.com
El fallo de Windows. CrowdStrike ha hablado

El fallo de Windows. CrowdStrike ha hablado

 threadreaderapp.com

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

DE3C548D-E347-406A-A60F-E6BBD322CAB7 6.2k 138

Comentarios

R

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.

V 49
K 346
Fingolfin

#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

V 4
K 34
J
editado

#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.

V 0
K 9
Peroquedices

#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 fichero afectado, al menos no sin deshabilitar el servicio y cargarte todas las copias que tengas.
Al menos el lunes idearon un parche que consideraba su propio fichero afectado como dañino y lo metía en cuarentena, así el propio Falcon no llegaba a leer el fichero afectado; ya que la cuarentena es una acción prioritaria frente al bloqueo o eliminación del archivo dañino. Muy ingenioso, la verdad, así es como se han resuelto los problemas en unos pocos millones de equipos/servidores desde el lunes. Aunque fueron lentos y el lunes solo lo aplicaban a demanda abriendoles un ticket, después vieron que mejor aplicarselo a todo el mundo ya que en el peor de los casos el equipo se quedaba igual.

V 6
K 54
J

#61 Qué claro todo. Gracias

V 0
K 9
DraWatson

#61 muy ingenioso ese parche. ¿Tienes algún enlace donde hablen de él?

V 0
K 6
Peroquedices

#88 Aquí tienes toda la info: https://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"

V 0
K 6
Polarin

#61 Pero no todos... 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.

V 0
K 9
apetor

#6 Para eso hace falta metering de updates con margen de tiempo, y aqui no parece haberlo habido.

V 2
K 19
f

#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...

V 3
K 31
N

#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.

V 1
K 16
Polarin

#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.

V 1
K 16
J

#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"

V 5
K 45
d

#13 "es solo un detallito que no va a afectar a nada"

V 1
K 16
f

#13 sí, el típico, "lo que he cambiado no puede romper nada" y siempre siempre se lía.

V 1
K 15
prejudice

#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"

V 2
K 23
elonmusk

#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 

V 1
K 12
N

#13 el típico despliegue a producción del viernes, nunca mejor dicho.

V 0
K 7
Polarin

#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.

V 0
K 9
apetor
editado

#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.

V 6
K 66
apetor

#39 Eso y mas, ver #14.

V 1
K 19
Peazo_galgo
editado

#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...

V 2
K 32
o

#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

V 1
K 18
Peazo_galgo

#30 yap pero... Tú ves a cloudstrike o mocosoft pagando algo a los damnificados....? roll

V 0
K 10
o

#68 no, de hecho como digo, implicará más gastos a los que quieran "protegerse" de esto

V 0
K 6
Peroquedices

#26 Al final la culpa al becario y a las vacaciones de los senior

V 0
K 6
apetor

#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.

V 0
K 10
N

#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.

V 0
K 7
o

#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.

V 5
K 44
c

#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...

V 0
K 11
o

#48 normalmente en azure no se hace en todo el mundo a la vez para eso tienen clústers en las regiones

V 0
K 6
c

#59 eso es..

V 0
K 11
Polarin

#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.

V 0
K 9
apetor

#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.

V 0
K 10
o
editado

#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"

V 1
K 16
p
editado

#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?

con lo molonas, modernas, y veloces que son las ultraliberales "metodologías ágiles"...

V 0
K 7
o

#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

V 0
K 6
Polarin

#28

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 un bloque de pisos: https://www.oscarperez.es/si-los-programadores-fueramos-albaniles/

Es es el problema. CI/CD y Agile esta muy bien para ciertas cosas, y si tienes que hacer algo industrial o critico, no. Esta muy bien para estresar a la gente, lol no habria odiado mas que tener que ir a una reunion diaria a decir que no tengo ni puta idea de por que el X funciona mal cuando todos los X meten la puta tarjeta... dejame mirar las putas 1000 clases... dentro de dos semanas hablamos.

V 2
K 25
Westgard

#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...

V 7
K 57
limoncio

#2 que sanity check, que esta gente despliega los viernes...

V 6
K 52
N

#33 error de principiantes...

V 1
K 16
beltzak

#33 Solo los putos amos hacen eso …

V 0
K 7
DangiAll

#2 Y que se saltaron los rings de updates, de primero de administración de sistemas, no actualizas todos los equipos a la vez.

V 3
K 38
Jesulisto

#40 ¡Que idea tan revolucionaria! lol

Parece mentira que haya que explicar algo tan básico

V 1
K 20
elonmusk

#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

V 1
K 13
O

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?

V 11
K 95
Ergo

#7 Porque el que tenía que ponerlo en cuarentena estaba de vacaciones

V 1
K 23
ostiayajoder
editado

#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...

V 1
K 15
apetor

#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 ).

V 1
K 19
M

#7 supongo que para evitar amenazas del tipo 0day

V 2
K 28
Polarin

#12 lo cual me lleva a pensar en quien se habra beneficiado del ZeroDay.

V 0
K 9
Jesulisto

#7 Buena política, exceptuando los zero days, es lo razonable.

V 1
K 16
Nitros

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.

lol

V 8
K 58
E

#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???!!!

V 2
K 18
W

#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…

V 0
K 9
higochungo

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.

V 7
K 57
AMDK6III
editado

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.

V 5
K 44
d
editado

#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....

V 6
K 46
apetor

#53 Para eso estan las ILOM y similares, KVMs como dice #29.

V 1
K 19
Jesulisto

#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.

V 2
K 30
AMDK6III

#29 El primero que ha mencionado Linux has sido tú
En todo caso, estamos de acuerdo en lo de KVM/ILO

V 0
K 9
Jesulisto

#19 La verdad es que hoy dia, el bare metal en una organización importante es irresponsable.

V 1
K 20
SaulBadman

#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 tal servidor, sin ninguna comunicación con el exterior.

Si esa máquina no la actualizas en 10~15 años va a dar completamente igual, ya que para cargar una web simple que actualice los datos cada X tiempo no necesitas más. Y además, si clonas la imagen del disco duro/almacenamiento y la guardas aparte, cuando esa máquina falle lo único que tienes que hacer es copiar con dd el fichero a la unidad y en pocos minutos lo tienes arreglado.

Históricamente, el mayor motivo que hay para usar software privativo (o al menos de una empresa gorda) es el poder tener alguien a quien culpar y gritarle por teléfono cuando se vaya al garete, pero a día de hoy, hay sistemas operativos más adecuados tanto libres como privativos, no sé cómo Windows se siguen usando frente a éstos lol

V 1
K 15
apetor
editado

#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.

V 0
K 10
z

¿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.

V 6
K 43
X
editado

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/

V 5
K 42
Varlak

#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.

V 7
K 64
R

#21 Exacto. Completamente inaceptable

V 1
K 13
X

#21 Es exactamente eso.

V 0
K 11
Jesulisto

#21 No hay que ser programador, solo tener un mínimo de cabeza mp

V 1
K 21
W

#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

V 1
K 16
z3t4

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,

V 4
K 41
yemeth

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?

V 3
K 33
Candidatas
12
meneos
tecnología Un estudio de VFX deja de usar CPU Intel por su alta tasa de fallos
21
meneos
tecnología Esclavitud 2.0: Ofertas de trabajo para programadores
17
meneos
tecnología A SimCity le salió tan cara la broma de poner a Godzilla en portada que tuvieron que destruir todas las cajas del simulador
18
meneos
tecnología El monoplaza de Formula Student Bizkaia se corona como el mejor vehículo eléctrico en Reino Unido
8
meneos
tecnología Hackers de Nullbulge roban información sobre proyectos inéditos de Disney
17
meneos
tecnología Los actores de doblaje de videojuegos se declaran oficialmente en huelga a causa de la IA
27
meneos
tecnología 10.704 URLs están prohibidas al navegar desde la red de Telefónica
22
meneos
tecnología Secure Boot está completamente roto en más de 200 modelos de 5 grandes fabricantes de dispositivos (ENG)
7
meneos
tecnología Plus Ultra: Legado, el videojuego que desmonta "la leyenda negra y la leyenda rosa" en torno a las hazañas de Hernán Cortés
17
meneos
tecnología Programadores legendarios (ENG)
32
meneos
tecnología Los extraños secretos que encontré investigando skins corruptos de Winamp (ENG)
5
meneos
tecnología CrowdStrike más allá de Windows [ENG]
14
meneos
tecnología No, Southwest Airlines no está usando todavía Windows 3.1 [ENG]
8
meneos
tecnología La caducidad de los medicamentos podría suponer un reto para las misiones espaciales de larga duración (eng)
6
meneos
tecnología Demanda y producción eléctrica en tiempo real
3
meneos
tecnología El papel de la computación cuántica en la industria automotriz
8
meneos
tecnología Exposición 40 Aniversario de DINAMIC en el Museo de Málaga OXO
k

Y el beta testing y los despliegues progresivos y escalonados... ya tal

V 3
K 32
comadrejo
editado

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.

V 2
K 32
ostiayajoder
editado

#4 por?

V 2
K 21
comadrejo
editado

#22 #10 Anteriormente:
comparativa-principales-lenguajes-programacion/c021#c-21

Hace 3 años | Por deedee_agonias a medium.com
Publicado hace 3 años por deedee_agonias a medium.com

Comparativa de los principales lenguajes de progra...

 medium.com

V 2
K 26
apetor
editado

#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 ambito y nivel de asbtraccion distinto, no una mera propagacion sin filtro alguno.

Y en cuanto a los constructores y objetos en general: es muy bonito eso de subir tanto de nivel de abstraccion que uno quiere olvidarse de donde esta y llama al constructor en plan infalible... NO FUN CIO NA, no funciona. Por eso es mejor separar el constructor en Alloc e Init y mas temas ( y chequear ambas partes ). Me digan misa los altonivelistas, la realidad es que estas en una maquina con recursos limitados ( por teras que tenga ) y que las situaciones donde el mundo es negrogris en vez de rosa se dan y mucho. Luego si, el programador DEBE pensar en lo que hay debajo y si, el programador DEBE poder controlarlo todo.

V 0
K 10
comadrejo

#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í.

V 2
K 29
apetor

#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 el catch es un , o sea, no se capturan las 2,3 o 4 cosas especificas que pueden ocurrir, se hace un "captura lo que sea, imprime el codigo y sigue".

Esto, entre otras cosas, hace que ante, por ejemplo, accesos a memoria no valida, estemos ante un potencial mono con pistolas/cuchillas/younameit, donde hay corrupcion de estructuras y demas. Incluso detectando esto o ya tratando de arreglarlo depurando, es un cristo del 15.

V 1
K 19
comadrejo

#58 "Amplificación del caos" llamo yo a la gestión de errores mediante excepciones.

V 2
K 29
apetor

#62 "deje, deja que siga para arriba, alguien cogera la patata caliente o... a alguien le explotara" lol

V 1
K 19
Polarin

#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.

V 0
K 9
Polarin

#58 Positivazo por lo de "un potencial mono con pistolas/cuchillas/younameit,"

V 1
K 19
Polarin

#54

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.

V 0
K 9
ostiayajoder
editado

#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++.

V 1
K 5
apetor
editado

#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". Incluso con lenguajes que desde el punto de vista de sistemas son juguetes ( una puta mierda ), no se trata de punteros, sino de que la creacion de un objeto tiene dos conceptos bien separados: uno es obtener recursos y otro es dar valores iniciales y/o hacer operaciones iniciales. Pues bien, sin pensar en punteros o como quieras, el concepto de que la reserva de recursos puede fallar debe ser una jodida PREMISA en programacion de sistemas, da igual que uses C, C++, Zig, Rust o lo que te salga del nabo.

Y ese error no hubiera pasado en java por que la mera idea de usar java para sistemas es poco mas o menos que un chiste en si mismo.

Por favor, no quiero tener que ir a arrogancias chungas, pero me fuerzas a insinuar una: "niño, ve a jugar con tus juguetes, estamos hablando de cosas de mayores" ( y si, CrowdStrike la ha cagado y bien, por jugar con herramientas que no son juguetes pero por no aplicar las premisas que SI, SON NECESARIAS, cuando se juega con herramientas que no son juguetes ).

Y por si acaso: no digo que .NET, Java, etc. no tengan su uso, CLARO que lo tienen, pero hablamos de programacion de sistemas, donde incluso un Rust te exige tener muy presentes estos conceptos y respetarlos.

V 2
K 22
Polarin
editado

#66 No te metas con mi leguje que he tenido que usar durante 20 anios... en vez de C++, mi amor de verdad.

V 0
K 9
apetor

#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, SIGSEGVs,... GPFs, invalid opcodes y demas ) como si fuesen y al mismo nivel que excepciones que son throws como tratamiento de errores diferido/propagado.

ESTO es un puto CANCER, cuando veo un casque ( me ha tocado depurar casques de otros departamentos en las empresas que he estado ) se en pocos minutos que se trata de esto que estoy diciendo y es de ponerte de mala ostia. No se pueden eludir responsabilidades como programador, es muy bonito vender esa moto academica de que los programadores no tienen porque trabajar a ese nivel de abstraccion ni saber de estas cosas pero yo creo que ese tipo de desarrolladores no son profesionales.

V 2
K 22
Polarin

#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.

V 2
K 26
Polarin

#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.

V 0
K 9
Polarin

#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 sabes que esto se va a meter una ostia que va a dejar sin cajeros a millones de personas si no tratas la excepcion bien... . Pero si no haces nada, hay algo asi como 100 personas cada 3 dias que se van a ir a quejar al banco porque no les han dado dinero, pero se lo han cargado en la cuenta. "

V 0
K 9
SaulBadman

#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 (https://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.

V 0
K 6
apetor

#c-55" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3962188/order/55">#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
#define ONERROR(x) if (((ERRORADDED_##type )(x)).Error)

ERRORADDED(TypoDeValorADevolver);

ERRORADDED_TypoDeValorADevolver NombreDeFuncion( parametros... )


ONERROR(NombreDeFuncion( parametros... ))


O bueno, muchas cosas del estilo... lo bueno de Rust, Zig y demas es que esto esta naturalizado en el lenguaje, pero ser no es gran cosa...

V 2
K 25
apetor
editado

#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.

V 6
K 62
cosmonauta

#22 Por eso no hay excepciones en go.

V 4
K 43
apetor

#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.

V 0
K 10
Arlick

#34 pero hay panic

V 1
K 17
cosmonauta

#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

V 0
K 11
ostiayajoder

#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.

V 0
K 6
apetor

#64 No se a donde coño vas, pero se ve que de cosas de sistemas... poco.

V 2
K 22
Polarin

#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 que a las 2 de la maniana se conecta a una central en Leon o Almeria, no le importa tu excepcion, si no que cojones hacer antes de que todos los telefonos de una provincia se vayan a tomar por culo y manian salga en las noticias.

Usabamos try-catch... y desarrolle una herencia de errores para controlarlos todos y saber que mensaje habia que darle a los ingenieros. Eso llevo semanas y despues meses de tuneo.

V 0
K 9
Polarin

#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 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 sabes que esto se va a meter una ostia que va a dejar sin cajeros a millones de personas si no tratas la excepcion bien... . Pero si no haces nada, hay algo asi como 100 personas cada 3 dias que se van a ir a quejar al banco porque no les han dado dinero, pero se lo han cargado en la cuenta.

Pues mi jefe era de los que decia que el sprint tenia que terminarse a tiempo y que eso lo veriamos luego.

V 0
K 9
manbobi

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.

V 4
K 31
Wajahpantat

#1 Corroboro que no tienes ni idea, pero matizo que yo tampoco. Espero que te valga.

V 12
K 89
Y

#16 Ambos han sido corroborados . Atte

V 2
K 22
manbobi

#16 #18 Pues nada nuevo entonces...

V 0
K 13
cosmonauta

#27 Pero si tienes la explicación en el envío...wall

V 0
K 11
manbobi
editado

#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.

V 0
K 13
N

#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.

V 0
K 7
k

#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.

V 1
K 19
Polarin

#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.

V 0
K 9
k

#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 lol

V 0
K 6
Polarin

#1 Positivo por la referencia: "La lie parda".

V 0
K 9
coderspirit

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.

V 3
K 30
kavra

Esos maravillosos canary...que no tienen...

V 1
K 18
C

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.

V 0
K 11
Thalin

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.

V 0
K 6
d

#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

V 1
K 14
Thalin

#95 Merci

V 0
K 6
1 2