Claudia

2026-07-07 12:34:07

Se domani dovesse entrare in vigore un solo protocollo. Quale scegliereste?

..e perché proprio IRC? 😎

Spcnet.it

2026-07-08 11:00:48

Bad Epoll (CVE-2026-46242): la race condition nel kernel Linux che regala root a chiunque

Una race condition di sei istruzioni che porta a root

Il 4 luglio 2026 è stata resa pubblica una nuova vulnerabilità di privilege escalation nel kernel Linux, battezzata Bad Epoll e catalogata come CVE-2026-46242. Il difetto permette a un utente locale non privilegiato di ottenere i permessi di root su qualsiasi sistema Linux con kernel 6.4 o successivo, incluse le distribuzioni server più diffuse e i dispositivi Android, dove epoll è un componente del kernel che non può essere disattivato senza rompere il funzionamento del sistema operativo e del browser.

Per chi gestisce infrastrutture Linux in produzione, questo è il tipo di bug che merita attenzione immediata: non richiede alcuna interazione dell’utente privilegiato, non richiede configurazioni particolari, e la finestra di race condition — appena sei istruzioni macchina — non è un ostacolo, perché l’exploit pubblicato la sfrutta con un’affidabilità di circa il 99%.

Cos’è epoll e dove si trova il bug

epoll è il meccanismo con cui il kernel Linux notifica in modo efficiente ai processi eventi di I/O su un gran numero di file descriptor, ed è alla base di praticamente ogni event loop moderno: da Nginx a Node.js, da systemd a Chrome. Proprio perché è così centrale, non è un modulo che si possa scaricare o disabilitare come contromisura temporanea.

Il ricercatore Jaeyoung Chung, dottorando al CompSec Lab della Seoul National University, ha individuato un use-after-free (UAF) nella funzione ep_remove(), quella che ripulisce un file descriptor epoll quando viene chiuso. In condizioni normali, ep_remove() azzera file->f_ep sotto file->f_lock, ma continua a utilizzare l’oggetto file all’interno della sezione critica durante le chiamate a hlist_del_rcu() e spin_unlock(). Se in quella finestra ristrettissima una chiamata concorrente a __fput() osserva un valore transitorio NULL, salta eventpoll_release_file() e procede direttamente a f_op->release, liberando una struttura eventpoll ancora in uso.

Il risultato è memoria del kernel corrotta. Poiché struct file è allocata con SLAB_TYPESAFE_BY_RCU, lo slot liberato può essere immediatamente riciclato da alloc_empty_file(), aprendo la strada a un cross-cache attack: l’attaccante fa in modo che il kernel richiami kmem_cache_free() sulla cache sbagliata, ottenendo il controllo su un oggetto di tipo diverso da quello originariamente allocato in quello slot.

La catena dell’exploit

L’exploit pubblicato da Chung costruisce quattro file descriptor epoll collegati tra loro, organizzati in due coppie: chiudendo una coppia si innesca ripetutamente la race condition, mentre l’altra coppia funge da “vittima”. In questo modo una scrittura UAF di soli 8 byte viene trasformata in un use-after-free completo su un oggetto file tramite cross-cache attack. Da lì, l’attaccante ottiene lettura arbitraria della memoria del kernel attraverso /proc/self/fdinfo e dirotta il flusso di esecuzione con una catena ROP (return-oriented programming) fino a ottenere una shell root.

# Schema semplificato della sequenza (pseudocodice concettuale)
fd1, fd2 = crea_coppia_epoll()   # coppia "trigger"
fd3, fd4 = crea_coppia_epoll()   # coppia "vittima"

thread_A: chiudi(fd1)   # innesca ep_remove() ripetutamente
thread_B: chiudi(fd3)   # __fput() concorrente osserva f_ep == NULL
# -> eventpoll_release_file() saltato
# -> free prematuro dell'oggetto eventpoll ancora referenziato
# -> alloc_empty_file() ricicla lo slot -> cross-cache attack

Va sottolineato che questo bug è raggiungibile anche dall’interno della sandbox del processo di rendering di Google Chrome, il che significa che un exploit lato browser potrebbe in teoria essere incatenato a Bad Epoll per ottenere l’esecuzione di codice completa a livello kernel, superando l’isolamento del sandbox.

Perché nemmeno un modello AI lo ha trovato

La storia di questo bug ha un risvolto interessante per chi segue l’evoluzione degli strumenti di analisi automatica del codice. Entrambe le vulnerabilità nascono da un singolo commit del 2023 nello stesso percorso di codice di epoll, lungo circa 2.500 righe. La prima, oggi tracciata come CVE-2026-43074, era stata individuata dal modello AI di Anthropic, Mythos, e già corretta all’inizio del 2026. Bad Epoll è la seconda falla, gemella della prima ma molto più difficile da individuare, che Mythos non aveva notato.

Chung stesso indica due possibili ragioni: la finestra temporale è talmente stretta da rendere difficile “visualizzare” la sequenza esatta degli eventi anche leggendo il codice con attenzione, e l’errore di memoria raramente attiva KASAN, il principale rilevatore di bug del kernel, lasciando pochissime tracce a runtime. È un promemoria utile: gli strumenti di code review basati su AI stanno diventando sempre più capaci di individuare race condition nel kernel, ma i bug di concorrenza restano difficili da scovare a ogni livello, per una macchina come per una persona.

Patch e mitigazioni per i sistemisti

Non esiste un workaround praticabile, perché disabilitare epoll non è un’opzione realistica su un sistema Linux moderno. La correzione definitiva è arrivata con il commit upstream a6dc643c6931, dopo che un primo tentativo di patch non aveva risolto completamente il problema — la correzione corretta è arrivata a circa due mesi dalla divulgazione iniziale.

Le azioni concrete da intraprendere:

• Verificare la versione del kernel in uso: sono interessati i kernel basati su 6.4 e successivi; i kernel 6.1 più datati (compresi alcuni dispositivi Android come il Pixel 8) non sono vulnerabili perché il bug è stato introdotto solo con la 6.4.
• Applicare l’aggiornamento del kernel non appena la propria distribuzione rilascia il backport della patch (Debian, Ubuntu, RHEL e derivate stanno seguendo il processo standard di backport della sicurezza).
• Su flotte Android/embedded, verificare i cicli di aggiornamento del vendor per il patch level di sicurezza corrispondente.
• Non fare affidamento su mitigazioni lato SELinux/AppArmor come sostituto della patch: riducono la superficie d’attacco ma non chiudono la race condition nel kernel.

