L’effetto dell’errore può portare a guasti imprevedibili su diversi sistemi, compresi quelli che non utilizzano direttamente GPSD, poiché questa applicazione viene utilizzata per ottenere dati temporali precisi su alcuni server NTP utilizzati per la sincronizzazione dell’ora.
È stato identificato un problema critico nel pacchetto GPSD, che viene utilizzato per estrarre dati precisi su ora e posizione dai dispositivi GPS, che farà spostare l’ora di 1024 settimane fa, domani 24 ottobre, ovvero l’ora sarà modificata a marzo 2002. È segnalato da opennet.ru.
Il problema è apparso nelle versioni dalla 3.20 alla 3.22 inclusa ed è stato corretto nella versione GPSD 3.23 (la correzione è stata anche riportata nel pacchetto Debian 3.22). Tutti gli utenti di sistemi che utilizzano GPSD devono installare urgentemente aggiornamenti o essere preparati per un guasto.
L’effetto dell’errore può portare a guasti imprevedibili su diversi sistemi, compresi quelli che non utilizzano direttamente GPSD, poiché questa applicazione viene utilizzata per ottenere dati temporali precisi su alcuni server NTP utilizzati per la sincronizzazione dell’ora. Quando l’ora viene spostata, i sistemi potrebbero riscontrare problemi con l’autenticazione (ad esempio, password monouso, Kerberos e altri meccanismi di verifica dell’accesso che hanno una data di scadenza smetteranno di funzionare), con la verifica dei certificati e con i calcoli che manipolano gli intervalli di tempo (ad esempio, calcolando il tempo della sessione di un utente)…
GPSD viene utilizzato anche in navigatori per auto, droni, robot, apparecchiature militari, apparecchiature di navigazione marittima e aeronautica, in vari dispositivi mobili, compresi quelli basati su piattaforma Android, per molti dei quali non sono più disponibili aggiornamenti firmware. Di solito, su tali dispositivi, il lavoro GPSD è correlato alla navigazione e non influisce sull’impostazione dell’ora del sistema.
Il protocollo GPS prevede un contatore settimanale, che conta le settimane dal 5 gennaio 1980. Il problema è che durante la trasmissione vengono allocati solo 10 bit per questo contatore, il che implica un overflow ogni 1023 settimane (19,7 anni). Il primo overflow si è verificato nel 1999, il secondo nel 2019 e il terzo nel 2038. Questi eventi vengono monitorati dai produttori e dispongono di gestori speciali per essi. Attualmente è stato introdotto in parallelo un nuovo formato di messaggio GPS (CNAV), in cui sono allocati 13 bit per il contatore (ovvero l’overflow è previsto solo nel 2137).
In GPSD, nella logica di correggere l’aspetto di un secondo in più (aggiunto per sincronizzare l’orologio atomico mondiale di riferimento con l’ora astronomica della Terra), è stato commesso un errore a causa del quale il 24 ottobre 2021 1024 sarà prematuramente sottratto dal contatore del numero di settimane. Come previsto dall’autore del codice, lo spostamento doveva avvenire il 31 dicembre 2022, ma la traduzione di questa data nel numero di settimane non è stata eseguita correttamente e il numero effettivo di settimane indicato nell’assegno è sceso sotto ottobre 2021 (il valore è 2180 invece di 2600).
/* sanity check week number, GPS epoch, against leap seconds
* Does not work well with regressions because the leap_sconds
* could be from the receiver, or from BUILD_LEAPSECONDS. */
if (0 < session->context->leap_seconds &&
19 > session->context->leap_seconds &&
2180 < week) {
/* assume leap second = 19 by 31 Dec 2022
* so week > 2180 is way in the future, do not allow it */
week -= 1024;
GPSD_LOG(LOG_WARN, &session->context->errout,
"GPS week confusion. Adjusted week %u for leap %d\n",
week, session->context->leap_seconds);
}