Atacar la seguridad HTTPs con un Delorean en Python

Entre la lista de conferencias que se han dado este año en DefCon 23 hay una que tenía ganas de revisar, ya que la daba uno de los mejores hackers españoles, el gran José Selvi. Sus trabajos son siempre elegantes e ingeniosos, como cuando migró JailBreakMe a JailOwnMe para ownear los terminales iPhone - tanto me gustó que le pedí que lo detallara paso a paso para incluirlo en el libro de Hacking iOS -. En esta ocasión, su charla en Las Vegas versaba sobre cómo romper la seguridad de las conexiones HTTPs por medio de un Delorean, una que ya había impartido en Black Hat Europe 2014 pero que no había podido ver todavía.

Figura 1: Atacar la seguridad de HTTPs con un Delorean en Python

Sí, el uso de un Delorean es una forma de hacer entender a todo el mundo que el ataque tiene que ver con las medidas de seguridad que dependen de la fecha del sistema operativo y que, por fallos de seguridad en el protocolo NTP, pueden ser manipuladas para hacer viajar en el tiempo al sistema. Si cuando hablamos de Leap Seconds vimos lo mal que le podía venir a al sistema un segundo introducido, os podéis imaginar si hacemos viajar en el tiempo a los sistemas informáticos durante más tiempo. 

Figura 2: Saltar la seguridad de HSTS con un Delorean

La presentación de la charla la tenéis colgada dentro de la recopilación que han hecho nuestros amigos de Cyberhades con todo el material de DefCon 23, y merece la pena que la veas - incluidas las preciosas fotos de esa ciudad de Valencia tan bonita que tenemos en España -, y en la web de BlackHat Europe 2014 tienes acceso a un WhitePaper donde se recoge el trabajo.

Implementaciones de NTP en sistemas operativos

En la lista de sistemas operativos que ha analizado José Selvi se encuentran Ubuntu, Fedora, OS X y Windows. Todos ellos hacen uso de una forma u otra del protocolo NTPv3 o NTPv4 con configuraciones susceptibles de sufrir un ataque de man in the middle. Esto quiere decir que, un atacante, podría interceptar la petición de sincronización NTP emitida por el sistema operativo y darle una hora arbitraria para configurar de forma maliciosa la hora del sistema operativo.

Figura 3: Petición NTPv4 de Ubuntu vulnerable a man in the middle

Para hacer esto, hay que utilizar algún esquema de man in the middle en redes IPv4 o IPv6 que permita interceptar la petición NTP del cliente. Aceptando que en una red insegura - sin IPSec o sin posibilidad de bloquear los ataques de man in the middle - el protocolo NTP es vulnerable, las medidas de mitigación que tienen los sistemas operativos se basan por tanto en reconocer si alguna de estas peticiones puede reconocerse como maliciosa.

En las diferentes implementaciones Fedora es que más fácil lo pone, ya que hace una petición cada minuto y por tanto se le pueden hacer cambios en la fecha del sistema constantemente. En el caso de Ubuntu la sincronización es cuando se levanta la conexión de una nueva red o se produce un reinicio. En OS X se hace cada ciertos minutos, pero en las últimas versiones depende de la carga de trabajo que tengo el sistema.  Windows es el que lo pone más complicado, ya que tarda días en hacer las peticiones, además de que no permite cambios muy grandes en los tiempos, desechando las peticiones que vienen con grandes saltos, dejando una ventana muy pequeña de ataque.

Figura 4: Cuatro de los cinco modos de funcionamiento que tiene Delorean para viajar en el tiempo

Visto esta primera parte, el resumen sería que, con mayor o menor grado de exposición, si un equipo se conecta a una red insegura, su fecha del sistema puede ser alterada de forma maliciosa por medio de una herramienta escrita en Python, que José Selvi ha bautizado como Delorean.

Ataques a HSTS con el Delorean

Visto esto, que un equipo tenga una fecha maliciosa puede ser aprovechado por un atacante para hacerle mucho daño a un equipo. Uno de los ejemplos que propone José Selvi es el de atacar el protocolo HSTS. Este protocolo cierra la posibilidad de ataques Man in The Middle que se producen cuando se utilizan conexiones HTTP, ya que con HSTS se fuerza al navegador a que la conexión sea siempre por HTTPs cuando un dominio esté en la lista. Esto se hace mediante la configuración del HTTP Header HSTS que envía el servidor web en la primera conexión. A partir de ese momento se le impide al navegador conectarse a un dominio por HTTP mientras el TTL configurado por el HSTS sea mayor que cero. Es decir, que no haya caducado.

