Spcnet.it

2026-04-20 11:58:16

Rust 1.95.0: cfg_select!, if-let guard nei match e nuove API per Vec e atomici

Il 16 aprile 2026 è uscita Rust 1.95.0, una release che porta novità significative al linguaggio e alla sua libreria standard. Questa versione si segnala in particolare per l’introduzione della macro cfg_select!, il supporto agli if-let guard nei blocchi match, e una serie di nuove API per la gestione della memoria e degli atomici.

Vediamo nel dettaglio cosa cambia e come queste novità influenzano il codice quotidiano dei Rustaceans.

cfg_select!: condizionali di compilazione senza dipendenze esterne

La macro cfg_select! introduce un modo più espressivo per scrivere codice condizionale basato sulla configurazione di compilazione. Si comporta come un match valutato a compile-time sulle condizioni cfg, rimpiazzando di fatto il crate esterno cfg-if che molti progetti Rust usano da anni.

Prima di Rust 1.95, per scrivere codice dipendente dalla piattaforma si usava tipicamente:

// Prima: con cfg-if (dipendenza esterna nel Cargo.toml)
cfg_if::cfg_if! {
    if #[cfg(target_os = "linux")] {
        fn get_system_info() -> String {
            linux_system_info()
        }
    } else if #[cfg(target_os = "macos")] {
        fn get_system_info() -> String {
            macos_system_info()
        }
    } else {
        fn get_system_info() -> String {
            String::from("unknown")
        }
    }
}

Con cfg_select!, la stessa logica si esprime ora senza aggiungere dipendenze al progetto:

// Ora: built-in nella libreria standard
fn get_system_info() -> String {
    cfg_select! {
        target_os = "linux" => { linux_system_info() }
        target_os = "macos" => { macos_system_info() }
        _ => { String::from("unknown") }
    }
}

La sintassi è più pulita e il fatto di essere nella libreria standard elimina la necessità di dichiarare cfg-if nel Cargo.toml. Particolarmente utile per chi sviluppa librerie cross-platform o crate che devono supportare più sistemi operativi e architetture CPU.

if-let guard nei match: pattern matching più espressivo

Rust 1.95 stabilizza gli if-let guard all’interno delle espressioni match, costruendo sulle let chain introdotte in Rust 1.88. Un guard in un match è la condizione if che può seguire un pattern. Finora, questa condizione doveva essere un’espressione booleana semplice. Ora si può usare if let per abbinare pattern aggiuntivi direttamente nella guardia:

fn process(value: Option<Result<i32, String>>) {
    match value {
        Some(x) if let Ok(y) = x => {
            println!("Valore ottenuto: {}", y);
        }
        Some(Err(ref e)) => {
            println!("Errore: {}", e);
        }
        None => {
            println!("Nessun valore");
        }
    }
}

Questo permette di scrivere logica di pattern matching più complessa senza ricorrere a blocchi match annidati. Un caso d’uso pratico è la validazione combinata di metodo HTTP e corpo della richiesta:

fn handle_request(req: &Request) -> Response {
    match req.method() {
        Method::POST if let Ok(body) = serde_json::from_str::<Payload>(req.body()) => {
            process_payload(body)
        }
        Method::POST => {
            Response::bad_request("Payload JSON non valido")
        }
        _ => {
            Response::method_not_allowed()
        }
    }
}

Nota importante sull’esaustività: il compilatore non tiene conto dei pattern negli if-let guard per il controllo di esaustività (exhaustiveness checking). Questo significa che il compilatore non avvertirà se un pattern nell’if-let guard è irraggiungibile. Occorre quindi prestare attenzione quando si usano questi costrutti in match che devono essere esaustivi per correttezza.

Nuove API per Vec, VecDeque e atomici

push_mut e push_back_mut: riferimenti mutabili post-inserimento

Una delle aggiunte più pratiche riguarda i metodi push_mut e varianti per Vec e VecDeque. Questi metodi inseriscono un elemento e restituiscono immediatamente un riferimento mutabile all’elemento appena inserito, eliminando il doppio accesso che prima era necessario:

