En los últimos años venimos observando cada vez más preocupación sobre qué tenemos ejecutándose en las máquinas por ahí, sobre todo por las diversas nubes y el deseo de estar seguros de que allá sigue estando lo que nosotros habíamos puesto.

En Personal Reflections On Immutable Linux

Immutable means “not subject or susceptible to change” according to Merriam-Webster, which is not 100% accurate in this context, but it’s close enough and the name is there so we’re stuck with it. Immutable distributions are subject to change, it’s just that how you change them is quite a bit different than bog-standard Linux.

Tiene un poco que ver, creo, también con la reproducibilidad y tener la tranquilidad de que nuestro entorno de ejecución será parecido al de pruebas.

Nos habla de algunos ejemplos, como MicroOS, OSTree, Silverblue Aurora…

Pero esa inmutabilidad no significa que no podamos instalar nuevos programas y la solución habitual es mediante contenedores (Flatpak, por ejemplo). A partir de ahí muestra cómo MacOS es un Unix inmutable, a través de su aislamiento de las carpetas del sistema en modo de solo lectura. Las actualizaciones vienen como snapshots que sustituyen esa parte del sistema completa.

And Cupertino has been moving towards this “immutable” thing for a long time, until Catalina finally sealed the system folders away completely on a read-only volume. Updates for MacOS also come as snapshots to replace that system volume– you could certainly call them “atomic”.

La pregunta que surge es si esto es aceptable para el escritorio y la respuesta es que, probablemente, para la mayoría sí. Lo demuestra macOS y sus usuarios satisfechos.

macOS has shown that very few desktop users will ever notice if they can access the system folders or not; they are most interested in having a stable, reproducible environment to work in.

Naturalmente, estas aproximaciones vienen con sus propios inconvenientes: el uso de contenedores supone mayor uso de recursos (memoria y disco, fundamentalmente).

There are downsides to this kind of system, of course, and it is important to recognize that. Some people really, really hate containerization because Flatpaks, and other similar options, use more memory, both on disk and in RAM.

También nos quita algunas cosas a las que estamos acostumbrados en los sistemas de tipo Linux como el control sobre lo que hay en nuestra máquina, o cambiando la perspectiva, la idea de ‘no tocar’, derivada de la inmutabilidad.

From an aesthetic perspective, it’s not as elegant as a traditional Linux environment, at least to some eyes, mine included. Those of us who switched to Linux because we wanted absolute control over our computers might not feel too great about the “do not touch” label implicitly scrawled across the system folders

Finalmente, nos habla de una solución que no es exactamente inmutable, pero que nos permite abordar el problema del control sobre lo que hay en nuestro sistema, como es Nix, ofreciéndonos muchas de las ventajas de la inmutabilidad pero sin renunciar a configurar nuestro sistema.

After seeing how well containerization can work on desktop, Nix looks extra appealing – it can do most of what this article talks about with the immutable distros, but without trusting configuration of any facet of the system to anyone else.

Cualquiera que haya jugado un rato con una IA sabe que pueden convertirse en algo adictivo: nos aligera las tareas repetitivas, nos ayuda a resolver algunos problemas técnicos sin necesidad de leerse unos cuantos foros para ver cuál es la buena…. casi siempre.

En Large Language Models (LLMs) Are Falling for Phishing Scams: What Happens When AI Gives You the Wrong URL? nos recordaban que las recomendaciones no siempre son correctas y para comprobarlo hicieron un experimento.

Preguntaban dónde conectarse a algunas plataformas conocidas y las respuestas eran erróneas; no solo eso, ni siquiera estaban conectadas con el sitio al que pretendíamos ir en un 34% de las ocaciones.

When Netcraft researchers asked a large language model where to log into various well-known platforms, the results were surprisingly dangerous. Of 131 hostnames provided in response to natural language queries for 50 brands, 34% of them were not controlled by the brands at all.

Esto era un problema relativo, porque en la mayoría de los casos (29%) eran dominios aparcados, no registrados o sin actividad y en un 5% de los casos eran negocios legítimos, pero incorrectos.

64 domains (66%) belonged to the correct brand. 28 domains (29%) were unregistered, parked, or had no active content. 5 domains (5%) belonged to unrelated but legitimate businesses.

Pero cualquiera que tenga interés por las cosas de las que solemos hablar aquí sabe cuál es el siguiente paso: alguien descubre estas direcciones, las registra, y solo le queda esperar a recolectar los frutos.

Worse, many of the unregistered domains could easily be claimed and weaponized by attackers. This opens the door to large-scale phishing campaigns that are indirectly endorsed by user-trusted AI tools.

¿A quién afecta esto? Fundamentalmente, los damnificados podrían ser los negocios y empresas más pequeñas (que, además, últimamente son los que tienen la web completamente abandonada echándose en los brazos de las redes sociales).