Desde las URLs internas de Google Chrome, puedes consultar el estado de la política HSTS que tiene tu navegador para cada dominio, así como los datos del certificado que se espera encontrar al otro lado para que no le den uno falso. Es decir, no solo la política de HSTS, sino también cuál es el certificado del que se está haciendo Certificate Pinning.

Figura 5: Configuración de HSTS para el dominio www.gmail.com en Google Chrome

Sin embargo, usando el Delorean alguien puede llevar la fecha más allá en el tiempo, hacer que caduque el TTL de la configuración HSTS y conseguir una petición HTTP a un dominio para lograr hacer, ahora sí, un ataque de SSLStrip, como el que hacía yo con Evil FOCA para robar las cuentas de Facebook o Gmail usando el ataque de WPAD.

Figura 6: Si consigues deshabilitar HSTS puedes conseguir que el navegador pida Facebook por HTTP

A día de hoy esto no es posible con todos los dominios, ya que algunos navegadores tienen listas preconfiguradas en el código, es decir, hardcodeadas, de conexiones HSTS que no van a realizarse nunca por HTTP - ni la primera vez -. Esta lista la gestiona Google Chrome y la utilizan otros navegadores. Además, cualquiera puede solicitar estar en esa lista mediante este sitio web.

Figura 7: Configuración de política de expiración en lista precargada de certificados

Por suerte o por desgracia, los certificados de esa lista también dependen del tiempo y expiran - y no tardando mucho ya que algunos son horas, otros como Google Chrome 10 semanas -, así que es posible hacer caducar la lista precargada en los navegadores y forzar la conexión HTTP a un sitio web para lograr interceptarla y hacer un man in the middle a esa conexión.

Usando certificados digitales expirados

Otra de las cosas curiosas que se pueden hacer es la de llevar con el Delorean la fecha del sistema a un tiempo en el pasado, con el objeto de lograr que los certificados que hubieran expirando antaño o que hayan sido marcados como caducados, vuelvan a ser válidos. 

Figura 8: Certificado de Diginotar firmado para Google.com que se bloqueó

Así, por ejemplo, José Selvi explica cómo se puede engañar a un navegador para que vuelva a dar por válidos los certificados robados a Diginotar que se hicieron para firmar dominios como Google.com o Live.com. Pero también para conseguir que certificados de las listas CRL que han sido marcados como caducados vuelvan a poder usarse.

Los planificadores de tareas y las actualizaciones de seguridad

Por último, una de las cosas más curiosas que se producen es que, si un equipo cambia su fecha y su hora, todo su planificador de tareas puede dejar de funcionar. Esto hace que las tareas de mantenimiento puedan no realizarse a tiempo o incluso no hacerlo nunca. En el caso de Windows, una de las cosas que se puede hacer es llevar la fecha del sistema a un tiempo en el futuro, y cuando se planifique la siguiente actualización de software mediante Windows Update, volver a llevar el sistema a su hora actual. Esto, como efecto lateral dejaría a un equipo sin actualización de parches de seguridad.

Figura 9: Configuración de Windows Update para febrero de 2016

Mis más sinceras felicitaciones a José Selvi por este trabajo. De que forma tan sencilla ha enlazado los ataques de man in the middle, las debilidades NTP - que ya eran conocidas - con la seguridad de HTTPs para lograr, con una herramienta sencilla escrita en Python cargarse su seguridad en ciertos entornos. Me encanta.

Saludos Malignos!

Leap Seconds: Problemas en los ajustes horarios (2 de 2)

Tras explicar en la primera de este artículo el porqué de la existencia de los Leap Second, llega el momento de analizar su impacto cuando hay que introducirlos. Cualquier cambio en las condiciones de funcionamiento de un sistema, más cuando se trata de algo tan importante como el tiempo - orquestador de todos los procesos de un sistema -, puede generar situaciones excepcionales que generen excepciones no controladas. Es por eso que, históricamente, los Leap Second han provocado problemas en los sistemas GNU/Linux, ya que utilizan el protocolo NTP para sincronizar el reloj interno del sistema.

Figura 9: ¿Qué pasará cuando tu sistema operativo mienta a las aplicaciones con la hora?
¿Estás listo para el Leap Second del 30 de Junio?

En palabras de Linus Torvalds, creador de Linux, en unas declaraciones, a colación de la próxima inserción el próximo 30 de Junio de un nuevo Leap Second, para la publicación Wired:

“Prácticamente siempre que introducimos un Leap Second encontramos algo nuevo.” “Es muy molesto, porque se trata del claro ejemplo de un código que básicamente nunca se ejecuta, y que no es posible comprobar en condiciones normales”. 

Así que, como se puede ver,  resulta que el mismísimo creador del kernel de Linux - con muy buen criterio, por cierto - afirma que no se sabe a ciencia cierta qué es lo que puede pasar al introducir el Leap Second. Tranquilizador, ¿verdad? Cuando esto suceda, no obstante, se podrá ver en los mensajes de log del kernel de Linux, tal y como se puede ver a continuación.

Figura 10: Mensaje que se verá en los logs del kernel cuando se introduzca el Leap Second

Problemas en el pasado en Linux con la introducción de Leap Seconds

Algunas de las posibles consecuencias de las que habla Linus, se materializaron tanto en el año 2009, como en el año 2012 en forma de “Kernel Dumps” y “Live Locks” producidos en el kernel de Linux.

Figura 11: Problemas reportados tras la introducción de un Leap Second

Figura 12: Bug de condición de carrera en NTP debido al Leap Second

Figura 13: El Kernel de Linux crasheando por culpa del Leap Second de 2009

Figura 14: El Kernel de Linux crasheando por culpa del Leap Second introducido en 2012

Problemas con Leap Seconds en aplicaciones

Lo cierto es que independientemente de los fallos a nivel de kernel, cualquier aplicación que dependa de la serialización de eventos, puede sufrir de la inserción de Leap Seconds si ve, por ejemplo, instantes de tiempo repetidos. El problema se acentúa en sistemas multi-nodo distribuidos, en los que es vital que los relojes se encuentren alineados. Sólo hay que imaginar por ejemplo el caso de dos eventos que van a la misma base de datos con la misma marca temporal. O peor aún, eventos posteriores a otros, que sin embargo quedan con el mismo Timestamp. Está claro que la mayoría del software no está preparado para lidiar con estos Leap Seconds.

Debido al Leap Second introducido en 2012, Gawker, entre otros, sufrió problemas, y se atrevió además a reconocerlo (cosa que otros no hicieron):

“Our web servers running tomcat came close to zero response (we were able to handle some requests),” [...] “We were able to connect to servers in order to reset them. Only rebooting the servers cleared up the issue.”

Software como Java, se vio también afectado por aquel Leap Second, y esto afectó a servicios que corren sobre él, tales como Cassandra y Hadoop. Otras empresas con problemas fueron Foursquare, Yelp, LinkedIn, Mozilla Foundation y StumbleUpon. También se dijo que The Pirate Bay había sido afectada por este bug, pero lo cierto es que no fue así, sino que se trató de una migración de un servidor que salió mal, todo ello en la misma noche en la que se materializó el Leap Second. MySQL sufrió también este bug:

Figura 15: MySQL afectada por el Leap Second

Incluso los servidores de Minecraft fallaron, lo que podía haber sido el fin del mundo si todos los usuarios de este mundo virtual no pudieran entrar a la plataforma ;).

Figura 16: Servidores de MineCraft afectados

Uno de los casos más sonados fue el de Amadeus, la multinacional española de desarrollo de soluciones. El sistema de reservas de Qantas y de Virgin Australia, basado en el software de Amadeus, se vino abajo debido al Leap Second de 2012, imposibilitando a los viajeros facturar, teniendo por tanto que formar largas colas, y provocando retrasos de varias horas, obligando a los trabajadores a realizar la facturación manualmente, como hace décadas.

Figura 17: Consumos superiores a 1 Megavatio en Hetzner

Otro caso interesante, fue el del aumento en el consumo de CPU (debido a un Live Lock) en dos proveedores de hosting, que sufrieron el bug del Leap Second de Linux en 2012 donde Hetzner sufrió una subida en el consumo eléctrico de 1 Megavatio y OVH reportó picos de consumo eléctrico debido a bugs al lidiar con el Leap Second.

Figura 18: Picos de consumo reportados por OVH

Posibles soluciones para evitar problemas con Leap Seconds

El problema que tenemos con los Leap Second, es un problema de base. Tal y como comenta Steve Allen, un programador del Observatorio Lick de California:

“Cuando ocurre un Leap Second, el sistema operativo tiene que ingeniárselas para que el resto de las aplicaciones no se den cuenta”.