// Prima: due operazioni separate
let mut v: Vec<String> = Vec::new();
v.push(String::new());
let last = v.last_mut().unwrap(); // secondo accesso necessario
last.push_str("hello");

// Ora con push_mut: un unico accesso, più efficiente
let mut v: Vec<String> = Vec::new();
let elem = v.push_mut(String::new());
elem.push_str("hello"); // riferimento diretto all'elemento appena inserito

Metodi analoghi (push_back_mut, push_front_mut) sono disponibili anche su VecDeque, utile per code e buffer circolari.

update e try_update sugli atomici

I tipi atomici (AtomicUsize, AtomicBool, AtomicI32, ecc.) guadagnano i metodi update e try_update per semplificare i pattern read-modify-write senza dover scrivere manualmente il loop CAS (Compare-And-Swap):

use std::sync::atomic::{AtomicUsize, Ordering};

let counter = AtomicUsize::new(0);

// Incrementa atomicamente, restituisce il vecchio valore
let old = counter.update(Ordering::SeqCst, |x| x + 1);
println!("Valore precedente: {}", old);

// try_update: permette di fallire condizionalmente
// (ritorna Err se la chiusura restituisce None)
let result = counter.try_update(Ordering::SeqCst, |x| {
    if x < 100 { Some(x + 1) } else { None }
});

match result {
    Ok(old_val) => println!("Aggiornato da {}", old_val),
    Err(_) => println!("Limite raggiunto, nessun aggiornamento"),
}

Questi metodi gestiscono internamente il retry loop in caso di contesa tra thread, rendendo il codice più leggibile e meno soggetto a errori.

Stabilizzazioni in const context

Rust 1.95 estende il supporto ai const context per alcune API già stabili, consentendo un uso più ampio della valutazione a compile-time:

• fmt::from_fn ora utilizzabile in contesti const
• Metodi di ControlFlow ora const-stabili
• Nuovi metodi unsafe per puntatori: as_ref_unchecked e as_mut_unchecked
• Layout::dangling_ptr per manipolazione avanzata della memoria in allocatori custom

Breaking change: JSON target spec non più supportata su stable

Rust 1.95 rimuove il supporto alle specifiche di target in formato JSON sul canale stable. Questa funzionalità era già effettivamente limitata al canale nightly (costruire core richiedeva già nightly), quindi l’impatto pratico è minimo per la maggior parte dei progetti. Chi usa target custom non standard dovrà assicurarsi di usare il canale nightly o di migrare a definizioni di target ufficialmente supportate.

Come aggiornare

Per aggiornare Rust all’ultima versione stabile, basta eseguire:

rustup update stable

Per verificare la versione installata:

rustc --version
# rustc 1.95.0 (xxxxxxxx 2026-04-16)

Conclusioni

Rust 1.95.0 è una release solida che porta miglioramenti trasversali all’ergonomia del linguaggio. cfg_select! riduce la dipendenza da crate esterni per il codice condizionale, gli if-let guard aumentano l’espressività del pattern matching, e le nuove API per Vec e atomici semplificano pattern comuni nella gestione dello stato condiviso in contesti concorrenti.

Nel complesso, questa release conferma la direzione del progetto Rust: migliorare l’ergonomia senza compromettere la sicurezza, incorporando nella libreria standard soluzioni che prima richiedevano crate esterni.

Fonte: Announcing Rust 1.95.0 — The Rust Programming Language Blog

Announcing Rust 1.95.0 | Rust Blog

Empowering everyone to build reliable and efficient software.

^{blog.rust-lang.org}

(in)sicurezza digitale

2026-04-20 08:44:42

PRISMEX: la suite di cyberspionaggio di APT28 che prende di mira Ucraina e alleati NATO con steganografia e cloud C2

Si parla di:
Toggle

