Del fallo de CrowdStrike y Microsoft

En el canal de youtube se avanzó en el tema, que hace ya algo más de un mes, sobre el fallo mundial que afectó a una librería de CrowdStrike y Microsoft:

Al parecer, el problema a nivel técnico venía, precisamente, de un mal puntero a memoria en el código C++. Al principio parecía que el error se relacionaba con una desreferencia de un puntero NULL, después, parece que el programa leía punteros de una tabla en bucle, y algunos no eran válidos, provocando el error. Probablemente la causa del mal puntero venía de un archivo de configuración con entradas sin inicializar.

Más información técnica en:

Sea como fuera, parece obvio que el causante del problema es un puntero a memoria. Ahora, sin afán de ser conspiranoico, ¿no parece curioso que ocurra esto tan solo unos meses después de que la Oficina de su Director Nacional de Ciberseguridad (ONCD) de la Casa Blanca hiciera público un llamamiento a la industria del software para promover lenguajes memory-safe?

Básicamente, la Casa Blanca exhorta a dejar de utilizar lenguajes que no garanticen la seguridad de la memoria (mediante punteros) como C o C++, y recomiendan el uso de otros lenguajes que sí la garanticen como Rust, Python, Java, C#, Go… Es un intento de ‘ilegalización’ positiva (en el sentido de derecho, no moral) de C y C++ por parte del gobierno de EEUU.

También la NSA, para nada sospechosa de buscar “inseguridad por diseño” ha desaconsejado el uso de C/C++ por el mismo motivo hace unos meses más.

¿Habrá sido una enorme casualidad que en el mismo curso, instituciones de gobierno de EEUU desaconsejen programas no memory-safe, y ocurra un fallo a escala global provocado por un fallo de puntero a memoria? A saber.

4 Me gusta

Qué curioso, no sabía que las autoridades estaban desaconsejando el uso de C.

1 me gusta

Todo lo que tenga que ver con gobiernos, nunca trae noticias buenas en informática.

2 Me gusta

En eso no estoy del todo de acuerdo, si tengo la posibilidad de discernir.
El año pasado, en Europa, tuvieron un movimiento muy fuerte relacionado con los organismos gubernamentales y el código libre.
Por motivos que no voy a enumerar ahora, Se declaró públicamente el deseo de la Unión Europea de cambiar el software privativo de los gobiernos europeos por sus equivalentes libres. En Alemania, más concretamente, cambiaron la suite ofimática de Windows por una de código libre en 30.000 computadoras. Dependiendo del éxito de este cambio, se estimaba que pronto cambiarían Windows por distribuciones de Linux diseñadas para gobiernos.

1 me gusta

Aca en mi país seguimos atrasados 15 a 10 años con respecto a EEUU o Europa en software libre. Malas gestiones y decisiones nos llevaron al atraso actual.

2 Me gusta

En eso estamos en un estado muy similar. La única ventaja, es que hace una década y media, repartieron netbooks en las escuelas para los estudiantes que traía una distribución educativa de Linux y Windows 7, pero en el resto, el país entero depende de mucho software privativo pirata.

Wow, si había leído la noticia de que se desaconsejaba C/C++ pero nunca lo había relacionado así.

Recientemente estos últimos meses un equipo ha tratado de implementar Rust en el Kernel Linux, y creo que hoy se dieron por vencido debido a los viejos lobos de mar que defienden C/C++. De todas maneras, podrían ser grupos de desarrolladores pagados? Como lo que se teorizaba que JiaTan de XZ, era también un organización subsidiada por el gobierno de EU?

Interesante…

3 Me gusta

Entrar a valorar si hay conspiración o no en este caso ya me parece muy atrevido por mi parte, ya que me falta excesiva información para poder correlacionar en términos absolutos ambos hechos; si bien es curioso la cercanía en el calendario y la naturaleza del error…