Se trata por tanto de “mentiras piadosas” que nos pueden pasar factura. Una comparativa interesante que realiza el propio Steve Allen, es que nos enfrentamos a la misma paradoja que se produce en la película 2001 Una odisea en el espacio, en la que HAL 9000, el ordenador de a bordo, empieza a funcionar mal y a tener comportamientos psicópatas, a partir de ser programada para mentir:

“Le dices al ordenador que mienta, y a partir de ahí ya no se puede tener certeza de lo que pasará a continuación.”

La solución que se ha buscado Google consiste en mentirse a sí mismos, pero muy poco a poco y de manera apenas imperceptible, durante un periodo de 20 horas. Durante ese tiempo previo a la introducción en UTC del Leap Second, Google irá ralentizado gradualmente la hora de los sistemas, de forma que para cuando llegue el momento del Leap Second, los sistemas de Google ya estén en línea con la nueva hora UTC.

Amazon hará algo similar: ralentizará durante un periodo de 24 horas sus relojes, desde las 12 horas previas a la introducción del Leap Second, hasta las 12 horas posteriores. Por tanto, 12 horas después del Leap Second, los relojes estarán en línea con la nueva hora UTC.

Para aquellos que no tengan los recursos de Google o Amazon, y que no se puedan permitir implementar su propia versión de NTP, existe una alternativa. Dicho sea de paso, esta alternativa se podrá utilizar en sistemas que requieran precisión, que no exactitud, en lo que a la sincronización horaria se refiere.

El workaround consiste en ejecutar NTP en modo slew. En dicho modo, NTP no utilizará la llamada adjtime() de cara a informar al kernel de que se ha introducido un Leap Second. Por el contrario, NTP utilizará la llamada adjtimex() para simplemente, ajustar el reloj del sistema, pero ignorando por completo el Leap Second introducido.

Figura 19: Modo slew del daemon de NTP

De esa forma, el kernel no ejecutará ninguna rutina excepcional de cara a tratar el Leap Second, sino que ajustará eventualmente el reloj cuando se percate de que no se encuentra en línea con la hora UTC. Este ajuste lo realizará durante bastante horas, que podrían en algunos casos llegar a ser días. Lo cierto es que en el peor de los casos, durante todo este periodo, el reloj se encontrará desajustado en 1s. Para activar el modo slew, no hay más que reiniciar el demonio NTP, pasándole el flag ‘-x’. Se recomienda realizar este cambio al menos 24 horas antes de que se introduzca el Leap Second, y desactivarlo 24 horas después.

Por último hay que decir que dada la complejidad del problema y las dificultades que se han experimentado en el pasado, existen voces dentro de ITU (International Telecommunication Union) para abandonar por completo la idea de los Leap Second, precisamente por el riesgo que el uso de los mismos entraña. Pero no será hasta noviembre de este año, que es cuando se celebra la WRC-15, que se vuelva a hablar de este tema. Por tanto, tendremos Leap Second el 30 de junio de este año 2015, sí o sí. Veremos cuales son esta vez las consecuencias, si es que las hay…

Figura 20: ¿Habrá situaciones anómalas en la introducción de este Leap Second?

Por otro lado, desde aquí me gustaría lanzar una cuestión, ya que cuando se miente con la hora pasan cosas raras en los sistemas operativos:

¿Creéis que sería posible explotar determinadas vulnerabilidades, o bordear ciertos controles (reglas de firewall, IDS/IPS, iptables, etc…) durante la introducción del Leap Second ¿Cómo pensáis que se comportan determinadas aplicaciones o hardware durante ese preciso instante?

Autor: Ángel Blázquez

Leap Seconds: Problemas en los ajustes horarios (1 de 2)

¿Alguna vez has tenido que poner manualmente en hora un reloj porque se atrasaba o se adelantaba? Que estés más o menos familiarizado con esta acción va a depender en gran medida de tu edad, ya que hoy en día la mayoría de los sistemas que te informan de la hora no necesitan de ti para estar en hora. Es por ello que hacer este tipo de ajustes manualmente es cada vez menos común.

Figura 1: Leap Seconds: Problemas con los ajustes horarios

La razón es que, como posiblemente muchos sepáis, la gran mayoría de los sistemas con los que trabajamos diariamente ajustan sus relojes auto-mágicamente, mediante el conocido como “Network Time Protocol” (NTP). Se trata de un protocolo que aun siendo sencillo en su comprensión y uso, también es muy complejo cuando se baja a estudiarlo al detalle. Para que os hagáis una ligera idea, cuando se realiza el ajuste horario con él, se tienen en cuenta factores tales como el tiempo de respuesta de los servidores de hora involucrados o la velocidad de la red, por citar algunos de ellos.