• APT28 nel 2026: evoluzione di una minaccia permanente
• I bersagli: una mappa geopolitica della catena logistica NATO
• La catena di attacco: due zero-day, un RTF e un server WebDAV
• Anatomia di PRISMEX: quattro componenti, un ecosistema invisibile
• Living-off-the-Cloud: Filen.io come infrastruttura C2
• Indicatori di compromissione (IOC)
• Consigli pratici per i difensori

Una suite di malware inedita, battezzata PRISMEX, porta la firma del GRU russo e punta diritto al cuore delle reti militari e governative legate al conflitto in Ucraina. La campagna combina steganografia proprietaria, COM hijacking e abuso di cloud storage cifrato per raggiungere i propri obiettivi restando praticamente invisibile agli strumenti di difesa tradizionali.

APT28 nel 2026: evoluzione di una minaccia permanente

APT28 — tracciato anche come Forest Blizzard, Fancy Bear e Pawn Storm — è l’unità cyber attribuita al GRU, l’intelligence militare russa. Operativo da oltre vent’anni, il gruppo ha all’attivo compromissioni di altissimo profilo: dal Partito Democratico USA nel 2016 al WADA, passando per decine di istituzioni europee e governi NATO. Ciò che distingue APT28 è la capacità di weaponizzare vulnerabilità ancora prima della loro divulgazione pubblica e di costruire toolchain modulari estremamente evasive.

La campagna documentata tra febbraio e aprile 2026 da Trend Micro, Zscaler ThreatLabz e Trellix — denominata Operation Neusploit — rappresenta un ulteriore salto qualitativo in questa direzione. L’analisi delle infrastrutture mostra che i preparativi erano in corso da settembre 2025, con exploitation attiva dal gennaio 2026.

I bersagli: una mappa geopolitica della catena logistica NATO

La selezione dei target riflette la precisa intelligence operativa del GRU. La campagna ha colpito organi esecutivi centrali ucraini, servizi di difesa, protezione civile e servizi idrometeorologici; operatori ferroviari polacchi coinvolti nella logistica degli aiuti militari; settore marittimo e trasportistico in Romania, Slovenia e Turchia; partner della filiera di approvvigionamento di munizioni in Slovacchia e Repubblica Ceca; unità droni nelle regioni di Kyiv e Kharkiv. Il denominatore comune è la catena di supporto alle operazioni militari ucraine — la stessa che il Cremlino ha interesse a monitorare e potenzialmente compromettere.

La catena di attacco: due zero-day, un RTF e un server WebDAV

Il vettore iniziale è uno spear-phishing particolarmente contestualizzato: email con lure tematici su addestramenti militari, allerte meteorologiche o contrabbando di armi — argomenti credibili per i destinatari designati. L’allegato è un documento RTF che sfrutta CVE-2026-21509, una vulnerabilità di bypass delle funzionalità di sicurezza di Microsoft Office.

All’apertura, il sistema vittima viene forzato a connettersi a un server WebDAV controllato dagli attaccanti, da cui viene recuperato automaticamente un file LNK malevolo. Questo sfrutta CVE-2026-21513 per bypassare le protezioni del browser ed eseguire silenziosamente il payload successivo. La tempistica è rivelatrice: l’infrastruttura per CVE-2026-21509 era operativa il 12 gennaio 2026, due settimane prima della divulgazione pubblica del 26 gennaio. La patch per CVE-2026-21513 è arrivata il 10 febbraio, lasciando una finestra di undici giorni da zero-day sfruttabile.

Anatomia di PRISMEX: quattro componenti, un ecosistema invisibile

PRISMEX non è un singolo malware ma una suite modulare di quattro componenti progettate per operare in concerto, ciascuna con un ruolo preciso:

