{"id":30412,"date":"2026-01-28T15:48:44","date_gmt":"2026-01-28T13:48:44","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=30412"},"modified":"2026-01-28T15:48:44","modified_gmt":"2026-01-28T13:48:44","slug":"mitigating-y2k38-vulnerability-in-organization","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/mitigating-y2k38-vulnerability-in-organization\/30412\/","title":{"rendered":"Epochalypse Now: come prepararsi al bug Y2K38"},"content":{"rendered":"

C\u2019\u00e8 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\u2019elaborazione 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\u2019acqua e illuminazione e molti altri problemi, di gravit\u00e0 pi\u00f9 o meno elevata. Qual \u00e8 il giorno fatidico? \u00c8 presto detto: il 19 gennaio 2038<\/strong>. Certo, mancano ancora molti anni, ma non conviene riposarsi sugli allori. Anzi, il tempo che ci resta potrebbe non essere pi\u00f9 sufficiente. Questa moltitudine di problemi sar\u00e0 innescata da un overflow dei numeri interi utilizzati per la rappresentazione di data\/ora. La causa scatenante \u00e8 chiara e semplice, ma sar\u00e0 necessario impegnarsi a fondo e con rigore su pi\u00f9 fronti, a partire dai governi e dagli enti internazionali fino alle aziende e ai privati cittadini.<\/p>\n

Lo standard non scritto di Unix Epoch<\/h2>\n

Unix Epoch \u00e8 il metodo che \u00e8 stato adottato dai sistemi operativi Unix per calcolare la data e l\u2019ora e si \u00e8 diffuso come standard in tutto il settore IT. I secondi vengono conteggiati dalle 00:00:00 UTC del 1\u00b0 gennaio 1970, che \u00e8 considerato il punto zero. Ogni dato momento \u00e8 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\u00e0: non \u00e8 necessario memorizzare separatamente l\u2019anno, il mese, il giorno e l\u2019ora, perch\u00e9 basta un solo numero. In questo modo \u00e8 pi\u00f9 semplice eseguire una serie di operazioni, come l\u2019ordinamento o il calcolo dell\u2019intervallo 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.<\/p>\n

Y2K38: una bomba a orologeria<\/h2>\n

Quando Unix \u00e8 stato sviluppato, si \u00e8 deciso di memorizzare la data e l\u2019ora 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 \u00e8 che il 19 gennaio 2038 alle 03:14:07 UTC verr\u00e0 raggiunto il valore massimo (2.147.483.647 secondi) e si verificher\u00e0 un overflow: il numero intero diventer\u00e0 negativo e i computer verranno \u201cteletrasportati\u201d al 13 dicembre 1901. In alcuni casi il viaggio nel tempo potrebbe essere pi\u00f9 breve, ossia fino al punto zero (l\u2019anno 1970).<\/p>\n

Questo evento, conosciuto anche come \u201cil bug dell\u2019anno 2038\u201d, \u201cEpochalypse\u201d o \u201cY2K38\u201d, 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<\/a>. Nei sistemi pi\u00f9 recenti il problema viene risolto memorizzando data e ora nel formato a 64 bit, che consente di estendere l\u2019intervallo 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\u2019ora X.<\/p>\n

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\u00e0 automaticamente la garanzia che la data verr\u00e0 archiviata nel formato \u201cnativo\u201d. Inoltre, molte applicazioni memorizzano le date in modi completamente diversi e a prescindere dai bit potrebbero non essere colpite dal bug Y2K38.<\/p>\n

Se non \u00e8 necessario gestire date antecedenti al 1970, il timestamp viene archiviato come un numero intero senza segno a 32 bit, che pu\u00f2 rappresentare una data compresa tra il 1970 e il 2106. Il problema, quindi, si presenter\u00e0 in un futuro remoto.<\/p>\n

Differenze rispetto al Millennium Bug<\/h2>\n

Il famigerato Millennium Bug (Y2K)<\/a>, che secondo le previsioni avrebbe scatenato un disastro alla fine del XX<\/sup> secolo, era piuttosto simile: i sistemi che utilizzavano due cifre per memorizzare l\u2019anno potevano infatti interpretare erroneamente il 2000 scambiandolo per il 1900. Anche se gli esperti e i mass media prefiguravano l\u2019avvento di un\u2019apocalisse informatica, alla fine si \u00e8 verificata soltanto una serie di episodi isolati<\/a>, che non hanno provocato una catastrofe su scala globale.<\/p>\n

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 \u00e8 di gran lunga superiore a quello dei computer che esistevano nel 20 \u00b0<\/sup> secolo ed \u00e8 praticamente impossibile calcolare quanti processi e quante attivit\u00e0 vengono gestiti ogni giorno dai sistemi informatici. Intanto, nei computer e nei sistemi operativi standard, il problema posto dal bug Y2K38 \u00e8 gi\u00e0 stato risolto (o verr\u00e0 risolto a breve) semplicemente installando un aggiornamento del software. Ma i microcomputer che gestiscono i condizionatori d\u2019aria, 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.<\/p>\n

Epochalypse: che cosa dobbiamo aspettarci?<\/h2>\n

Il ripristino della data al 1901 o al 1970 avr\u00e0 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 \u2013 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<\/a> o un sistema di analisi del midollo osseo utilizzato in un ospedale non funzionasse correttamente?<\/p>\n

Un altro protagonista dell\u2019Epochalypse sar\u00e0 il criptaggio. Rispetto al 2000, nel 2038 il criptaggio e le firme digitali saranno sempre pi\u00f9 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 \u00e8 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 \u00e8 in grado di gestire correttamente la data.<\/p>\n

Per stabilire l\u2019entit\u00e0 delle conseguenze, non si pu\u00f2 far altro che eseguire una serie di test controllati di tutti i sistemi, analizzando i singoli errori che potrebbero presentarsi in modo concatenato.<\/p>\n

Y2K38 e lo sfruttamento dannoso delle vulnerabilit\u00e0<\/h2>\n

I team IT e InfoSec non dovrebbero considerare Y2K38 come un semplice bug, ma piuttosto come una vulnerabilit\u00e0 che pu\u00f2 dare luogo a diversi problemi, come l\u2019esposizione agli attacchi DoS (Denial of Service), e che, in alcuni casi, potrebbe perfino essere sfruttata dai malintenzionati. Per prevenire questi rischi, \u00e8 indispensabile manipolare la data e l\u2019ora nel sistema interessato, una soluzione che \u00e8 possibile adottare in almeno due scenari:<\/p>\n