redmount.xyz

All’inizio degli anni 2000, prima che l’IPv6 fosse una realtà comune, per connettersi alla nuova rete servivano i tunnel broker: nodi messi in piedi da appassionati o provider che permettevano di avere un indirizzo IPv6 incapsulato dentro IPv4. In Italia c’erano nomi che oggi sembrano quasi leggendari: NGnet, Zibibbo, e poi, su scala più internazionale, SixXS, che per anni ha fornito tunnel di altissima qualità fino a dichiarare “mission accomplished” e chiudere nel 2017. Erano anni in cui IPv6 era roba da smanettoni, e la comunità IRCNet italiana era uno dei posti dove questo “potere” trovava applicazioni creative. Personalmente lo usavo per camuffare il mio IPv4: mentre con un indirizzo 95.x.x.x il server IRC mostrava il reverse DNS dell’ISP, con IPv6 potevo scegliere il mio indirizzo nel blocco assegnato, evitando di esporre il mio IP reale e cambiandolo a piacere. In quel periodo circolavano anche strumenti curiosi, come ipv6fuck.c dell’autore “schizoid”, un codice C che serviva pe...

Dieci anni fa nasceva il Kernel Self-Protection Project, conosciuto come KSPP, con l'obiettivo di cambiare il paradigma della sicurezza in Linux: non più semplicemente correggere vulnerabilità una per una, ma impedire in modo strutturale che intere classi di bug potessero esistere o essere sfruttate. Kees Cook, figura centrale del progetto e sviluppatore in Google, ha recentemente ripercorso dieci anni di progressi nel talk "Kernel Hardening: Ten Years Deep". Il punto di partenza era critico: in media una vulnerabilità nel kernel restava scoperta e sfruttabile per oltre cinque anni. Android e tanti altri sistemi basati su Linux venivano rilasciati con versioni vecchie del kernel, quindi prive delle ultime patch di sicurezza. Il KSPP ha introdotto un nuovo approccio: trasformare il kernel stesso in un ambiente ostile agli exploit. I risultati sono impressionanti. Grazie al lavoro del KSPP, alcune famiglie di bug sono scomparse. Array a lunghezza variabile (VLA), variabili ...

Non succede spesso che sudo, uno dei comandi più fidati e scrutinati del mondo Unix, finisca sotto i riflettori per una vulnerabilità davvero seria. Stavolta è successo due volte, e una delle due fa davvero male. Due bug scoperti e documentati di recente – CVE-2025-32462 e CVE-2025-32463 – mostrano come, anche dopo più di 12 anni di sviluppo, errori silenziosi possano ancora nascondersi in piena vista. Il primo, CVE-32462, è quasi romantico per quanto è vecchio: un difetto nell’uso dell’opzione --host che, in determinate configurazioni di sudoers, può consentire a un utente locale di eseguire comandi con privilegi su host che non dovrebbe nemmeno poter vedere. Roba da manuale, bassa priorità, ma comunque un richiamo interessante per chi pensa che le configurazioni “da laboratorio” non portino guai. Il secondo è molto più cattivo. CVE-32463 sfrutta l’opzione -R di sudo, che consente di specificare una directory chroot. L’idea è che tu possa lanciare comandi in un ambiente isolato, ma ec...