• PrismexSheet: dropper Excel con macro VBA che estrae payload nascosti nel file tramite steganografia. Mostra un documento decoy convincente (inventari droni, listini prezzi militari) per non destare sospetti e stabilisce persistenza via COM hijacking.
• PrismexDrop: dropper nativo che prepara l’ambiente per lo sfruttamento successivo utilizzando scheduled task e COM DLL hijacking abbinati al riavvio di explorer.exe per la persistenza tra i riavvii.
• PrismexLoader: proxy DLL che esegue codice malevolo mascherandosi da libreria legittima. Impiega la tecnica steganografica proprietaria “Bit Plane Round Robin” per estrarre payload nascosti all’interno di immagini apparentemente normali, con esecuzione interamente in memoria per minimizzare le tracce su disco.
• PrismexStager: implant .NET basato sul framework Covenant, fortemente offuscato con nomi di funzione randomizzati. Comunica con i server C2 abusando di Filen.io, un servizio di cloud storage cifrato legittimo, rendendo il traffico malevolo indistinguibile da normali operazioni cloud.

In alcuni scenari di attacco è stato rilevato anche il deployment di MiniDoor, uno stealer specificamente progettato per l’esfiltrazione di email da Microsoft Outlook — un indicatore diretto del tipo di intelligence ricercata.

Living-off-the-Cloud: Filen.io come infrastruttura C2

L’abuso di Filen.io come canale C2 rappresenta una raffinata applicazione del paradigma Living-off-the-Cloud (LotC). Filen.io offre storage cifrato end-to-end, rendendo l’ispezione del contenuto del traffico particolarmente difficile anche per soluzioni avanzate di network detection. I sistemi di filtraggio basati su reputazione IP o domain non rilevano anomalie poiché il dominio è genuinamente legittimo e ampiamente utilizzato. Questa strategia, già osservata con OneDrive, Google Drive e Dropbox in campagne APT precedenti, viene qui applicata con un servizio meno noto e con cifratura robusta — un ostacolo aggiuntivo per i Blue Team.

Indicatori di compromissione (IOC)

# Domini usati per hosting/delivery degli exploit Office
wellnessmedcare[.]org
wellnesscaremed[.]com
freefoodaid[.]com
longsauce[.]com

# CVE sfruttate nella campagna
CVE-2026-21509 - Microsoft Office Security Feature Bypass
  Divulgazione pubblica: 26 gennaio 2026
  Infrastruttura attaccante attiva dal: 12 gennaio 2026

CVE-2026-21513 - Browser Security Feature Bypass
  Prime sample osservate: 30 gennaio 2026
  Patch Microsoft: 10 febbraio 2026 (finestra 0-day: 11 giorni)

# C2 infrastructure
Filen.io (cloud storage legittimo abusato per C2 cifrato)

# Framework C2 utilizzato
Covenant (Grunt implant) tramite PrismexStager

# Tecniche MITRE ATT&CK
T1566.001 - Spearphishing Attachment
T1221   - Template Injection (RTF)
T1574.001 - COM DLL Hijacking (PrismexDrop, PrismexSheet)
T1027.003 - Steganography: Bit Plane Round Robin (PrismexLoader)
T1053.005 - Scheduled Task/Job: Scheduled Task
T1102.002 - Web Service: Bidirectional Communication (Filen.io C2)
T1218.011 - Signed Binary Proxy Execution (Rundll32)

Consigli pratici per i difensori

La campagna PRISMEX evidenzia quanto i modelli di difesa basati su firme statiche e reputazione siano inadeguati contro attori di questo livello. Per i team di sicurezza che operano in settori ad alto rischio è essenziale: applicare immediatamente le patch CVE-2026-21509 e CVE-2026-21513 se non già fatto; monitorare comportamenti anomali di processi legittimi come explorer.exe, regsvr32 e processi COM; implementare regole di detection per COM hijacking e creazione non autorizzata di scheduled task; bloccare o monitorare il traffico verso servizi di cloud storage non approvati aziendalmente (incluso Filen.io); disabilitare le macro VBA nei documenti Office provenienti da fonti esterne tramite Group Policy o Intune; adottare una postura “assume breach” con hunting proattivo su anomalie comportamentali piuttosto che su indicatori statici.

PRISMEX: la suite di cyberspionaggio di APT28 che prende di mira Ucraina e alleati NATO con steganografia e cloud C2 - (in)sicurezza digitale

APT28 ha lanciato una nuova campagna di cyberspionaggio contro Ucraina e alleati NATO con PRISMEX, una suite di malware inedita che combina steganografia 'Bit Plane Round Robin', COM hijacking e abuso di Filen.io come C2 cifrato.