Me ocurre lo mismo con el backdoor en SSH a través de xz/liblzma , si bien la complejidad del ataque me parece sobresaliente y digna de un gran intelecto, me parece sobremanera complicado establecer la bandera en un gobierno u organización. Eso sí, he leído por ahí un dato que me ha parecido divertido, siendo que el nombre del usuario JiaT75 aparecía como Jia Cheong Tan. El usuario, con mucho tiempo libre, se puso a organizar anagramas de esa frase, obteniendo que sería un anagrama perfecto de…

JIA CHEONG TAN
CIA JHEONG TAN
CIA JHON EGTAN
CIA JOHN AGENT
CIA AGENT JOHN

Siendo que John es un nombre ampliamente utilizado como genérico en EEUU. No me he parado a validar que toda la información sea real, pero desde luego es un planteamiento interesante, o al menos divertido.

3 Me gusta

Me gusta teorizar jeje.

Como dices, es al menos divertido…

1 me gusta

Para mi que se precipitan en las conclusiones. Por mucho que se se cambie de lenguaje de programación si no se sigue unas buenas prácticas seguirán habiendo fallos. La recomendación decía sustituir c por JavaScript y otros. No parece que estén muy informados.

Tampoco es cuestión de estar inventando la rueda. El uso de unos lenguajes u otros debería dejarse en manos de los que programan y no de expertos que parecen no tenerlo muy claro.

1 me gusta

Lo de C es porque lenguajes como Rust hacen un a gestión mas eficiente de la memoria y no tienen fallos a ese nivel y también son mas seguros a ese nivel según lo que he oído por eso descansojan en C en derretimiento de estos lenguajes ya que permitirán crear programas mas rapidos

Llevar el debate a lenguajes de programación buenos y lenguajes de programación malos no sirve para nada.

Para empezar se presenta un dilema maniqueo: bueno o malo. Falta un detalle muy importante y es: bueno o malo para programar qué.

¿Qué lenguaje de programación es **bueno ** y cuál malo: Bash o C? Pues depende de que quieras programar, el tiempo que quieras dedicarle al desarrollo,etc.

Con los dos puedo programar un programa para acceder a una base de datos o para realizar notificaciones en el escritorio.

Para notificaciones parece mejor usar Bash y C para acceso a base de datos, a parte de que en C puedes usar librerías que facilitan el trabajo.

Pero si tu prioridad es mejorar tu nivel de uso en Bash, programar un script para acceder a una base de datos es un buen problema al que enfrentarte para mejorar.

La entrada del blog que analiza el problema de CrowStrike no relaciona el fallo con el uso de lenguaje de programación malo.

What Code Issues Caused the CrowdStrike Outage?

La entrada aclara que que nadie sabe cuál ha sido el problema ya que no se ha publicado el código :

While the affected source code is not published, this blog post summarizes what CrowdStrike has publicly confirmed and examines code-level problems that could have led to this global outage.

Por tanto, la entrada del post se va ha centrar en cuál pudo ser el fallo y lo importante que es detectarlos en la fase de desarrollo:

Our goal is to shed light on what type of bugs can lead to such serious software reliability issues in general and why catching code issues early in the development process is as important as catching security vulnerabilities.

Sigue explicando que el fallo pudo ser por:

  • un puntero a NULL.
  • Una variable no inicializada
  • Un acceso a memoria más allá del límite asignado.

La conclusión a la que llega es que los fallos (Bugs) son inevitables y nadie se libra. Que incluso el código más pequeño puede ser crítico ( un driver). Y por último y creo que es la clave de todo, se pone mucha atención a la seguridad del software y del código (tengo mis dudas en el caso del código) y se descuida la fiabilidad y mantenimiento:

A lot of attention is paid to software and code security, but reliability and maintainability issues are often neglected.

La mayoría de los sistemas operativos y una gran parte del software están escritos en C y en C++. Windows y *nix están escritos en C/C++ y no tienen los mismos problemas de seguridad. La diferencia está en los filosofía al programar: p.e. Código que haga una sola tarea es más corto y por tanto más fácil de mantener. Un ejemplo son las normas POSIX.

3 Me gusta