Epochalypse Now: come prepararsi al bug Y2K38

C’è una data in cui milioni di sistemi IT, compresi quelli industriali e IoT, potrebbero iniziare a comportarsi in modo imprevedibile. Ad esempio, potrebbero verificarsi rallentamenti durante l’elaborazione dei pagamenti con carte di credito o di debito, falsi allarmi generati dai sistemi di sicurezza, errori di funzionamento delle apparecchiature mediche, guasti ai sistemi automatizzati di riscaldamento, erogazione dell’acqua e illuminazione e molti altri problemi, di gravità più o meno elevata. Qual è il giorno fatidico? È presto detto: il 19 gennaio 2038. Certo, mancano ancora molti anni, ma non conviene riposarsi sugli allori. Anzi, il tempo che ci resta potrebbe non essere più sufficiente. Questa moltitudine di problemi sarà innescata da un overflow dei numeri interi utilizzati per la rappresentazione di data/ora. La causa scatenante è chiara e semplice, ma sarà necessario impegnarsi a fondo e con rigore su più fronti, a partire dai governi e dagli enti internazionali fino alle aziende e ai privati cittadini.

Lo standard non scritto di Unix Epoch

Unix Epoch è il metodo che è stato adottato dai sistemi operativi Unix per calcolare la data e l’ora e si è diffuso come standard in tutto il settore IT. I secondi vengono conteggiati dalle 00:00:00 UTC del 1° gennaio 1970, che è considerato il punto zero. Ogni dato momento è rappresentato come il numero di secondi trascorsi da questa data. Per quelle precedenti vengono impiegati valori negativi. Gli sviluppatori dei sistemi Unix hanno scelto questo approccio per la sua estrema semplicità: non è necessario memorizzare separatamente l’anno, il mese, il giorno e l’ora, perché basta un solo numero. In questo modo è più semplice eseguire una serie di operazioni, come l’ordinamento o il calcolo dell’intervallo tra diverse date. Unix Epoch viene oggi utilizzato in molti altri ambiti, non soltanto per i sistemi Unix: ad esempio, nei database, nei protocolli di rete, nei linguaggi di programmazione e negli smartphone con iOS e Android.

Y2K38: una bomba a orologeria

Quando Unix è stato sviluppato, si è deciso di memorizzare la data e l’ora sotto forma di un numero intero con segno a 32 bit. In questo modo era possibile rappresentare un intervallo di date compreso tra il 1901 e il 2038 circa. Il problema è che il 19 gennaio 2038 alle 03:14:07 UTC verrà raggiunto il valore massimo (2.147.483.647 secondi) e si verificherà un overflow: il numero intero diventerà negativo e i computer verranno “teletrasportati” al 13 dicembre 1901. In alcuni casi il viaggio nel tempo potrebbe essere più breve, ossia fino al punto zero (l’anno 1970).

Questo evento, conosciuto anche come “il bug dell’anno 2038”, “Epochalypse” o “Y2K38”, potrebbe causare errori in quei sistemi che utilizzano ancora i numeri interi a 32 bit per rappresentare il tempo, come i terminali POS, i sistemi embedded e i router, e persino le automobili e le attrezzature industriali. Nei sistemi più recenti il problema viene risolto memorizzando data e ora nel formato a 64 bit, che consente di estendere l’intervallo di date a centinaia di miliardi di anni a venire. Ma esistono ancora milioni di dispositivi che impiegano timestamp a 32 bit e che dovranno quindi essere aggiornati o sostituiti prima che scatti l’ora X.

Nel caso specifico, 32 bit e 64 bit si riferiscono al formato di archiviazione della data. Il fatto che un processore o un sistema operativo sia del tipo a 32 o a 64 bit non dà automaticamente la garanzia che la data verrà archiviata nel formato “nativo”. Inoltre, molte applicazioni memorizzano le date in modi completamente diversi e a prescindere dai bit potrebbero non essere colpite dal bug Y2K38.

Se non è necessario gestire date antecedenti al 1970, il timestamp viene archiviato come un numero intero senza segno a 32 bit, che può rappresentare una data compresa tra il 1970 e il 2106. Il problema, quindi, si presenterà in un futuro remoto.

Differenze rispetto al Millennium Bug

Il famigerato Millennium Bug (Y2K), che secondo le previsioni avrebbe scatenato un disastro alla fine del ^XX secolo, era piuttosto simile: i sistemi che utilizzavano due cifre per memorizzare l’anno potevano infatti interpretare erroneamente il 2000 scambiandolo per il 1900. Anche se gli esperti e i mass media prefiguravano l’avvento di un’apocalisse informatica, alla fine si è verificata soltanto una serie di episodi isolati, che non hanno provocato una catastrofe su scala globale.

