@jack is back with a weekend project. Yes, that Jack. [Jack Dorsey] spent last weekend learning about Bluetooth meshing, and built Bitchat, a BLE mesh encrypted messaging application. It uses X25519 for key exchange, and AES-GCM for message encryption. [Alex Radocea] took a look at the current state of the project, suspects it was vibe coded, and points out a glaring problem with the cryptography.

So let’s take a quick look at the authentication and encryption layer of Bitchat. The whitepaper is useful, but still leaves out some of the important details, like how the identity key is tied to the encryption keys. The problem here is that it isn’t.

Bitchat has, by necessity, a trust-on-first-use authentication model. There is intentionally no authentication central authority to verify the keys of any given user, and the application hasn’t yet added an out-of-band authentication method, like scanning QR codes. Instead, it has a favorites system, where the user can mark a remote user as a favorite, and the app saves those keys forever. There isn’t necessarily anything wrong with this approach, especially if users understand the limitations.

The other quirk is that Bitchat uses ephemeral keys for each chat session, in an effort to have some forward secrecy. In modern protocols, it’s desirable to have some protection against a single compromised encryption key exposing all the messages in the chain. It appears that Bitchat accomplishes this by generating dedicated encryption keys for each new chat session. But those ephemeral keys aren’t properly verified. In fact, they aren’t verified by a user’s identity key at all!

The attack then, is to send a private message to another user, present the public key of whoever your’re trying to impersonate, and include new ephemeral encryption keys. Even if your target has this remote user marked as a favorite, the new encryption keys are trusted. So the victim thinks this is a conversation with a trusted person, and it’s actually a conversation with an attacker. Not great.

Now when you read the write-up, you’ll notice it ends with [Alex] opening an issue on the Bitchat GitHub repository, asking how to do security reports. The issue was closed without comment, and that’s about the end of the write-up. It is worth pointing out that the issue has been re-opened, and updated with some guidance on how to report flaws.

Post-Quantum Scanning

There’s a deadline coming. Depending on where you land on the quantum computing skepticism scale, it’s either the end of cryptography as we know it, or a pipe dream that’s always going to be about 10 years away. My suspicion happens to be that keeping qubits in sync is a hard problem in much the same way that factoring large numbers is a hard problem. But I don’t recommend basing your cryptography on that hunch.

Governments around the world are less skeptical of the quantum computer future, and have set specific deadlines to migrate away from quantum-vulnerable algorithms. The issue here is that finding all those uses of “vulnerable” algorithms is quite the challenge. TLS, SSH, and many more protocols support a wide range of cryptography schemes, and only a few are considered Post Quantum Cryptography (PQC).

Anvil Secure has seen this issue, and released an Open Source tool to help. Pqcscan is a simple idea: Scan a list of targets and collect their supported cryptography via an SSH and TLS scan. At the end, the tool generates a simple report of how many of the endpoints support PQC. This sort of compliance is usually no fun, but having some decent tools certainly helps.

Citrixbleed 2

Citrix devices have a problem. Again. The nickname for this particular issue is CitrixBleed 2, which hearkens all the way back to Heartbleed. The “bleed” here refers to an attack that leaks little bits of memory to attackers. We know that it’s related to an endpoint called doAuthentication.do.

The folks at Horizon3 have a bit more detail, and it’s a memory management issue, where structures are left pointing to arbitrary memory locations. The important thing is that an incomplete login message is received, the code leaks 127 bytes of memory at a time.

What makes this vulnerability particularly bad is that Citrix didn’t share any signs of attempted exploitation. Researchers have evidence of this vulnerability being used in the wild back to July 1st. That’s particularly a problem because the memory leak is capable of revealing session keys, allowing for further exploitation. Amazingly, in an email with Ars Technica, Citrix still refused to admit that the flaw was being used in the wild.

Opossum

We have a new TLS attack, and it’s a really interesting approach. The Opossum Attack is a Man in the Middle (MitM) attack that takes advantage of of opportunistic TLS. This TLS upgrade approach isn’t widely seen outside of something like email protocols, where the StartTLS command is used. The important point here is that these connections allow a connection to be initiated using the plaintext protocol, and then upgrade to a TLS protocol.

The Opossum attack happens when an attacker in a MitM position intercepts a new TCP connection bound for a TLS-only port. The attacker then initiates a plaintext connection to that remote resource, using the opportunistic port. The attacker can then issue the command to start a TLS upgrade, and like an old-time telephone operator, patch the victim through to the opportunistic port with the session already in progress.

