Friday, March 20, 2020

[xqqjwpzs] Verifying leap-seconds.txt

The file leap-seconds.list , installed at /usr/share/zoneinfo on Debian and Ubuntu Linux, has a line that begins with #h near the end of the file.  This line is a SHA1 hash.  The following Perl script verifies the integrity of the file, recomputing that hash from the leap second data in the file:

perl -nwe 's/\s//g; if (/^#[@\$](.*)/) {print$1} s/#.*//; print' /usr/share/zoneinfo/leap-seconds.list | sha1sum

The official C software for verifying integrity is at ftp://ftp.boulder.nist.gov/pub/time/software/sha/ and not ~/pub/sha as the file says.

Although the software works, it has a few bugs:

int icount= 0;          /*number of bits in the message*/

The above comment should say number of bytes, not bits.

The code assumes the number of bits will be less than 2^32 (though SHA1 permits up to 2^64 bits), so it will malfunction when the amount of leap second data exceeds 2^29 bytes = 512 MiB.  Currently we have only 356 bytes, so we are a long ways off.  (How long til trouble?  At what rate is the earth's rotation slowing?)

The variable cc ought to be int, not char:

char cc;
...
cc=getchar();
...
if(cc == EOF) /*end of the file*/

The code will fail if a byte with value 255 is read, because EOF (an int with value -1) and 255 are equal.  I think this technically requires char to be signed char, and 255 as a signed char gets sign extended when comparing with the integer value EOF.  A value of 255 might happen with UTF-8 encoding of Unicode.

In the bigger picture, this file ought to have a signature, not just a hash.  It seems imaginable for an attacker to do something nefarious by convincing some computers to observe a leap second and some computers not.

No comments :