Vale la pena ricordare che Bad Epoll si inserisce in una serie di bug di privilege escalation del kernel Linux usati storicamente anche per il root di Android, come Bad Binder, Bad IO_uring e Bad Spin. A differenza di altri bug recenti più deterministici (come Copy Fail o Dirty Frag), Bad Epoll appartiene alla categoria più “classica” delle race condition da vincere, nello stile di Dirty Cow del 2016: meno affidabile in teoria, ma qui resa quasi deterministica da un exploit ben costruito.

Conclusione

Per chi amministra server Linux, workstation di sviluppo o flotte Android aziendali, Bad Epoll è un chiaro caso da trattare con priorità alta: patch del kernel disponibile, nessuna mitigazione alternativa valida, e un exploit pubblico con affidabilità prossima al 100%. La lezione più ampia è che, nonostante i progressi degli strumenti di analisi automatica basati su AI nel trovare bug di concorrenza nel kernel, la revisione umana e soprattutto la prontezza nell’applicare le patch di sicurezza restano parte essenziale della gestione del rischio su qualunque infrastruttura Linux.

Fonte: 4sysops.com, con approfondimenti da The Hacker News e Cyber Security News.

New "Bad Epoll" 0-Day Vulnerability Allows Root Access on Linux Servers and Android Devices

A newly disclosed Linux kernel flaw dubbed "Bad Epoll" (CVE-2026-46242) allows an unprivileged local user to escalate to root on Linux servers, desktops, and Android devices by exploiting a race condition and a use-after-free (UAF) in the kernel's ep…

^{Guru Baran (Cyber Security News)}

Spcnet.it

2026-07-08 11:01:11

systemd: guida completa a unit file, hardening e troubleshooting dei servizi Linux

Perché systemd è ancora il cuore di ogni server Linux moderno

Chiunque amministri sistemi Linux ha digitato decine di volte comandi come systemctl start o systemctl enable senza fermarsi troppo a pensare a cosa succede realmente sotto il cofano. systemd è l’init system presente sulla stragrande maggioranza delle distribuzioni Linux in produzione, e gli unit file sono il meccanismo con cui gli si dice cosa eseguire, quando eseguirlo e come comportarsi in caso di errore.

Conoscere a fondo la sintassi degli unit file e le tecniche di troubleshooting non è un esercizio accademico: è ciò che fa la differenza tra risolvere un servizio bloccato in due minuti o passare mezza giornata a indovinare. Vediamo come scrivere service unit robusti, quali opzioni contano davvero e come diagnosticare i fallimenti più comuni.

Anatomia di un service unit file

Un unit file è un file di configurazione testuale che descrive una risorsa gestita da systemd: servizi (.service), timer (.timer), socket (.socket), mount point (.mount) e altro ancora. In questo articolo ci concentriamo sui service unit, che sono quelli con cui la maggior parte dei sistemisti ha a che fare quotidianamente.

Prima regola pratica: sapere dove vivono i file.

• /lib/systemd/system/ o /usr/lib/systemd/system/ — unit forniti dai pacchetti di sistema, da non modificare mai direttamente
• /etc/systemd/system/ — dove lavori tu: unit personalizzati e override
• /run/systemd/system/ — unit runtime, spariscono al reboot

I file in /etc/systemd/system/ hanno precedenza su quelli in /lib/systemd/system/: è così che funzionano gli override.

Un service unit tipico si compone di tre sezioni: [Unit], [Service] e [Install]. Ecco un esempio minimo ma realistico per un’app Python:

[Unit]
Description=My Python Web App
After=network.target

[Service]
Type=simple
User=webapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/venv/bin/python app.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

La sezione [Unit]: ordinamento, non dipendenza

After=network.target indica solo l’ordine di avvio, non una vera dipendenza: il servizio parte dopo che la rete di base è stata configurata, ma non è garantito che un’interfaccia sia effettivamente raggiungibile. Per servizi che devono fare connessioni in uscita all’avvio (database, agenti di sincronizzazione, chiamate verso internet) è preferibile usare network-online.target:

[Unit]
After=network-online.target
Wants=network-online.target

Attenzione: questo funziona solo se sul sistema è abilitato un servizio “wait”, come systemd-networkd-wait-online o NetworkManager-wait-online, cosa non garantita su tutte le distribuzioni. Verificalo con:

systemctl is-enabled NetworkManager-wait-online.service

Vale la pena distinguere bene tra i tre operatori di dipendenza: Wants= è una dipendenza soft (se l’unit richiamata fallisce, il tuo servizio parte comunque), Requires= è una dipendenza hard (se fallisce, fallisce anche il tuo servizio), mentre After=/Before= riguardano solo l’ordine di avvio.

La sezione [Service]: dove si gioca la partita

Il parametro Type= descrive come si comporta il processo all’avvio, e sbagliarlo è una delle cause più comuni di servizi che sembrano non funzionare mai correttamente:

• Type=simple (default) — systemd considera il servizio avviato non appena parte il processo ExecStart. Va bene per processi in foreground.
• Type=forking — per demoni “vecchio stile” che fanno fork in background. systemd attende che il processo padre termini; serve quasi sempre PIDFile=.
• Type=notify — il processo notifica la propria disponibilità via sd_notify(). Più affidabile di simple per applicazioni complesse.
• Type=oneshot — per script che eseguono e terminano. Aggiungi RemainAfterExit=yes se vuoi che risulti “active” anche dopo l’uscita.
• Type=exec (systemd 240+) — simile a simple, ma systemd attende l’effettiva execve() del binario prima di considerare il servizio avviato, intercettando i casi in cui ExecStart non riesce nemmeno a partire.

Un dettaglio spesso sottovalutato riguarda i wrapper shell in ExecStart. Se usi:

ExecStart=/bin/bash -c 'echo started >> /var/log/myapp.log && /opt/myapp/start.sh'

ricorda che systemctl stop invia SIGTERM alla shell, non alla tua applicazione, rompendo potenzialmente lo shutdown pulito. Se proprio serve un wrapper, usa exec sul comando finale (exec /opt/myapp/start.sh) in modo che la shell passi il proprio PID al binario. Quando possibile, evita del tutto il wrapper e chiama il binario direttamente.