The good news is that this attack doesn’t result in encryption compromise. The basic guarantees of TLS remain. The problem is that there is now a mismatch between exactly how the server and client expect the connection to behave. There is also some opportunity for the attacker to poison that connection before the TLS upgrade takes place.

TSAs

AMD has announced yet another new Transient Execution attack, the Transient Scheduler Attack. The AMD PDF has a bit of information about this new approach. The newly discovered leak primitive is the timing of CPU instructions, as instruction load timings may be affected by speculative execution.

The mitigation for this attack is similar to others. AMD recommends running the VERW instruction when transitioning between Kernel and user code. The information leakage is not between threads, and so far appears to be inaccessible from within a web browser, cutting down the real-world exploitability of this new speculative execution attack significantly.

Bits and Bytes

The majority of McDonald’s franchises uses the McHire platform for hiring employees, because of course it’s called “McHire”. This platform uses AI to help applicants work through the application process, but the issues found weren’t prompt injection or anything to do with AI. In this case, it was a simple default username and password 123456:123456 that gave access to a test instance of the platform. No real personal data, but plenty of clues to how the system worked: an accessible API used a simple incrementing ID, and no authentication to protect data. So step backwards through all 64 million applications, and all that entered data was available to peruse. Yikes! The test credentials were pulled less than two hours after disclosure, which is an impressive turn-around to fix.

When you’ve been hit by a ransomware attack, it may seem like the criminals on the other side are untouchable. But once again, international law enforcement have made arrests of high-profile ransomeware gangs. This time it’s members of Scattered Spider that were arrested in the UK.

And finally, the MCP protocol is once again making security news. As quickly as the world of AI is changing, it’s not terribly surprising that bugs and vulnerabilities are being discovered in this very new code. This time it’s mcp-remote, which can be coerced to run arbitrary code when connecting to a malicious MCP server. Connect to server, pop calc.exe. Done.

hackaday.com/2025/07/11/this-w…

[Sylvain Fortin] recently wrote in to tell us about his Homebrew CPU Project, and the story behind this one is truly remarkable.

He began working on this toy CPU back in 1994, over thirty years ago. After learning about the 74LS181 ALU in college he decided to build his own CPU. He made considerable progress back in the 90s and then shelved the project until the pandemic hit when he picked it back up again and started adding some new features. A little later on, a board house approached him with an offer to cover the production cost if he’d like to redo the wire-wrapped project on a PCB. The resulting KiCad files are in the GitHub repository for anyone who wants to play along at home.
An early prototype on breadboard
The ALU on [Sylvain]’s CPU is a 1-bit ALU which he describes as essentially a selectable gate: OR, XOR, AND, NOT. It requires more clock steps to compute something like an addition, but, he tells us, it’s much more challenging and interesting to manage at the microcode level. On his project page you will find various support software written in C#, such as an op-code assembler and a microcode assembler, among other things.

For debugging [Sylvain] started out with das blinkin LEDs but found them too limiting in short order. He was able to upgrade to a 136 channel Agilent 1670G Benchtop Logic Analyzer which he was fortunate to score for cheap on eBay. You can tell this thing is old from the floppy drive on the front panel but it is rocking 136 channels which is seriously OP.

The PCB version is a great improvement but we were interested in the initial wire-wrapped version too. We asked [Sylvain] for photos of the wire-wrapping and he obliged. There’s just something awesome about a wire-wrapped project, don’t you think? If you’re interested in wire-wrapping check out Wire Wrap 101.

hackaday.com/2025/07/11/this-h…

Secondo Trellix, il gruppo DoNot APT ha recentemente condotto una campagna di spionaggio informatico in più fasi, prendendo di mira il Ministero degli Affari Esteri italiano. Il gruppo, attribuito da diverse società di intelligence sulle minacce informatiche all’India, si è spacciato per funzionari della difesa europei, menzionando la loro visita in Bangladesh, e ha indotto le sue vittime a cliccare su un link dannoso di Google Drive.

DoNot APT, noto anche come APT-C-35, Mint Tempest, Origami Elephant, SECTOR02 e Viceroy Tiger, è attivo almeno dal 2016. Il gruppo si concentra tradizionalmente su campagne di spionaggio informatico con interessi geopolitici nell’Asia meridionale. Le sue operazioni sono caratterizzate da sorveglianza persistente, esfiltrazione di dati e accesso a lungo termine. Il gruppo è noto per l’utilizzo dimalware Windows personalizzati, tra cui backdoor come YTY e GEdit, spesso diffusi tramite e-mail di spear-phishing o documenti dannosi.