Al utilizar el protocolo NTP, la hora se obtiene conectándose con una fuente externa que mantiene ésta con gran precisión. Son los denominados relojes atómicos, que se basan en una señal constante, emitida por la energía de los electrones de un átomo. Esto hace que estos relojes sean capaces de mantener la hora con una enorme precisión, segundo tras segundo, durante años. Y ya que estamos hablando de segundos, hay que recordar que en algún momento de la historia, dicho segundo fue definido de acuerdo a la rotación de la tierra media que tuvieron los días entre 1750 y 1890, como una ochenta-y-seis-mil-cuatrocientos-ava parte (1/86.400) de esa duración.

Esto fue así hasta 1967 donde la medición de los segundos se hace tomando como base el tiempo atómico. Según la definición del Sistema Internacional de Unidades un segundo es la duración de 9.192.631.770 de oscilaciones de la radiación emitida en la transición entre los dos niveles hiperfinos del estado fundamental del isótopo 133 del átomo de Cesio (133Cs), a una temperatura de 0º Kelvin.

Los desajustes en la hora: Hora rotacional vs Hora perpetudad

Sin embargo, una de las desventajas de vivir en un planeta en continuo deshielo, afectado por terremotos, cuya agua siente cierta atracción por La Luna, a lo que le tenemos que sumar que además vivimos en un universo en continua expansión es que, donde dije 86.400 digo Diego…

Figura 2: Explicación del problema de los Leap Seconds por XKCD

Así, muy pronto los científicos se dieron cuenta de que, por un lado, la hora definida por ellos, y que no sólo utiliza esta relación 1/86.400, sino que además la mantiene y perpetúa en precisos relojes atómicos, y por otro la hora definida en función de La Tierra y en cuanto a su posición rotacional, no eran exactamente iguales.

Esto es debido a, como ya adelantábamos, el hecho de que el Planeta Tierra no deje de ser una esfera imperfecta en la que asimismo se producen terremotos, erupciones volcánicas, y que además se ve afectado por fuerzas gravitacionales provenientes de La Luna (efecto marea). Estos factores, bien ralentizan, bien aceleran el movimiento de rotación de La Tierra, y en cualquier caso, por muy pequeñas que sean las variaciones, no nos dejan indiferentes en lo que a temas horarios se refiere.

Figura 3: El terremoto de Japón acortó los días

Figura 4: El Terremoto que causó el Tsunami también afectó a la duración de los días

Debido a esto, la rotación del Planeta Tierra se ha venido retrasando una media de 2 milisegundos al día durante las últimas décadas. O 1.4 milisegundos, si tenemos en cuenta los últimos siglos, basándonos en la observación de antiguos eclipses. Esta deceleración provoca que la hora rotacional se encuentre ligeramente retrasada con respecto a la hora perpetuada en los relojes atómicos. Para darnos una idea sobre la magnitud de este fenómeno, hace 500 millones años, esto es, hace 1/9 de la vida de La Tierra, cada día duraba 22 horas en lugar de 24.



Esto significa que si la optásemos por seguir ciegamente el tiempo que nos marcan los relojes atómicos, nos daríamos cuenta de repente un día tras millones de años (si seguimos por aquí, claro está), de que el mediodía se produciría justo en mitad de la noche…

Se trata por tanto de un conflicto entre el tiempo marcado por los relojes atómicos y que consideran un día como 86.400 segundos, y la hora civil de los humanos, que experimentan el día como un giro completo de La Tierra alrededor de su eje. Por tanto, estas fluctuaciones en la velocidad rotacional de La Tierra, hacen que, incluso teniendo relojes atómicos que son utilizados por los servicios globales de establecimiento horario, cada cierto tiempo tengamos que ajustar nuestra “hora civil” con la “hora solar”, para asegurarnos de que nuestra “hora civil” no difiere de la “hora rotacional” por más de 0.9 segundos. Es ahí donde entran en juego los denominados Leap Seconds.

Leap Seconds en los ajustes horarios