La differenza fondamentale tra il bug Y2K38 e il Millennium Bug consiste nel livello di digitalizzazione del mondo odierno. Il numero di dispositivi che dovranno essere aggiornati è di gran lunga superiore a quello dei computer che esistevano nel 20 ^° secolo ed è praticamente impossibile calcolare quanti processi e quante attività vengono gestiti ogni giorno dai sistemi informatici. Intanto, nei computer e nei sistemi operativi standard, il problema posto dal bug Y2K38 è già stato risolto (o verrà risolto a breve) semplicemente installando un aggiornamento del software. Ma i microcomputer che gestiscono i condizionatori d’aria, gli ascensori, le pompe, le serrature delle porte e le linee di assemblaggio nelle fabbriche potrebbero trascinarsi nel nuovo decennio con versioni del software obsolete ed esposte a questo bug.

Epochalypse: che cosa dobbiamo aspettarci?

Il ripristino della data al 1901 o al 1970 avrà un impatto diverso a seconda del sistema interessato. In alcuni casi potrebbe passare del tutto inosservato, come negli impianti di illuminazione programmati per accendersi ogni giorno alle 07:00. I sistemi che invece si basano su timestamp completi e precisi potrebbero andare incontro a un arresto totale: nel 2000, per esempio, i tornelli delle linee di trasporto pubblico e i terminali di pagamento hanno smesso di funzionare. Potrebbero anche verificarsi situazioni quasi comiche – pensiamo a un certificato di nascita che viene emesso con una data risalente al 1901. Lo scenario si complica se sono i sistemi di importanza critica a essere colpiti. Cosa succederebbe se un impianto di riscaldamento si spegnesse del tutto o un sistema di analisi del midollo osseo utilizzato in un ospedale non funzionasse correttamente?

Un altro protagonista dell’Epochalypse sarà il criptaggio. Rispetto al 2000, nel 2038 il criptaggio e le firme digitali saranno sempre più utilizzati per la protezione delle comunicazioni. La verifica dei certificati di sicurezza, in genere, non va a buon fine se la data del dispositivo non è corretta. Questo significa che un dispositivo esposto al bug si troverebbe tagliato fuori dalla maggior parte delle comunicazioni, anche se il codice delle principali applicazioni aziendali è in grado di gestire correttamente la data.

Per stabilire l’entità delle conseguenze, non si può far altro che eseguire una serie di test controllati di tutti i sistemi, analizzando i singoli errori che potrebbero presentarsi in modo concatenato.

Y2K38 e lo sfruttamento dannoso delle vulnerabilità

I team IT e InfoSec non dovrebbero considerare Y2K38 come un semplice bug, ma piuttosto come una vulnerabilità che può dare luogo a diversi problemi, come l’esposizione agli attacchi DoS (Denial of Service), e che, in alcuni casi, potrebbe perfino essere sfruttata dai malintenzionati. Per prevenire questi rischi, è indispensabile manipolare la data e l’ora nel sistema interessato, una soluzione che è possibile adottare in almeno due scenari:

• Associando al sistema un server simulato di riferimento ora, in modo da causare un’interferenza nella trasmissione dei dati del protocollo NTP
• Eseguendo lo spoofing del segnale GPS (se il sistema si basa sull’ora satellitare)

È molto probabile che questo errore venga sfruttato nei sistemi OT e IoT, perché di solito occorre più tempo per correggere una vulnerabilità e le conseguenze di un arresto anomalo possono essere decisamente più gravi.

Nelle console ProGauge MagLink LX4 di Dover, che consentono di controllare in modo automatico il livello di carburante, è presente una vulnerabilità legata al calcolo del tempo: CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8). La modifica della data e dell’ora può causare un evento DoS presso il distributore di benzina e impedire l’accesso alla dashboard online per la gestione del dispositivo. Una vulnerabilità tanto pericolosa da meritarsi un avvertimento specifico da parte della CISA .

A che punto siamo con la mitigazione dei rischi associati a Y2K38