L’obiettivo finale dell’attacco era quello di stabilire un punto d’appoggio nell’infrastruttura del bersaglio e sottrarre informazioni sensibili. L’analisi del payload ha rivelato la sua associazione con il malware LoptikMod, uno strumento utilizzato esclusivamente dal gruppo APT DoNot dal 2018.

“Sebbene storicamente focalizzato sull’Asia meridionale, questo incidente che ha preso di mira le ambasciate dell’Asia meridionale in Europa indica una chiara espansione dei loro interessi verso le comunicazioni diplomatiche e l’intelligence europea”, hanno affermato i ricercatori di Tellix in un rapporto dell’8 luglio .
Catena di infezione (Fonte Trellix)
L’ultimo attacco DoNot APT identificato da Trellix è iniziato con un’email di spear-phishing proveniente da un indirizzo Gmail, int.dte.afd.1@gmail[.]com, che impersonava corrispondenza diplomatica ufficiale. Il bersaglio era un ente governativo italiano operante nel settore diplomatico. L’e-mail ha fatto leva su temi diplomatici legati al coordinamento degli addetti alla difesa tra Italia e Bangladesh.

Sebbene il contenuto esatto del messaggio non sia stato raccolto nei risultati, l’oggetto “Visita dell’addetto alla Difesa italiano a Dhaka, Bangladesh” suggerisce un’esca studiata per apparire come legittima corrispondenza diplomatica, che ragionevolmente conterrebbe allegati o link a documenti. L’e-mail conteneva un collegamento a Google Drive che indirizzava il destinatario a un archivio RAR dannoso denominato SyClrLtr.rar.

“Il recente attacco a un ministero degli esteri europeo evidenzia la portata crescente di DoNot APT e il suo persistente interesse nel raccogliere informazioni sensibili, sottolineando la necessità di una maggiore vigilanza e di solide misure di sicurezza informatica”, ha concluso il rapporto Trellix.

L'articolo Il Ministero degli Esteri italiano preso di mira in una campagna di spionaggio da Gruppo DoNot APT proviene da il blog della sicurezza informatica.

TapTrap sfrutta le animazioni dell’interfaccia utente per aggirare il sistema di autorizzazioni di Android, consentendo di accedere a dati sensibili o di indurre l’utente a compiere azioni distruttive, come il ripristino delle impostazioni di fabbrica del dispositivo. L’attacco TapTrap è un tipo di tapjacking, l’equivalente mobile del clickjacking. In questi attacchi, l’aggressore induce l’utente a cliccare su un elemento apparentemente innocuo, ma che in realtà causa un’azione indesiderata in background.

Tuttavia, a differenza del tapjacking tradizionale con overlay, TapTrap può essere utilizzato anche da app con zero permessi, consentendo loro di avviare attività trasparenti apparentemente innocue su quelle dannose. Inoltre, questo metodo funziona anche su Android 15 e 16.

TapTrap è stato sviluppato da un team dell’Università Tecnica di Vienna (TU Wien) e dell’Università di Bayreuth. La nuova tecnica sarà presentata il mese prossimo al Simposio sulla Sicurezza USENIX. Tuttavia, i ricercatori hanno già pubblicato un white paper che descrive l’attacco e creato un sito web che ne illustra i dettagli principali.

TapTrap sfrutta la gestione delle transizioni tra le attività da parte di Android mediante animazioni personalizzate per creare un’incoerenza visiva tra ciò che l’utente vede e ciò che accade realmente sullo schermo del dispositivo. Un’app dannosa installata sul dispositivo di destinazione avvia una schermata di sistema con informazioni sensibili (ad esempio una richiesta di autorizzazione o impostazioni di sistema) per conto di un’altra app chiamando startActivity() ed eseguendo un’animazione personalizzata con quasi totale trasparenza.

“La chiave di TapTrap è l’uso di animazioni che rendono l’attività target praticamente invisibile”, spiegano i ricercatori. “Questo risultato si ottiene tramite un’animazione personalizzata con i valori alfa iniziale e finale impostati su valori molto bassi, come 0,01. Questo rende l’attività dannosa o rischiosa quasi completamente trasparente. Inoltre, un’animazione zoom può essere utilizzata per ingrandire un elemento specifico dell’interfaccia (come un pulsante di autorizzazione) e visualizzarlo a schermo intero, aumentando la probabilità che l’utente lo tocchi.”