^{Dario Fadda ((in)sicurezza digitale)}

Spcnet.it

2026-04-20 08:05:22

Come GitHub usa eBPF per rendere i deploy sicuri: architettura e implementazione

Quando si parla di deployment safety, pochi casi studio sono più istruttivi di quello di GitHub: un’azienda che ospita il proprio codice sorgente sulla piattaforma che sta cercando di aggiornare. Questo crea una dipendenza circolare potenzialmente devastante — durante un’interruzione del servizio, il deploy che dovrebbe ripristinarlo potrebbe fallire proprio perché si appoggia alla piattaforma non disponibile.

Un recente articolo del blog di ingegneria di GitHub descrive come il team abbia risolto questo problema usando eBPF (extended Berkeley Packet Filter), una tecnologia kernel Linux che permette di eseguire codice sandboxed direttamente nel kernel senza modificarlo.

Il problema delle dipendenze nei deploy

GitHub ha identificato tre categorie di dipendenze problematiche nei propri script di deploy:

• Dipendenze dirette: script che scaricano binari da github.com durante il deploy
• Dipendenze nascoste: tool che controllano aggiornamenti su GitHub senza una richiesta esplicita
• Dipendenze transitive: servizi interni che chiamano dipendenze esterne in modo indiretto

Il rischio è evidente: se github.com non è disponibile e il deploy ne dipende, si entra in un loop da cui è difficile uscire. Serviva un meccanismo per rilevare — e bloccare — queste dipendenze prima che causassero problemi in produzione.

eBPF: filtraggio kernel-level senza modificare il kernel

eBPF è un framework che consente di iniettare programmi nel kernel Linux in modo sicuro e verificato. Originariamente nato per il filtraggio dei pacchetti di rete (da cui il nome “Berkeley Packet Filter”), si è evoluto in una piattaforma generale per osservabilità, sicurezza e networking a bassa latenza.

GitHub ha sfruttato due tipi specifici di programmi eBPF:

• BPF_PROG_TYPE_CGROUP_SKB: monitora il traffico in uscita (egress) e applica regole di blocco IP basate sui risultati della risoluzione DNS
• BPF_PROG_TYPE_CGROUP_SOCK_ADDR: intercetta le query DNS e le reindirizza a un proxy userspace che valuta le richieste rispetto a una lista di domini bloccati

I cgroup Linux vengono usati per isolare i processi di deploy. A questi cgroup vengono poi agganciate (attached) le mappe e i programmi eBPF, che possono così osservare e controllare il traffico di rete generato da quei processi specifici.

L’architettura del sistema

Il flusso di funzionamento è il seguente:

1. Un processo di deploy tenta di risolvere un nome di dominio (es. github.com)
2. Il programma eBPF intercetta la query DNS tramite BPF_PROG_TYPE_CGROUP_SOCK_ADDR
3. La query viene reindirizzata a un proxy userspace
4. Il proxy verifica il dominio rispetto alla policy attiva
5. Se il dominio è nella lista bloccata, la risposta viene falsificata (restituendo un IP non raggiungibile)
6. Il programma BPF_PROG_TYPE_CGROUP_SKB monitora il traffico IP per rafforzare il blocco
7. Tutte le violazioni vengono loggate con PID, nome del processo, comando e transaction ID DNS

Particolarmente elegante è l’uso di mappe eBPF (BPF maps) per condividere stato tra i programmi kernel e il proxy userspace, consentendo aggiornamenti dinamici alla policy senza dover ricaricare i programmi.

Implementazione con cilium/ebpf e Go

Per semplificare lo sviluppo, il team ha usato la libreria Go cilium/ebpf, uno dei wrapper eBPF più maturi disponibili oggi. I programmi eBPF sono scritti in C e compilati con bpf2go, uno strumento che genera automaticamente le struct Go corrispondenti per interagire con le mappe e i programmi nel kernel.