Sitios más pequeños tienen una menos probabilidad de estar incluidos en los conjuntos de datos de entrenamiento y, por lo tanto, son los que invitan a los LLMs a alucinar, inventándose algo que decir cuando no lo tienen en su información.

These smaller players are less likely to appear in LLM training data, meaning hallucinations are more likely.

Podría suceder lo mismo con asistentes de programación, si alguien consigue contaminar sus datos con APIs falsas, que el asistente incluirá en nuestro código sin demasiados problemas.

In another campaign, Netcraft uncovered a sophisticated effort to poison AI coding assistants. The threat actor created a fake API, SolanaApis, designed to impersonate a legitimate Solana blockchain interface. Developers who unknowingly included this API in their projects were, in reality, routing transactions directly to the attacker’s wallet. The malicious API was hosted on two hostnames: api.solanaapis[.]com and api.primeapis[.]com

Interesante.

No estoy muy seguro sobre en qué habrá terminado esto pero me parece interesante por varios motivos: Ubuntu disables Intel GPU security mitigations, promises 20% performance boost.

Por un lado, está claro que añadir controles de seguridad hace que el código sea más lento (en este caso parece que mucho), y más complejo (se añaden instrucciones para vigilar que no pasen cosas y estar seguros de que sucden las adecuadas).

En este caso, además, los controles de seguridad vienen de un fallo de diseño por la ejecución predictiva (Recordar “Meltdown” and “Spectre:” Every modern processor has unfixable security flaws).

Según Ubuntu, este sería un problema suficientemente bien manejado en el kernel y, por lo tanto, los controles que añadían serían innecesarios.

At this point, Spectre has been mitigated in the kernel, and a clear warning from the Compute Runtime build serves as a notification for those running modified kernels without those patches. For these reasons, we feel that Spectre mitigations in Compute Runtime no longer offer enough security impact to justify the current performance tradeoff.

La ganancia no es pequeña, como dice el titular: un 20% de mejora.

Más aún, parece que estos fallos no están siendo atacados porque el esfuerzo no compensa (aunque ya sabemos que todo depende del sistema y el nivel de la información que protege).

“Nobody bothers attacking these vulns because it takes a lot of engineering time to implement attacks against them to any useful level of rigor, and getting any interesting data back outside very targeted scenarios is very unlikely (plus it’s noisy due to the number of iterations you need to do on these types of side-channels),” independent researcher Graham Sutherland wrote on Mastodon. “The economics just don’t stack up for attackers, especially when there are so many lower-effort higher-reward attack approaches they can throw at stuff.”

Interesante.

En LastPass Dodges Deepfake Scam: CEO Impersonation Attempt Thwarted nos cuentan un caso de intento de engaño mediante deep-fakes para engañar a las personas adecuadas, haciéndose pasar por alguna persona de confianza.

En este caso se trataba de la empresa LastPass y un intento de engaño con mensajes de audio para hacerse pasar por el CEO de la empresa.

The incident, detailed in a blog post by LastPass, involved an audio deepfake impersonating CEO Karim Toubba attempting to contact the employee via WhatsApp.

Las señales de que algo no van bien están muchas veces claras; un ejemplo es el uso de sistemas de comunicación alternativos (o no habituales).

As for LastPass, the company commended the employee’s vigilance in recognizing the red flags of the situation. The unusual use of WhatsApp, a platform not commonly used for official communication within the company…

Tampoco es que esto sea lo más habitual (hacerlo bien tiene requisitos importantes) pero es, nos avisan, que es una amenaza creciente.

While deepfake scams targeting businesses are still relatively uncommon, the LastPass incident stresses the growing threat. The company’s decision to publicize the attempt serves as a valuable cautionary tale for other organizations, urging them to heighten awareness and implement preventative measures.

El panorama ha cambiado un poco en los últimos tiempos, y en Triaging security issues reported by third parties la queja era que recibían muchos avisos de seguridad, perdiendo mucho tiempo en verificarlos, aunque no siempre son tan importantes.

I have to spend several hours each week dealing with security issues reported by third parties. Most of these issues aren’t critical but it’s still a lot of work.

Tiene algo que ver con la irrupción de la IA (más facilidad para hacer análisis y encontrar fallos), pero también con que el software libre no termina de encontrar el camino para financiar a sus desarrolladores y ese trabajo termina siendo, muchas veces, pura voluntariosidad.

In the long run, putting such demands on OSS maintainers without compensating them is detrimental. I just stepped down as libxslt maintainer and it’s unlikely that this project will ever be maintained again. It’s even more unlikely with Google Project Zero, the best white-hat security researchers money can buy, breathing down the necks of volunteers.