Sebbene il prompt avviato accetti tutti i tocchi, l’utente vede solo l’interfaccia principale dell’applicazione, sopra la quale si trova un’attività praticamente trasparente con la quale interagisce realmente. Credendo di avere a che fare con un’applicazione innocua, l’utente potrebbe cliccare su determinate aree dello schermo, senza rendersi conto che sta premendo pulsanti come “Consenti” o “Autorizza” in una finestra quasi invisibile.

Un video pubblicato dai ricercatori dimostra come un’app di gioco può utilizzare TapTrap per accedere alla telecamera tramite il browser Chrome per conto di un sito web. Per scoprire se TapTrap funzionasse con le app del Google Play Store, l’app store ufficiale di Android, i ricercatori hanno analizzato quasi 100.000 app. È emerso che il 76% di esse era vulnerabile perché conteneva attività che soddisfacevano le seguenti condizioni:

• possono essere avviati da un’altra applicazione;
• vengono eseguiti nello stesso task dell’applicazione chiamante;
• non sovrascrivere l’animazione di transizione;
• iniziare a rispondere alle azioni dell’utente prima che l’animazione sia completata.

Secondo i ricercatori, nell’ultima versione di Android le animazioni sono abilitate di default. A meno che l’utente non le disattivi tramite le impostazioni sviluppatore o le opzioni di accessibilità, il dispositivo rimane vulnerabile a TapTrap.

Sebbene l’attacco fosse stato inizialmente creato per Android 15 (la versione corrente all’epoca), in seguito, con il rilascio di Android 16, gli esperti hanno testato TapTrap anche su di esso. Il team ha quindi testato TapTrap su Google Pixel 8a con Android 16, e il problema si è riscontrato anche nell’ultima versione del sistema operativo. I rappresentanti di Google hanno dichiarato ai media che TapTrap verrà risolto in un futuro aggiornamento.

L'articolo Attacco TapTrap: come farti cliccare cose che nemmeno tua madre approverebbe proviene da il blog della sicurezza informatica.

We’re all used to crystal resonators — they provide pretty accurate frequency references for oscillators with low enough drift for most of our purposes. As the quartz equivalent of a tuning fork, they work by vibrating at their physical resonant frequency, which means that just like a tuning fork, it should be possible to listen to them.

A crystal in the MHz might be difficult to listen to, but for a 32,768 Hz watch crystal it’s possible with a standard microphone and sound card. [SimonArchipoff] has written a piece of software that graphs the frequency of a watch crystal oscillator, to enable small adjustments to be made for timekeeping.

Assuming a microphone and sound card that aren’t too awful, it should be easy enough to listen to the oscillation, so the challenge lies in keeping accurate time. The frequency is compared to the sound card clock which is by no means perfect, but the trick lies in using the operating system clock to calibrate that. This master clock can be measured against online NTP sources, and can thus become a known quantity.

We think of quartz clocks as pretty good, but he points out how little it takes to cause a significant drift over month-scale timings. if your quartz clock’s accuracy is important to you, perhaps you should give it a look. You might need it for your time reference.

Header: Multicherry, CC BY-SA 4.0.

hackaday.com/2025/07/11/listen…

La Generative AI, inclusi strumenti come Cursor e Claude Code, stanno abbattendo drasticamente i costi e i tempi dello sviluppo software. Quello che una volta richiedeva centinaia o migliaia di dollari per token ora può essere realizzato con poche decine di centesimi, determinando un ribaltamento delle dinamiche del settore.

Il paragone con il mondo dei media è illuminante: così come Internet e YouTube hanno infranto il modello della TV a pagamento, allo stesso modo l’AI sta modificando in profondità il panorama della programmazione. Se prima le aziende detenevano il monopolio sulle competenze e l’accesso al mercato, oggi la barriera di ingresso è crollata.

Nel mondo dei contenuti, la riduzione delle barriere ha favorito la nascita di milioni di nuovi creatori: da poche migliaia di canali a oltre 113 milioni su YouTube, con oltre 32 300 creator che hanno più di un milione di iscritti. Costare circa 25 000 $/per avviare un programma televisivo, rispetto ai 3 000 $ consumati per lanciare un canale di successo su YouTube, è un cambiamento radicale – e lo stesso vale per l’AI nel coding .