Sulla gestione dei riavvii automatici, Restart=on-failure è la scelta più sensata per la maggior parte dei servizi (riavvia su codici di uscita diversi da zero, segnali o timeout), mentre Restart=always va usato con cautela. RestartSec=5 aggiunge un ritardo prima del riavvio: senza, un servizio rotto martella il sistema in loop.

Override sicuri: mai toccare i file dei pacchetti

Non modificare mai i file in /lib/systemd/system/: gli aggiornamenti dei pacchetti sovrascrivono le modifiche. Il modo corretto è usare i drop-in override:

systemctl edit nginx

Questo comando apre un editor e crea automaticamente un file in /etc/systemd/system/nginx.service.d/override.conf, dove inserire solo le direttive da modificare:

[Service]
LimitNOFILE=65536
Restart=on-failure

Per vedere l’unit completo con gli override applicati: systemctl cat nginx. Dopo ogni modifica a un unit file, esegui sempre systemctl daemon-reload prima di riavviare il servizio: dimenticarlo è una fonte comune di confusione quando le modifiche non sembrano avere effetto.

Hardening: sandboxing gratuito integrato in systemd

systemd offre funzionalità di sandboxing native che riducono la superficie d’attacco in caso di compromissione del servizio. Da aggiungere nella sezione [Service]:

# Impedisce l'acquisizione di nuovi privilegi
NoNewPrivileges=yes

# /tmp privato e isolato
PrivateTmp=yes

# Accesso in sola lettura a /usr, /boot, /etc
ProtectSystem=strict

# Impedisce la scrittura nelle home directory
ProtectHome=yes

# Restringe le famiglie di indirizzi utilizzabili
RestrictAddressFamilies=AF_INET AF_INET6

# Limita le syscall a un set sicuro
SystemCallFilter=@system-service

Parti da PrivateTmp=yes e NoNewPrivileges=yes, che sono a costo pressoché zero. Aggiungi le altre opzioni con cautela, in particolare ProtectSystem=strict, che richiede che l’applicazione scriva solo in /var, /tmp o percorsi esplicitamente consentiti tramite ReadWritePaths=. Per servizi esposti su internet, questo è un investimento minimo con un ritorno di sicurezza notevole.

systemd timer: un sostituto moderno di cron

I timer di systemd sono un’alternativa spesso sottovalutata a cron, con logging integrato, gestione delle dipendenze ed esecuzione “catch-up” se il sistema era spento all’orario previsto. Servono due file: il timer e il service corrispondente.

/etc/systemd/system/backup.service:

[Unit]
Description=Nightly Backup

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/backup.sh

/etc/systemd/system/backup.timer:

[Unit]
Description=Run backup nightly at 2am

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true fa sì che, se il sistema era spento alle 2:00, il job venga eseguito al successivo avvio: qualcosa che cron non fa senza configurazioni aggiuntive. Si abilita e avvia il timer, non il service:

systemctl enable --now backup.timer
systemctl list-timers

Troubleshooting sistematico dei servizi falliti

Quando un servizio fallisce, conviene seguire un percorso ripetibile invece di procedere per tentativi.

1. Controlla lo stato

systemctl status myapp

Mostra stato corrente, ultime righe di log e PID. Un servizio fallito appare tipicamente così:

● myapp.service - My Python Web App
     Loaded: loaded (/etc/systemd/system/myapp.service; enabled)
     Active: failed (Result: exit-code) since Tue 2026-05-05 14:22:01 UTC
    Process: 1234 ExecStart=/opt/myapp/venv/bin/python app.py (code=exited, status=203/EXEC)

status=203/EXEC indica che il binario non poteva essere eseguito: quasi sempre un problema di percorso o permessi.

2. Leggi il journal

journalctl -u myapp -n 50      # ultime 50 righe
journalctl -u myapp -f         # segui in tempo reale
journalctl -u myapp -b         # dall'ultimo boot
journalctl -u myapp -b -1      # dal boot precedente

3. Verifica errori di sintassi

systemd-analyze verify /etc/systemd/system/myapp.service

Intercetta typo, direttive sconosciute e dipendenze mancanti prima ancora di tentare l’avvio.

4. Testa manualmente ExecStart

sudo -u webapp /opt/myapp/venv/bin/python app.py

Se fallisce qui, il problema è nell’applicazione o nel suo ambiente, non in systemd.

Pattern di errore comuni

• status=203/EXEC: binario non trovato o non eseguibile
• status=217/USER: l’utente specificato in User= non esiste
• status=200/CHDIR: WorkingDirectory non esiste o non è accessibile
• Start request repeated too quickly: crash-loop; aggiungi RestartSec= e resetta il contatore con systemctl reset-failed myapp
• Timeout on start: il servizio non ha segnalato la propria disponibilità in tempo; verifica se Type= è corretto (un demone che fa fork con Type=simple va cambiato in Type=forking)

Un esempio production-ready

Ecco un unit file completo per un’API Node.js che riassume le best practice viste finora:

[Unit]
Description=Node.js API Server
Documentation=https://github.com/example/myapi
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=nodeapp
Group=nodeapp
WorkingDirectory=/opt/myapi
ExecStart=/usr/bin/node /opt/myapi/server.js
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=10
StartLimitBurst=3
StartLimitIntervalSec=60
EnvironmentFile=/etc/myapi/env
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapi

# Hardening
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ReadWritePaths=/var/lib/myapi /var/log/myapi

[Install]
WantedBy=multi-user.target

StartLimitBurst=3 e StartLimitIntervalSec=60 insieme significano: se il servizio si riavvia più di 3 volte in 60 secondi, systemd smette di riprovare, evitando che un servizio rotto continui a “sbattere” contro il sistema.

Comandi rapidi da tenere a portata di mano

# Start, stop, restart, reload
systemctl start myapp
systemctl stop myapp
systemctl restart myapp
systemctl reload myapp

# Abilitazione al boot
systemctl enable myapp
systemctl disable myapp

# Unit completo con override applicati
systemctl cat myapp

# Servizi falliti
systemctl --failed

# Performance di boot
systemd-analyze blame
systemd-analyze critical-chain

Conclusione