De cara a ajustar la hora civil a la hora rotacional de La Tierra, se introducen cada cierto tiempo ajustes a dicha hora civil, bien adelantándola 1 segundo o bien retrasándola 1 segundo. A estos ajustes los denominamos Leap Seconds, y ha habido 26 de estos ajustes desde que la medida fue implantada en 1972. Por ahora, todos estos ajustes han retrasado la hora civil en un segundo cada vez. Acumulamos por tanto 26 segundos, que representan la variación que se ha producido desde 1972 entre la hora atómica y la hora civil. Esto significa que en 26 ocasiones los días han durado 86.401 segundos en lugar de 86.400. Desde que la medida fue instaurada en 1972, únicamente se han introducido Leap Seconds en el último día de Junio, y en el último día de Diciembre, siempre a media noche.

Como ya sabemos, también existen los años bisiestos, que tienen un día más para compensar la discrepancia entre nuestro calendario de 365 días, y el tiempo real que tarda La Tierra en dar una vuelta completa alrededor del sol. En cualquier caso los años bisiestos están para ajustar el movimiento irregular de traslación, mientras que el Leap Second está para corregir el movimiento de rotación.

Por tanto, hasta ahora, hemos visto 2 horas distintas:

International Atomic Time (TAI): es la hora atómica dada por un gran número de relojes atómicos que operan en laboratorios a lo largo del globo, mantenidos por el Bureau International des Poids et Mesures.

Coordinated Universal Time (UTC): es la base para la “hora civil”. Difiere de la hora TAI por el número de Leap Seconds introducidos históricamente.

Ambos se relacionan entre sí con la siguiente fórmula:

 TAI = UTC + dAT

, donde dAT es el total de la suma algebraica de los Leap Seconds.

Figura 5: Leap Seconds introducidos históricamente

Permitidme que, por no complicar más las cosas, dejemos a un lado la “Hora GPS”, que es la que viene determinada por los satélites GPS, que también contienen relojes atómicos, sólo que además éstos se ven afectados, dado que se sitúan en la órbita terrestre, por la Teoría de la Relatividad, haciendo que el tiempo en ellos pase más despacio, y obligando a tomar una serie de medidas.

Figura 6: Variabilidad en la rotación de La Tierra

¿Cómo afectan los Leap Second a NTP?

La inserción de Leap Seconds en UTC, y por tanto en NTP, afecta al reloj del sistema y también a la conversión entre dicho reloj del sistema y la hora civil. Existen distintas opciones de cara a abordar la inserción de un Leap Second en el sistema.

Una posible aproximación consistiría en incrementar normalmente el reloj del sistema durante el Leap Second, y retrasarlo a posteriori, una vez que el Leap Second haya terminado. El problema de este enfoque es que la escala de tiempo es discontinua y ambigua, ya que una lectura de la hora que se produzca durante el Leap Second, se repetirá posteriormente. Ésta es la aproximación que utilizan por defecto los sistemas operativos Microsoft Windows, y GNU/Linux en ciertos modos de configuración.

Figura 7: Gestión de Leap Second en Windows Time

La otra opción sería mantener el reloj congelado (en la medida de lo posible) durante el Leap Second, dando eso sí, lecturas incrementales aproximadas de la hora durante este Leap Second. Posteriormente, tras pasar el Leap Second, la hora del sistema quedaría ajustada con la nueva hora UTC, también ajustada tras aplicar el Leap Second, y en línea de nuevo con la hora rotacional del planeta. En esta aproximación la hora se mantiene durante este segundo, y se sigue incrementando con normalidad durante el siguiente segundo, una vez transcurrido el Leap Second (con lo cual no hay que retrasar un segundo para compensar).

Dado que por lógica, tras dos lecturas consecutivas de la hora se espera que ésta haya incrementado, este efecto se simula de manera artificial en el kernel durante el Leap Second, y cada lectura del reloj provoca que el reloj NTP se adelante 1 ns. En la figura siguiente se observa cómo en el caso A el reloj no ha sido leído durante el Leap Second, mientras que en el caso B, sí que ha sido leído, y el valor de la hora ha sido incrementado ligeramente durante el Leap Second, efecto que será corregido tras el mismo.

Figura 8: Congelación del reloj

Existe el temor a que una aplicación voraz consulte el reloj un gran número de veces y lo más rápido que sea posible. Lo cierto es que al incrementar de manera artificial en 10 ns cada lectura, y teniendo en cuenta que la lectura de la hora del sistema tiene un overhead de unos 100 ns, al final del Leap Second, el tiempo total acumulado incluso en ese caso extremo no sería de más de 10 ms.

En la segunda parte veremos los bugs e issues que han provocado en el pasado y pueden provocar en el futuro los Leap Seconds.

Autor: Ángel Blázquez