In ambito software, mentre prima scrivere migliaia di righe richiedeva budget importanti, ora bastano poche centinaia di dollari per generare milioni di righe grazie all’AI. Alcuni detrattori sostengono che qualità, adattamento al mercato e distribuzione rimangano fattori distintivi, ma l’articolo sostiene che questa visione è miope: se la produzione software diventa illimitata, quale valore potrà approdare da un unico fornitore?.

Le aziende tradizionali potrebbero dover affrontare margini in diminuzione: fino a oggi il software garantiva profitti del 90%, ma l’abbondanza di soluzioni generative renderà i margini sempre più sottili. In futuro, la competizione punterà su marketing e vendite, oltre che su integrazioni e servizi, ma sarà una “corsa al ribasso”, in cui solo chi si adatta sopravvivrà .

Infine, l’aspetto più filosofico: il software rischia di diventare un elemento secondario rispetto all’hardware. Se il codice diventa generabile all’infinito, a prevalere sarà la potenza computazionale, ossia i chip e l’infrastruttura.

In un futuro dominato dall’AI, il valore si sposterà verso dispositivi sempre più potenti, con software su misura già integrati, un po’ come avvenuto nelle prime grandi macchine informatiche .

Va da se che l’articolo, fa una riflessione di contesto che a molti non potrà piacere. L’introduzione massiccia dell’intelligenza artificiale nello sviluppo software sta infatti scardinando modelli consolidati e mettendo in crisi chi ha sempre fondato la propria competitività solo sulla manodopera o sulla rendita di posizione. Non si tratta solo di automatizzare righe di codice, ma di cambiare radicalmente il modo in cui progettiamo, testiamo e distribuiamo applicazioni, con un impatto diretto su prezzi, ruoli professionali e dinamiche di mercato.

Questa trasformazione, se da un lato spaventa per la velocità e la portata, dall’altro apre opportunità enormi per chi saprà adattarsi: più spazio per la creatività, più margine per sperimentare e una barriera d’ingresso più bassa per startup e innovatori proprio come è avvenuto nei media tradizionali.

L'articolo L’AI porrà fine all’industria del software tradizionale come Internet ha cambiato i media tradizionali proviene da il blog della sicurezza informatica.

Mentre il mondo corre verso l’adozione di nuovi modelli, reti segmentate e difese automatizzate, l’Italia resta ancorata a un passato fatto di server dimenticati, password su foglietti volanti e backup “fatti a mano”. Questo non è cyberpunk.

È la quotidianità, ma nessuno sembra nemmeno preoccuparsene. Benvenuti nel Paese dove i ransomware trovano più porte aperte che nei peggiori bar di Caracas. Comuni con sistemi gestionali del 2003, software proprietari che nessuno sa più aggiornare, enti locali che usano ancora Internet Explorer.

Dal 2021 abbiamo visto, infatti, una crescita di attacchi verso regioni, comuni e ospedali. La cosa peggiore è che molti attacchi non vengono nemmeno resi pubblici. I log non esistono. I responsabili IT sono spesso da soli, sottopagati e colpevolizzati. Le piccole e medie imprese italiane sono un bersaglio perfetto. Budget IT risicati, cultura della sicurezza assente, sistemi spesso gestiti da parenti e amici informatici improvvisati.

E così la sicurezza diventa folklore. In Italia, la cybersecurity è spesso trattata come una moda passeggera, buona per qualche convegno, un po’ di LinkedIn marketing e qualche “badge” su siti istituzionali. Ma sotto la superficie c’è il vuoto: procedure scritte male (quando ci sono), infrastrutture che nessuno osa toccare e sistemi affidati a società esterne che spariscono quando serve assistenza.

L’IT è visto come un costo, la sicurezza come un fastidio.

E chi prova a cambiare le cose si trova presto schiacciato tra burocrazia, scetticismo e mancanza di fondi. Non c’è bisogno di un APT russo per violare una rete comunale: basta una mail con allegato Excel e una macro scritta male. Il problema non è la potenza degli attaccanti. È la debolezza strutturale dei bersagli.

Chi è il responsabile di tutto questo? Nessuno, e quindi tutti.

I dirigenti che firmano capitolati con software senza manutenzione. I fornitori che installano firewall convenienti e poi spariscono. I politici che parlano di digitalizzazione senza sapere distinguere una VPN da una rete Wi-Fi. Ma anche noi tecnici, che troppo spesso ci rassegniamo al “così fan tutti”.