Scrivere un service unit non è complicato una volta capito cosa fa ciascuna sezione: [Unit] gestisce ordinamento e dipendenze, [Service] definisce come il processo gira e si riprende dai fallimenti, [Install] controlla il comportamento al boot. Le opzioni di hardening richiedono pochi minuti in più ma vanno inserite di default su ogni servizio esposto in rete. E se ancora lanci job da cron, vale la pena provare un timer systemd: l’integrazione con il journal da sola giustifica il passaggio.

Fonte: LinuxBlog.io – systemd Services: Writing, Managing, and Troubleshooting Unit Files on Linux

systemd Services: Writing, Managing, and Troubleshooting Unit Files on Linux | LinuxBlog.io

Learn how to write, manage, and troubleshoot systemd service unit files on Linux. From basic service definitions to hardening options, restart policies, timers, and real-world debugging techniques.

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-07-08 11:00:43

OpenSSH 10.4: otto fix di sicurezza e il debutto della firma post-quantum ML-DSA+Ed25519

Perché ogni release di OpenSSH merita attenzione

OpenSSH non è un pacchetto qualunque nell’inventario di un sistemista: è il canale attraverso cui la stragrande maggioranza degli accessi remoti a server Linux e Unix passa ogni giorno, dai deployment automatizzati alle sessioni interattive degli amministratori. Quando il progetto rilascia una nuova versione con otto correzioni di sicurezza, non è il tipo di changelog da archiviare “per dopo”: va letto, capito e pianificato subito, anche se nessuna delle falle risulta sfruttata attivamente al momento del rilascio.

Il 6 luglio 2026 è uscita OpenSSH 10.4, e oltre alle correzioni porta con sé la prima implementazione sperimentale di una firma post-quantum ibrida e un cambiamento strutturale nel motore che interpreta i pattern con wildcard. Vediamo cosa cambia davvero per chi gestisce infrastrutture in produzione.

Le correzioni di sicurezza che contano di più

Due delle otto falle sono state individuate dallo Swival Security Scanner e riguardano il trasferimento file:

• sftp: un server malevolo poteva dirottare un download avviato da riga di comando (ad esempio sftp host:/percorso .) verso una destinazione diversa da quella attesa sul client.
• scp: durante le copie tra due host remoti, un server compromesso poteva scrivere file nella directory padre di quella di destinazione, uscendo dal perimetro previsto.

Sul lato server (sshd) sono stati corretti altri problemi rilevanti:

• l’implementazione internal-sftp troncava silenziosamente gli argomenti oltre il nono su righe di comando lunghe, con il rischio concreto di perdere un’opzione di sicurezza posizionata più avanti nella riga;
• DisableForwarding=yes non disattivava correttamente il tunneling quando combinato con PermitTunnel=yes, una regressione ora risolta per allinearsi al comportamento documentato;
• è stata chiusa una denial of service pre-autenticazione legata a GSSAPIAuthentication (funzione disattivata di default, ma diffusa in ambienti Active Directory);
• il ritardo minimo di autenticazione — la misura che rallenta i tentativi ripetuti di indovinare una password — in alcuni casi non veniva applicato: ora viene sempre imposto.

Sul client, ssh aveva un bug use-after-free innescabile quando un server cambiava la propria host key durante un re-exchange delle chiavi. Non è uno scenario comune, ma è esattamente il tipo di corner case che un attaccante con un server sotto il proprio controllo può orchestrare deliberatamente.

Checklist di aggiornamento pratica

1. Verifica la versione attuale con ssh -V e sshd -V su tutti i nodi.
2. Prima di riavviare il servizio, testa la nuova configurazione con sudo sshd -t.
3. Se hai script che analizzano l’output di sshd -T o sshd -G, verifica la sensibilità al maiuscolo/minuscolo (vedi sotto).
4. Pianifica la finestra di manutenzione su bastion host e jump server per primi, dato il loro ruolo critico.

La firma post-quantum sperimentale: ML-DSA-44 + Ed25519

La novità più discussa di questa release è il supporto sperimentale per uno schema di firma che combina ML-DSA-44 (l’algoritmo lattice-based standardizzato da NIST) con Ed25519, seguendo la bozza IETF draft-miller-sshm-mldsa44-ed25519-composite-sigs. Le due firme vengono unite in un’unica firma composita: per validare l’autenticazione entrambi gli algoritmi devono verificare correttamente, il che significa che un attaccante dovrebbe rompere sia la crittografia classica sia quella post-quantum per falsificare una chiave.

La funzione resta disattivata di default. Per provarla su un host di test:

# Generare una nuova coppia di chiavi ibride
ssh-keygen -t mldsa44-ed25519 -f ~/.ssh/id_mldsa44_ed25519

# Abilitare l'algoritmo lato client (~/.ssh/config)
Host bastion.esempio.it
    PubkeyAcceptedAlgorithms +mldsa44-ed25519

# Abilitare l'algoritmo per le host key lato server (sshd_config)
HostKeyAlgorithms +mldsa44-ed25519
HostKey /etc/ssh/ssh_host_mldsa44_ed25519_key

Va trattata per quello che è: una funzione sperimentale. Non ha senso migrare in blocco l’infrastruttura di produzione oggi, ma vale la pena aprire un ticket interno per iniziare a testarla su ambienti non critici, perché la transizione verso algoritmi resistenti al calcolo quantistico nell’SSH arriverà — la domanda è solo quando, non se.

Un motore di pattern matching più robusto

La seconda novità tecnica è meno appariscente ma importante lato hardening: il matcher dei pattern con wildcard (usato ad esempio in AllowUsers, Match e nelle liste di host) è stato riscritto attorno a un automa a stati finiti non deterministico (NFA). Il vecchio codice poteva incorrere in un tempo di esecuzione esponenziale su pattern costruiti ad arte, un problema simile ai classici attacchi ReDoS sulle espressioni regolari. Con il nuovo matcher questo caso patologico scompare.

Modifiche che possono rompere configurazioni esistenti

Tre cambiamenti meritano un controllo esplicito prima dell’upgrade:

• L’output di sshd -G ora stampa le direttive in stile misto (es. PubkeyAuthentication) invece che tutto minuscolo: se hai script di parsing con grep case-sensitive, vanno aggiornati.
• Su Linux, se il sandbox seccomp non può essere attivato (o manca NO_NEW_PRIVS), l’avvio di sshd ora fallisce in modo fatale invece di degradare silenziosamente. Ambienti containerizzati con restrizioni sul syscall filtering (alcuni setup gVisor o kernel molto vecchi) vanno testati prima del rollout.
• Il layer di trasporto è diventato più severo: un peer che invia messaggi non pertinenti al key exchange durante un rekey post-autenticazione viene ora disconnesso, chiudendo un vettore di esaurimento memoria.

