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 :
Post a Comment