In altri Paesi si investe per rafforzare l’infrastruttura digitale come se fosse un asset critico nazionale. Da noi si spera solo che domani non succeda. Si spera che nessuno si accorga che quel NAS è esposto su internet. Che nessuno clicchi su quell’allegato. Che nessuno chieda log che non esistono.

Nel frattempo, tutto resta com’è. I bandi premiano l’offerta più economica, le competenze digitali sono affidate a chi ha fatto un corso da 30 ore, e gli attacchi aumentano. Ogni volta ci si sorprende.

Ogni volta si promette un audit, una commissione, un’indagine interna. Poi si archivia. Si dimentica.

E nel frattempo, chi segnala vulnerabilità viene ignorato. O peggio, minacciato.

Non esiste sistema invulnerabile. Ma un sistema che ignora le sue vulnerabilità è già compromesso.

Ma qualcosa può ancora cambiare.

La speranza ha un volto giovane. Sono gli studenti delle scuole superiori che si appassionano a Linux più che alla console. Sono i ragazzi che smontano router vecchi per capire come funzionano. Sono le community che fanno formazione gratuita, che organizzano CTF, che diffondono cultura dove lo Stato è assente.

Serve investire su di loro.

Dargli spazio. Fiducia. Budget.

Non saranno perfetti, ma sono l’unico firewall culturale che ci è rimasto.

Se c’è un futuro per la cybersecurity italiana, passa dalle mani di chi oggi sta imparando, spesso da solo, spesso senza mezzi, a difendere un Paese che non sa ancora di dover essere protetto.

L'articolo Spaghetti Crime: perché l’Italia è il bersaglio perfetto per i criminali informatici. Ma abbiamo una speranza! proviene da il blog della sicurezza informatica.

È stata scoperta una vulnerabilità critica di tipo double free nel modulo pipapo set del sottosistema NFT del kernel Linux. Un aggressore senza privilegi può sfruttare questa vulnerabilità inviando un messaggio netlink appositamente predisposto, innescando un errore double-free con elevata stabilità. L’aggressore può sfruttare le tecniche diexploit del kernel per ottenere un’escalation locale dei privilegi.

La vulnerabilità risiede nella funzione nft_add_set_elem che si trova in net/netfilter/nf_tables_api.c, dove una variabile stack non inizializzata struct nft_set_elem elem diventa la fonte del difetto di sicurezza. Gli analisti di SSD hanno riportato che il problema si verifica quando l’opzione di configurazione CONFIG_INIT_STACK_ALL_ZERO è disabilitata, lasciando dati non inizializzati sullo stack che contaminano la chiave dell’elemento durante l’elaborazione.

Il percorso del codice vulnerabile elabora i dati NFTA_SET_ELEM_KEY forniti dall’utente, ma inizializza la memoria solo fino alla lunghezza della chiave (klen), lasciando il contenuto del buffer rimanente con dati dello stack non inizializzati. Questa memoria non inizializzata contiene in genere puntatori da precedenti chiamate di funzioni del kernel, che attivano la condizione di doppia liberazione quando il set pipapo tenta di rimuovere elementi.

Il processo di exploit prevede una sofisticata tecnica di heap exploitation che consente di bypassare KASLR e stabilire una primitiva di scrittura arbitraria. La vulnerabilità riguarda le versioni del kernel Linux dalla 5.6-rc1 alla 6.13-rc3 e richiede configurazioni specifiche del kernel, tra cui:

• CONFIG_INIT_STACK_ALL_ZERO=n
• CONFIG_NETFILTER=y
• CONFIG_NF_TABLES=y
• CONFIG_USER_NS=y

Questa vulnerabilità presenta rischi significativi per la sicurezza poiché fornisce una primitiva double-free affidabile che può essere sfruttata per l’escalation dei privilegi locali. L’attacco raggiunge un’elevata stabilità attraverso tecniche di forza bruta che identificano le lunghezze ottimali delle chiavi per attivare il bug su configurazioni specifiche del kernel.

Strategie di mitigazione efficaci includono l’abilitazione dell’opzione di compilazione del kernel CONFIG_INIT_STACK_ALL_ZERO, che inizializza le variabili locali a zero e impedisce la contaminazione dei dati non inizializzati. Inoltre, applicando la patch disponibile dal team di sviluppo di Netfilter si affronta la causa principale inizializzando correttamente la struttura elem.

L'articolo Vulnerabilità Critica nel Kernel Linux: Una nuova Escalation di Privilegi proviene da il blog della sicurezza informatica.