In sintesi

OpenSSH 10.4 è un aggiornamento da programmare a breve termine, non da rimandare: le correzioni su sftp/scp toccano un vettore di attacco realistico (server malevolo o compromesso), mentre il fix sul ritardo minimo di autenticazione rafforza la resistenza al brute-force. La firma post-quantum resta un esperimento da monitorare, ma è il segnale più chiaro finora che il mondo SSH si sta muovendo verso la crittografia resistente al quantum computing. Prima di eseguire il rollout su larga scala, testate configurazione, script di automazione e ambienti containerizzati: le tre modifiche “breaking” di questa release sono piccole ma possono bloccare un deployment automatizzato se non verificate in anticipo.

Fonte: Help Net Security – OpenSSH 10.4 arrives with security fixes and a post-quantum signature option

OpenSSH 10.4 arrives with security fixes and a post-quantum signature option - Help Net Security

OpenSSH 10.4 release delivers security fixes plus an experimental post-quantum signature option and stricter transport checks.

^{Anamarija Pogorelec (Help Net Security)}

Spcnet.it

2026-07-08 11:00:45

Soglie dinamiche per gli alert su log in Azure Monitor: come ridurre il rumore senza perdere le anomalie

Il problema delle soglie statiche negli alert

Chiunque gestisca alert su log query in Azure Monitor conosce il dilemma delle soglie statiche: se il valore è troppo basso, si ricevono notifiche continue per fluttuazioni normali (l’autoscaling di un cluster AKS, il traffico più alto del lunedì mattina, i picchi stagionali di un e-commerce); se è troppo alto, si rischia di non accorgersi di un’anomalia reale finché non è troppo tardi. Il risultato tipico è affaticamento da alert, team che silenziano le notifiche, e problemi che passano inosservati.

Azure Monitor affronta questo problema con le soglie dinamiche (dynamic thresholds) per gli alert su ricerca di log, ora in disponibilità generale e senza costi aggiuntivi rispetto alla normale tariffa degli alert su log query. Vale la pena approfondire come funzionano e come configurarle correttamente, perché il vantaggio pratico per chi gestisce infrastrutture Azure è notevole.

Come funzionano le soglie dinamiche

Le soglie dinamiche applicano algoritmi di machine learning ai risultati delle query di log per apprenderne il comportamento storico. Il sistema analizza i dati nel tempo e identifica pattern ricorrenti — la cosiddetta seasonality, ovvero le fluttuazioni prevedibili che si ripetono a intervalli regolari (orari, giornalieri, settimanali). Quando i risultati della query si discostano in modo significativo dal pattern appreso, l’alert scatta.

In pratica, quando si crea una regola di alert, le soglie dinamiche utilizzano inizialmente 10 giorni di dati storici per calcolare i pattern stagionali orari e giornalieri. Dopo tre settimane, il sistema ha raccolto abbastanza dati da identificare anche i pattern settimanali e aggiusta il modello di conseguenza. Le soglie continuano ad apprendere dai nuovi dati, migliorando l’accuratezza nel tempo.

Configurare un alert su log search con soglia dinamica

La configurazione parte dalla procedura standard per creare una regola di alert su ricerca di log nel portale Azure: si definisce la query, la misurazione e le dimensioni esattamente come si farebbe con una soglia statica. La differenza sta nella sezione Alert logic:

• Per Threshold, selezionare Dynamic invece di Static.
• Per Operator, scegliere tra tre opzioni: Greater than the upper threshold or lower than the lower threshold (l’opzione predefinita, che considera entrambe le direzioni), Greater than the upper threshold, oppure Lower than the lower threshold. Le soglie dinamiche calcolano sia un limite superiore sia uno inferiore, quindi si può scegliere quale tipo di deviazione deve far scattare l’alert.
• Per Threshold sensitivity, selezionare High, Medium (predefinito) o Low. La sensibilità alta imposta soglie strette vicine al pattern misurato e scatta anche per deviazioni minime; quella bassa tollera scostamenti maggiori e si attiva solo per anomalie evidenti.

Dopo aver configurato la condizione, il pulsante Preview Chart mostra i risultati storici della query insieme all’intervallo di soglia calcolato: una linea blu per i valori misurati, un’area viola per l’intervallo di soglia consentito, punti rossi per le violazioni della soglia e barre rosa per gli alert effettivamente scattati. Dopo ogni modifica alla condizione, è necessario selezionare Refresh Chart per aggiornare l’anteprima.

// Esempio di query KQL usata come base per un alert con soglia dinamica
// (conteggio dei riavvii dei pod in un cluster AKS)
KubePodInventory
| where TimeGenerated > ago(1h)
| summarize RestartCount = sum(PodRestartCount) by ClusterName, Namespace, Name

Suddividere l’alert per dimensioni

Una delle funzionalità più utili per chi gestisce ambienti multi-risorsa è la possibilità di suddividere la valutazione dell’alert per dimensioni, ovvero colonne dei risultati della query che contengono dati aggiuntivi come nomi di risorse, namespace o ID di sottoscrizione. Quando si usano le dimensioni, la regola di alert valuta separatamente ogni combinazione di dimensioni e genera un alert indipendente per ciascun gruppo che soddisfa la condizione. È possibile applicare fino a sei dimensioni per regola.

Un caso pratico: monitorare i riavvii dei pod in un cluster AKS suddividendo per Namespace e Name, in modo che ogni namespace e ogni pod ottenga una propria baseline di soglia dinamica. Questo evita che un singolo alert generico “spari” per l’intero cluster quando in realtà è un solo namespace ad avere un comportamento anomalo, e permette al modello di adattarsi a fluttuazioni normali dovute all’autoscaling.

Limiti da conoscere prima di usarle in produzione

Alcune limitazioni sono importanti da tenere a mente per non avere aspettative sbagliate:

• La frequenza minima di valutazione è di 5 minuti.
• Le regole non scattano prima di aver raccolto almeno 3 giorni e 30 campioni di dati: risorse nuove o con dati mancanti non genereranno alert finché non ci sono dati sufficienti.
• Servono almeno 3 settimane di dati storici per rilevare la stagionalità settimanale; pattern come cicli bi-orari o semi-settimanali potrebbero non essere rilevati affatto.
• Le soglie dinamiche sono pensate per rilevare deviazioni significative e improvvise, non problemi che si sviluppano lentamente: un degrado graduale delle prestazioni probabilmente non farà scattare l’alert.
• Non è possibile usare soglie dinamiche in regole che monitorano più condizioni contemporaneamente.
• La configurazione è possibile tramite portale Azure o template ARM; PowerShell e Azure CLI non sono ancora supportati per le regole di alert su log search con soglie dinamiche.
• Il grafico di anteprima ha limiti sull’intervallo temporale in base alla frequenza della regola: con frequenza di 5 minuti si vedono fino a 6 ore di dati, con frequenza di un’ora o superiore fino a 2 giorni.

Come ridurre il rumore (o aumentare la sensibilità)

Se una regola scatta troppo spesso, ci sono diverse leve da regolare prima di abbandonare l’approccio: abbassare la sensibilità della soglia a Low per tollerare deviazioni maggiori, aumentare la granularità di aggregazione (la finestra temporale usata per raggruppare i punti dati) per ridurre la sensibilità a picchi transitori, oppure configurare nelle impostazioni avanzate il numero di violazioni richieste in un determinato periodo prima che l’alert scatti effettivamente.

Al contrario, se una regola non è abbastanza sensibile nemmeno con sensibilità alta, è probabile che la distribuzione dei dati sia molto irregolare. In questi casi Microsoft consiglia di verificare se nei 10 giorni precedenti si è verificato un cambiamento drastico nel comportamento dei dati — per esempio un’interruzione di servizio — che può aver alterato il calcolo delle soglie. Un’altra opzione è monitorare una metrica complementare o modificare la granularità di aggregazione.

Due casi d’uso concreti

Microsoft evidenzia due scenari tipici. Il primo riguarda il monitoraggio dei riavvii dei pod Kubernetes tramite la tabella KubePodInventory, riassumendo i conteggi per cluster, namespace e nome del pod: le soglie dinamiche si adattano alle fluttuazioni normali causate dall’autoscaling e generano alert solo per anomalie reali. Il secondo riguarda il rilevamento di drift nell’inventario delle risorse tramite query di Azure Resource Graph: contando le risorse per tipo e ID sottoscrizione, le soglie dinamiche possono identificare picchi improvvisi nella creazione o cancellazione di risorse che potrebbero indicare deployment fuori controllo, adattandosi ai pattern stagionali di deployment che una soglia statica non riuscirebbe a gestire.

Conclusione

Le soglie dinamiche per gli alert su log search sono una delle funzionalità più concretamente utili di Azure Monitor per chi gestisce ambienti con carichi variabili nel tempo: riducono il rumore degli alert senza richiedere di indovinare manualmente una soglia statica per ogni metrica, e si adattano automaticamente quando cambia la scala dell’infrastruttura. Detto questo, non sono una bacchetta magica: richiedono tempo per costruire una baseline affidabile (fino a tre settimane per la stagionalità settimanale) e non sono adatte a rilevare degradi lenti e progressivi. Per la maggior parte degli scenari di monitoraggio di infrastrutture Azure dinamiche — cluster Kubernetes, ambienti con autoscaling, fleet di risorse in continua evoluzione — rappresentano comunque un netto miglioramento rispetto alle soglie statiche tradizionali.

Fonte: 4sysops.com, con riferimenti alla documentazione ufficiale Microsoft Learn.

Dynamic thresholds for log search alerts in Azure Monitor – 4sysops

Microsoft announced general availability of dynamic thresholds for log search alerts in Azure Monitor on June 16, 2026. This feature uses machine learning to le

^{IT Experts (4sysops)}

Spcnet.it

2026-07-08 11:00:51

Manifest V2 è morto in Chrome 150: guida pratica alla migrazione verso Manifest V3

Manifest V2 è ufficialmente morto: cosa cambia da Chrome 150

Con il rilascio di Chrome 150 (fine giugno 2026), Google ha chiuso anche l’ultimo varco rimasto aperto sul Manifest V2: il flag sperimentale che permetteva, a chi lo attivava manualmente, di continuare a eseguire estensioni legacy. Il percorso di deprecazione era iniziato molto prima — le prime disattivazioni erano comparse già nei canali pre-stable di Chrome 127 a metà 2024, la rimozione del criterio enterprise che consentiva alle aziende di rimandare il cambio era arrivata con Chrome 139, e da Chrome 138 il Manifest V2 risultava già disabilitato su tutti i canali per gli utenti privati. Chrome 150 chiude il cerchio: da qui in avanti, chi mantiene un’estensione in Manifest V2 non ha più alcuna via di fuga lato utente, solo il downgrade manuale a una versione precedente del browser, un’operazione sconsigliata perché rinuncia a tutte le patch di sicurezza successive.

Per chi sviluppa o mantiene estensioni Chrome — plugin aziendali, ad blocker interni, tool di produttività distribuiti via policy — il messaggio è netto: la riscrittura in Manifest V3 non è più rimandabile. Vediamo cosa cambia concretamente e come affrontare la migrazione senza sorprese.

Perché Google ha fatto questa scelta

Manifest V3 nasce da un problema reale: il modello di background page persistente di V2 teneva in memoria un intero processo per ogni estensione installata, con un impatto misurabile su RAM e batteria. Inoltre l’API webRequest, che permetteva alle estensioni di intercettare e modificare ogni richiesta di rete in tempo reale con codice arbitrario, è da anni uno dei vettori più sfruttati per iniettare codice malevolo o dirottare il traffico dell’utente. Sostituendola con un sistema dichiarativo, Chrome elimina una classe intera di vulnerabilità, al costo di una minore flessibilità per gli sviluppatori legittimi (è il motivo per cui alcuni ad blocker complessi, come le versioni più sofisticate di uBlock Origin, hanno dovuto ripensare parte della loro logica di filtro).

Le tre modifiche strutturali che servono per migrare

1. Da background page a service worker

In Manifest V2 il background script veniva dichiarato così:

{
  "manifest_version": 2,
  "background": {
    "scripts": ["background.js"],
    "persistent": true
  }
}

In Manifest V3 il campo diventa singolare e punta a un service worker, non più a un processo persistente:

{
  "manifest_version": 3,
  "background": {
    "service_worker": "background.js"
  }
}

La differenza non è solo sintattica. Un service worker viene terminato da Chrome dopo circa 30 secondi di inattività e riavviato al bisogno: qualsiasi variabile in memoria (contatori, cache, stato di sessione) viene persa a ogni ciclo. Il codice va quindi ristrutturato per:

• registrare tutti i listener di eventi (chrome.runtime.onMessage, chrome.alarms.onAlarm, ecc.) in modo sincrono, nella prima esecuzione dello script — se li registri dentro una callback asincrona rischi che il service worker si riattivi senza agganciare l’evento;
• spostare qualunque stato che deve sopravvivere ai riavvii su chrome.storage.local o chrome.storage.session, mai su variabili globali;
• sostituire i timer lunghi basati su setTimeout/setInterval con l’API chrome.alarms, l’unica garantita a sopravvivere alla terminazione del worker.

2. Da webRequest a declarativeNetRequest

Questo è il cambiamento che rompe più estensioni esistenti. In V2 potevi intercettare ogni richiesta e decidere via codice cosa farne:

chrome.webRequest.onBeforeRequest.addListener(
  (details) => ({ cancel: details.url.includes("ads") }),
  { urls: ["<all_urls>"] },
  ["blocking"]
);

In V3 questo pattern “blocking” non è più disponibile per le estensioni pubbliche: devi descrivere le regole in modo dichiarativo e lasciare che sia Chrome, non il tuo JavaScript, ad applicarle — un dettaglio che tra l’altro migliora anche le performance, perché elimina la latenza di andata e ritorno verso lo script:

{
  "permissions": ["declarativeNetRequest"],
  "declarative_net_request": {
    "rule_resources": [{
      "id": "ruleset_1",
      "enabled": true,
      "path": "rules.json"
    }]
  }
}

Con rules.json strutturato così:

[
  {
    "id": 1,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {
      "urlFilter": "||ads.example.com",
      "resourceTypes": ["script", "image", "xmlhttprequest"]
    }
  }
]

Se hai bisogno di generare regole a runtime (per esempio in base a una blocklist scaricata dinamicamente), puoi ancora farlo, ma tramite l’API dedicata invece che intercettando il traffico:

chrome.declarativeNetRequest.updateDynamicRules({
  addRules: [ /* nuove regole */ ],
  removeRuleIds: [1, 2, 3]
});

3. Content Security Policy più rigida

Manifest V3 vieta il caricamento di codice remoto e l’uso di eval() o di stringhe passate a setTimeout. Ogni script deve essere incluso nel pacchetto dell’estensione al momento della submission. Se la tua estensione scarica script da un CDN esterno per aggiornare la logica senza ripassare dallo store, quella pratica va eliminata: è esattamente il tipo di comportamento che V3 vuole rendere impossibile.

Un percorso di migrazione pragmatico

Per un’estensione di media complessità, un ordine di lavoro che funziona bene nella pratica:

1. Aggiorna manifest_version a 3 e correggi gli errori di validazione più ovvi (campi rinominati, permessi da dichiarare esplicitamente in host_permissions invece che in permissions).
2. Converti il background script in service worker e verifica con i DevTools dell’estensione (chrome://extensions → “Ispeziona service worker”) che i tuoi eventi vengano ricevuti anche dopo un riavvio forzato del worker.
3. Mappa ogni regola di webRequest blocking in una regola dichiarativa equivalente; per i casi che non si lasciano esprimere in modo dichiarativo (analisi del body della richiesta, per esempio) valuta se il caso d’uso può spostarsi lato server o va accettato come limite architetturale.
4. Testa il ciclo di vita del service worker esplicitamente, non solo la logica funzionale: è la causa più comune di bug “intermittenti” post-migrazione.

Cosa fare se dipendi da un’estensione ancora in V2

Se in azienda usate ancora plugin legacy indispensabili, l’unica strada supportata da Google è il downgrade manuale a Chrome 148 (l’ultima build con supporto V2 completo), disabilitando i servizi “Google Updater” e “Google Updater Internal” da Windows per bloccare l’aggiornamento automatico, e aggiungendo flag da riga di comando al collegamento per bypassare la logica di deprecazione. È un compromesso rischioso, perché rinuncia a tutte le patch di sicurezza rilasciate da quel momento in poi, e va considerato solo come misura temporanea mentre si pianifica la migrazione o la sostituzione dell’estensione. Alcuni browser basati su Chromium, come Firefox (che usa un motore diverso ma supporta ancora API equivalenti a webRequest) o Opera, hanno dichiarato l’intenzione di mantenere più a lungo il supporto a funzionalità simili a V2: per estensioni interne aziendali può essere un’alternativa da valutare, con le dovute cautele su compatibilità e manutenzione nel lungo periodo.

Fonte: 4sysops.com

Google Chrome terminates Manifest V2 support in version 150 – 4sysops

Google Chrome version 150 has officially removed support for Manifest V2 extensions, effectively disabling older ad blockers and tools. While initial expectatio

^{IT News (4sysops)}

Spcnet.it

2026-07-08 11:00:39

Sette vulnerabilità in FatFs mettono a rischio milioni di dispositivi IoT ed embedded

Sette nuove vulnerabilità in FatFs, la libreria FAT/exFAT più diffusa nel mondo embedded, mettono a rischio milioni di dispositivi IoT, controllori industriali, drone, telecamere di sicurezza e persino hardware wallet. A scoprirle è stato il team di ricerca runZero, che ha rispolverato un audit di sicurezza del 2017 usando un approccio decisamente più moderno: Visual Studio Code e GitHub Copilot in modalità “auto”, con prompt semplici e nessun tooling custom. Il risultato è stato sorprendente: bug che il fuzzing manuale non aveva mai individuato sono emersi con relativa facilità.

Per chi lavora su sistemi embedded, firmware o dispositivi IoT, questa vicenda merita attenzione non solo per i dettagli tecnici delle CVE, ma anche per quello che rivela sulla fragilità della supply chain del software embedded.

Cos’è FatFs e perché è ovunque

FatFs è una libreria open source compatta, scritta in C, che permette a dispositivi con risorse limitate di leggere e scrivere volumi formattati FAT e exFAT — gli stessi filesystem usati da chiavette USB e schede SD. Proprio per la sua leggerezza è stata integrata, spesso tramite vendoring (copia diretta del codice sorgente nel proprio progetto), in un numero enorme di piattaforme embedded:

• Espressif ESP-IDF
• STMicroelectronics STM32Cube
• Zephyr RTOS
• MicroPython
• ArduPilot
• RT-Thread
• Mbed
• Samsung TizenRT
• SWUpdate

A valle di questi framework troviamo dispositivi IoT di consumo, controllori industriali, drone, hardware crypto wallet, telecamere con slot SD, chioschi pubblici, ATM e persino macchine per il voto elettronico con lettori USB. La maggior parte di questi dispositivi non dispone delle protezioni di memoria che diamo per scontate su desktop e smartphone, a partire dall’ASLR (Address Space Layout Randomization).

Le sette vulnerabilità

Tutte le CVE condividono lo stesso schema di innesco: il dispositivo legge un volume di storage o un’immagine firmware malformata, FatFs gestisce male i dati corrotti, e da lì partono corruzioni di memoria, crash o fughe di informazioni. Due delle sette CVE, la 6682 e la 6683, sono implicate anche nei processi di aggiornamento firmware over-the-air, il che estende la superficie di attacco ben oltre il semplice accesso fisico al dispositivo.

Le tre vulnerabilità più severe (CVSS 7.6, High)

CVE-2026-6682 - Integer overflow in mount_volume() (FAT32)
Un overflow intero può produrre metadati di dimensione file
controllati dall'attaccante. Se questo valore viene usato come
lunghezza di lettura da codice a valle, si arriva a corruzione
di heap/stack e potenziale esecuzione di codice arbitrario.

CVE-2026-6687 - Stack overflow in f_getlabel() (exFAT)
La gestione della label exFAT non limita correttamente la
lunghezza del campo, permettendo scritture oversize nel buffer
della label. Corruzione di memoria diretta nel firmware.

CVE-2026-6688 - Overflow nei filename lunghi
Quando fno.fname supera le dimensioni del buffer fisso nel
codice chiamante, il problema si manifesta tipicamente in
wrapper che usano strcpy o sprintf senza controlli di bound.

Le quattro vulnerabilità di severità media (CVSS 4.6–6.1)

CVE-2026-6685 (CVSS 6.1) - Wraparound in sottrazione unsigned
nella gestione della dirty-cache su volumi frammentati: può
corrompere memoria o causare corruzione silente dei dati,
particolarmente pericolosa in sistemi di logging e controllo.

CVE-2026-6683 (CVSS 4.6) - Divide-by-zero in exFAT nei percorsi
di sync/write, innescabile con media malformati: crash affidabili
e possibile "brick" del dispositivo durante update firmware.

CVE-2026-6686 (CVSS 4.6) - Esposizione di cluster non
inizializzati quando si estende un file oltre EOF: può rivelare
dati residui di file precedentemente cancellati (data leak).

CVE-2026-6684 (CVSS 4.6) - Loop di scansione GPT nelle versioni
precedenti a R0.16: può causare scansioni illimitate e denial
of service al boot. Corretta in R0.16, ma resta presente in
gran parte dei deployment embedded esistenti.

Il vero problema: chi la corregge?

FatFs è mantenuta da un solo sviluppatore. runZero ha tentato ripetutamente di contattarlo e ha coinvolto JPCERT/CC nel processo di coordinamento, senza ottenere risposta. Il risultato è che, delle sette CVE, solo quella relativa alla scansione GPT (CVE-2026-6684) ha una patch upstream disponibile, nella versione R0.16.

Ma anche questa correzione non risolve automaticamente nulla: praticamente tutti i produttori che integrano FatFs lavorano su copie vendorizzate e modificate localmente. Ogni patch upstream deve quindi essere validata con cura prima di essere incorporata nel proprio codice, un processo che — come insegna il precedente di PixieFail (le nove vulnerabilità in EDK II divulgate nel 2024) — può richiedere anni, non settimane.

Cosa fare se sviluppi o gestisci dispositivi con FatFs

Se sei tra chi costruisce firmware che interagisce con storage FAT o exFAT, le priorità immediate sono chiare:

• Individua la copia vendorizzata di FatFs nel tuo codice e verificane la versione
• Fai il audit del wrapper code che circonda le chiamate a FatFs, in particolare come vengono gestiti nomi file e dimensioni
• Presta particolare attenzione a qualsiasi punto in cui fno.fname viene copiato in un buffer di dimensione fissa
• Pianifica la validazione e il rilascio di patch per la tua base di codice specifica

Se invece gestisci dispositivi che integrano FatFs senza averli sviluppati (telecamere, NAS embedded, sistemi industriali), tratta le porte fisiche e i canali di aggiornamento firmware come superficie di attacco: limita chi può inserire fisicamente supporti removibili, monitora gli advisory di sicurezza dei vendor e applica gli aggiornamenti firmware non appena disponibili.

runZero ha pubblicato immagini disco proof-of-concept, un test harness e una dimostrazione di exploit basata su QEMU in un repository di accompagnamento. Alla data di divulgazione (1 luglio 2026) non risultavano attacchi noti che sfruttassero attivamente queste vulnerabilità — ma la disponibilità pubblica di PoC e tooling di fuzzing basato su AI riduce drasticamente il tempo necessario perché qualcuno le sfrutti.

Conclusione

Il caso FatFs è un promemoria di quanto sia fragile la catena di fornitura del software embedded: componenti piccoli, utili e copiati ovunque, che diventano difficili da correggere proprio per la loro diffusione capillare e la mancanza di un processo di manutenzione strutturato. È anche un caso di studio interessante sull’uso di strumenti AI-assisted (Copilot in modalità agente) per il security auditing: un processo che nel 2017 richiedeva settimane di fuzzing manuale, nel 2026 è stato in parte automatizzato con risultati migliori. Per i team che gestiscono flotte di dispositivi embedded, il messaggio pratico è di trattare ogni libreria di terze parti vendorizzata come debito tecnico da monitorare attivamente, non come un componente “impostato e dimenticato”.

Fonte: Security Affairs e 4sysops, basato sulla ricerca originale di runZero.

Seven FatFs bugs, one very large blast radius

One small component, massive blast radius. Explore seven new FatFs vulnerabilities discovered via AI that impact RTOS platforms, IoT devices, and firmware.

^{todb (runZero)}