Nei sistemi operativi più diffusi si è già iniziato a gettare le basi per risolvere il bug Y2K38. A partire dalla versione 5.6, il kernel Linux integra il supporto per la data e l’ora nel formato a 64 bit, anche se il tipo di architettura è a 32 bit, mentre Linux a 64 bit è sempre stato al riparo da questo problema. I sistemi BSD (Unix), macOS e iOS utilizzano l’ora a 64 bit in tutti i dispositivi più recenti. Le versioni di Windows distribuite nel 21 ^° secolo non sono esposte al bug Y2K38.

La situazione è invece più complessa a livello di applicazioni e archiviazione dei dati. I file system di ultima generazione, come ZFS, F2FS, NTFS e ReFS, sono stati progettati con timestamp a 64 bit, mentre quelli meni recenti, come ext2 ed ext3, presentano ancora vulnerabilità. I file system Ext4 e XFS richiedono l’abilitazione di flag specifici (rispettivamente, extended inode e bigtime) e per sottoporli a conversione potrebbe essere necessario intervenire offline. Il formato di archiviazione nei protocolli NFSv2 e NFSv3 è ancora obsoleto. Il problema colpisce a macchia di leopardo anche i database: il tipo TIMESTAMP in MySQL è sostanzialmente limitato all’anno 2038, quindi occorre effettuare la la migrazione a DATETIME, mentre i tipi standard di timestamp in PostgreSQL sono protetti e al sicuro. Per le applicazioni con codice in linguaggio C, sono stati creati percorsi specifici che consentono di impiegare il formato 64 bit anche nelle architetture a 32 bit, ma è necessario procedere con la ricompilazione di tutti i progetti. In genere i linguaggi come Java, Python e Go utilizzano tipi di timestamp che evitano l’overflow; tuttavia, la sicurezza dei progetti compilati dipende dal fatto che interagiscano o meno con le librerie vulnerabili in linguaggio C.

Un numero enorme di applicazioni, dispositivi embedded e sistemi a 32 bit resterà quindi esposto al bug finché non verrà rigenerato e sottoposto a test e fino a quando gli utenti non avranno installato i relativi aggiornamenti.

Gli appassionati del settore e diverse organizzazioni stanno cercando di dare un ordine coerente a queste informazioni, ma si tratta di iniziative isolate. Non esiste un vero e proprio “database comune delle vulnerabilità Y2K38” (1, 2, 3, 4, 5).

Come risolvere il bug Y2K38

Il bug dell’anno 2038 può essere affrontato con i metodi creati per definire le priorità e e correggere le vulnerabilità. Al momento non esiste purtroppo uno strumento in grado di generare un elenco completo di tutti gli hardware e i software vulnerabili. È quindi indispensabile aggiornare l’inventario delle risorse IT aziendali, assicurarsi che contenga informazioni dettagliate sul firmware e sul software installati e affrontare con metodo rigoroso le vulnerabilità.

Alle voci dell’elenco è possibile assegnare una priorità a seconda di diversi criteri, come l’importanza del sistema aziendale e i dati relativi allo stack tecnologico su cui si basa ogni sistema. Quindi occorre esaminare con attenzione le risorse di supporto del fornitore, chiedere ai produttori informazioni sull’esposizione di hardware e software al bug Y2K38 e, come estremo rimedio, sottoporre i sistemi a un test di verifica.

Quando si esegue il test dei sistemi aziendali, è di fondamentale importanza adottare specifiche precauzioni:

• Non sottoporre mai a test i sistemi di produzione.
• Crea un backup dei dati poco prima di iniziare il test.
• Isola dalle comunicazioni il sistema da sottoporre a test, in modo che non possa essere confuso con altri sistemi presenti nell’organizzazione.
• Se per la modifica della data si utilizza il protocollo NTP o GPS, assicurati che i segnali dei test non raggiungano altri sistemi.
• Al termine del test, reimposta la data e l’ora corrette e documentare in modo approfondito tutti i comportamenti osservati.

Se un sistema risulta vulnerabile al bug Y2K38, è necessario rivolgersi al fornitore e chiedere quali sono le tempistiche stimate per la correzione del problema. Altrimenti, conviene pianificare una migrazione. Per fortuna, c’è ancora abbastanza tempo per aggiornare i sistemi, compresi quelli che hanno un elevato livello di complessità o che richiedono un investimento maggiore.

L’importante è non pensare che il bug Y2K38 sia un problema da risolvere in un futuro remoto, di cui occuparsi tranquillamente tra cinque o otto anni. Probabilmente, abbiamo già esaurito il tempo a nostra disposizione. Per non farsi cogliere impreparati, sono necessari un approccio a livello di sistema e un’attenta pianificazione del parco tecnologico e delle risorse aziendali.