Ubuntu
util-linux package

UTC is incorrectly implemented; it does not handle leap seconds

Bug #970966 reported by James Haigh
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-control-center (Ubuntu)
Invalid
Undecided
Unassigned
util-linux (Ubuntu)
New
Undecided
Unassigned

Bug Description

UTC ticks SI seconds in step with TAI (International Atomic Time), but in order to keep in sync with UT1 which is defined by the earth's rotation, UTC is occasionally adjusted. In other words, in order to keep UTC 00:00:00 within a second of midnight at the Prime Meridian, leap seconds are added.

See: https://en.wikipedia.org/wiki/Leap_second

So I tested it.

I booted a live copy of Natty and went for a historic leap second:

date --rfc-3339=seconds -s '2008-12-31 23:59:54+00:00'; hwclock -w
while true; do date --rfc-3339=ns; sleep 0.25; done >> /mnt/time.log

time.log:
2008-12-31 23:59:57.753497430+00:00
2008-12-31 23:59:58.006601830+00:00
2008-12-31 23:59:58.259626718+00:00
2008-12-31 23:59:58.512632697+00:00
2008-12-31 23:59:58.765677765+00:00
2008-12-31 23:59:59.018668172+00:00
2008-12-31 23:59:59.271679983+00:00
2008-12-31 23:59:59.524653233+00:00
2008-12-31 23:59:59.777697760+00:00
2009-01-01 00:00:00.030698916+00:00 <-- Where is the leap second?
2009-01-01 00:00:00.283682058+00:00
2009-01-01 00:00:00.536682453+00:00
2009-01-01 00:00:00.789704596+00:00
2009-01-01 00:00:01.042716625+00:00
2009-01-01 00:00:01.295720967+00:00
2009-01-01 00:00:01.548714966+00:00
2009-01-01 00:00:01.801750574+00:00
2009-01-01 00:00:02.054801900+00:00
2009-01-01 00:00:02.307836286+00:00
2009-01-01 00:00:02.560842969+00:00
2009-01-01 00:00:02.813878513+00:00
2009-01-01 00:00:03.066923251+00:00
2009-01-01 00:00:03.319920865+00:00

So either there should be a 23:59:60 leap second, or the system timezone should not be called UTC, but the more ambiguous term 'Universal Time'.

I also tried 1998 and 2005. A leap second has been announced for this June 30.

I think that issues with time can potentially cause or trigger serious bugs elsewhere. So I'm marking this as a security vulnerability just-in-case.

See original description
Revision history for this message
James Haigh (james.r.haigh) wrote :

This makes me wonder if I can maintain a reliable source of TAI on my system.

visibility: private → public
James Haigh (james.r.haigh)
description: updated
Revision history for this message
Fabio Marconi (fabiomarconi) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in gnome-control-center.

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://help.ubuntu.com/community/ReportingBugs.

affects: ubuntu → gnome-control-center (Ubuntu)
Revision history for this message
James Haigh (james.r.haigh) wrote :

Fabio: I clicked 'I don't know' because I actually don't know. It's not gnome-control-center though because it's independent of the desktop environment.

What part of the system actually manages the time?

Changed in gnome-control-center (Ubuntu):
status: New → Invalid
Revision history for this message
James Haigh (james.r.haigh) wrote :

The closest package I can think of is util-linux, but I'm not sure. It's something low-level though, near the kernel. Possibly the kernel itself. I don't really know how time is managed by the system, I just know how to configure and use it.

Revision history for this message
James Haigh (james.r.haigh) wrote :

UTC is uniform but discontinuous. If someone wanted to precisely and reliably measure time between to points, they would need a uniform, continuous standard such as TAI.

TAI can be implemented using the defined relation:
TAI = UTC + 10s + Announced leap seconds since 1972 (Published here: http://maia.usno.navy.mil/ser7/tai-utc.dat)

(24 leap seconds so far)

So if UTC incorrectly fails to insert a leap second, TAI would appear to skip a second. I could therefore incorrectly measure a 25ms time interval as 1025ms.

I could also implement UT1 (which is continuous but non-uniform) by the defined relation:
UT1 = UTC + DUT1 (Published here: http://maia.usno.navy.mil/ser7/finals.all)

See: https://en.wikipedia.org/wiki/DUT1

Again, if UTC incorrectly fails to insert a leap second, UT1 would appear to skip a second, and incorrectly be discontinuous.

See IERS who publish the astronomical data and announce leap seconds:
http://www.iers.org/
http://maia.usno.navy.mil/

Anyway, how does it make sense to sync a clock over the network to high precision using time protocols, when the system's UTC can't even be relied on to a precision of a second?

Marc Deslauriers (mdeslaur)
security vulnerability: yes → no
security vulnerability: yes → no
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.