Un esempio semplificato di come si carica e aggancia un programma eBPF con cilium/ebpf:

// Carica i programmi eBPF compilati
objs := bpfObjects{}
if err := loadBpfObjects(&objs, nil); err != nil {
    log.Fatalf("loading objects: %v", err)
}
defer objs.Close()

// Aggancia il programma al cgroup del processo di deploy
l, err := link.AttachCgroup(link.CgroupOptions{
    Path:    "/sys/fs/cgroup/deploy",
    Attach:  ebpf.AttachCGroupInetEgress,
    Program: objs.FilterEgress,
})
if err != nil {
    log.Fatalf("attaching cgroup: %v", err)
}
defer l.Close()

log.Println("eBPF program attached, monitoring egress traffic...")

La policy viene aggiornata dinamicamente scrivendo nelle mappe eBPF, senza necessità di riavviare nulla:

// Blocca un dominio aggiungendolo alla mappa eBPF
key := []byte("github.com")
value := uint32(1) // 1 = blocked
if err := objs.BlockedDomains.Put(key, value); err != nil {
    log.Fatalf("updating map: %v", err)
}

Questo approccio consente di modificare le policy a runtime, ad esempio durante un incidente, aggiungendo o rimuovendo domini dalla blocklist senza interrompere i processi in esecuzione.

Correlazione PID e DNS transaction ID

Uno degli aspetti più sofisticati dell’implementazione è la capacità di correlare le query DNS bloccate al processo specifico che le ha generate. Il sistema usa una mappa eBPF per tenere traccia della coppia (PID, DNS transaction ID): quando il proxy userspace vede una query, può risalire al processo che l’ha originata e loggare il percorso completo dell’esecuzione, incluso il comando invocato.

Questo livello di visibilità è fondamentale per il debugging: anziché sapere solo che “qualcosa ha chiamato github.com”, gli ingegneri possono vedere esattamente quale script, a quale riga, stava tentando di accedere alla risorsa bloccata.

Risultati dopo sei mesi di rollout

Dopo sei mesi di utilizzo in produzione, il sistema ha permesso a GitHub di:

• Rilevare dipendenze problematiche prima che causino guasti durante i deploy
• Identificare tool e script che accedevano silenziosamente a github.com durante le operazioni di deploy
• Migliorare la velocità di recovery dagli incidenti, eliminando la circolarità delle dipendenze
• Costruire un inventario delle dipendenze esterne degli script di deploy, utile per la pianificazione della resilienza

Perché eBPF è la scelta giusta per questo caso d’uso

Soluzioni alternative avrebbero avuto limitazioni significative: un firewall a livello di rete avrebbe bloccato il traffico in modo troppo grossolano, impedendo anche il normale funzionamento dei servizi. Proxy applicativi avrebbero richiesto modifiche agli script di deploy. eBPF consente invece di applicare policy granulari, per-processo e dinamiche, senza modificare gli script esistenti né aggiungere overhead significativo alle operazioni normali.

Il fatto che sia una tecnologia kernel-level la rende anche difficile da aggirare accidentalmente: non è sufficiente usare una libreria di networking alternativa o bypassare il resolver DNS del sistema per evadere i controlli.

Conclusioni

L’approccio di GitHub dimostra come eBPF stia trasformando la sicurezza e l’osservabilità delle infrastrutture moderne. Non più solo strumento per profiling di rete, eBPF diventa un componente architetturale per l’enforcement di policy a runtime, invisibile alle applicazioni e aggiornabile senza downtime.

Per chi gestisce infrastrutture critiche o pipeline CI/CD complesse, questo caso studio offre un modello replicabile: usare eBPF per imporre vincoli ai processi di deploy e garantire che il sistema possa sempre ripristinarsi indipendentemente dallo stato dei servizi che ospita.

Fonte: How GitHub uses eBPF to improve deployment safety — GitHub Engineering Blog

How GitHub uses eBPF to improve deployment safety

Learn how Github uses eBPF to detect and prevent circular dependencies in its deployment tooling.

^{Lawrence Gripper (The GitHub Blog)}