Package: chrony / 1.30-2+deb8u2
Metadata
Package | Version | Patches format |
---|---|---|
chrony | 1.30-2+deb8u2 | 3.0 (quilt) |
Patch series
view the series filePatch | File delta | Description |
---|---|---|
01_fix small typo in manpages.patch | (download) |
chronyd.8.in |
2 1 + 1 - 0 ! |
fix small typo in manpage |
03_recreate always getdate c.patch | (download) |
Makefile.in |
6 3 + 3 - 0 ! |
recreate always getdate.c |
04_do not look for ncurses.patch | (download) |
configure |
4 2 + 2 - 0 ! |
do not look for ncurses |
05_disable installation of license.patch | (download) |
Makefile.in |
4 2 + 2 - 0 ! |
disable installation of license |
11_protect authenticated symmetric ass.patch | (download) |
ntp_core.c |
19 8 + 11 - 0 ! |
ntp: protect authenticated symmetric associations against dos attacks An attacker knowing that NTP hosts A and B are peering with each other (symmetric association) can send a packet with random timestamps to host A with source address of B which will set the NTP state variables on A to the values sent by the attacker. Host A will then send on its next poll to B a packet with originate timestamp that doesn't match the transmit timestamp of B and the packet will be dropped. If the attacker does this periodically for both hosts, they won't be able to synchronize to each other. It is a denial-of-service attack. According to [1], NTP authentication is supposed to protect symmetric associations against this attack, but in the NTPv3 (RFC 1305) and NTPv4 (RFC 5905) specifications the state variables are updated before the authentication check is performed, which means the association is vulnerable to the attack even when authentication is enabled. To fix this problem, save the originate and local timestamps only when the authentication check (test5) passed. [1] https://www.eecis.udel.edu/~mills/onwire.html |
12_fix subnet size indivisible by four.patch | (download) |
addrfilt.c |
5 4 + 1 - 0 ! |
addrfilt: fix access configuration with subnet size indivisible by 4 When NTP or cmdmon access was configured (from chrony.conf or via authenticated cmdmon) with a subnet size that is indivisible by 4 and an address that has nonzero bits in the 4-bit subnet remainder (e.g. 192.168.15.0/22 or f000::/3), the new setting was written to an incorrect location, possibly outside the allocated array. An attacker that has the command key and is allowed to access cmdmon (only localhost is allowed by default) could exploit this to crash chronyd or possibly execute arbitrary code with the privileges of the chronyd process. |
13_fix initialization of allocated reply slots.patch | (download) |
cmdmon.c |
1 1 + 0 - 0 ! |
cmdmon: fix initialization of allocated reply slots When allocating memory to save unacknowledged replies to authenticated command requests, the last "next" pointer was not initialized to NULL. When all allocated reply slots were used, the next reply could be written to an invalid memory instead of allocating a new slot for it. An attacker that has the command key and is allowed to access cmdmon (only localhost is allowed by default) could exploit this to crash chronyd or possibly execute arbitrary code with the privileges of the chronyd process. |
14_restrict authentication of server peer to specified key.patch | (download) |
ntp_core.c |
3 2 + 1 - 0 ! |
ntp: restrict authentication of server/peer to specified key When a server/peer was specified with a key number to enable authentication with a symmetric key, packets received from the server/peer were accepted if they were authenticated with any of the keys contained in the key file and not just the specified key. This allowed an attacker who knew one key of a client/peer to modify packets from its servers/peers that were authenticated with other keys in a man-in-the-middle (MITM) attack. For example, in a network where each NTP association had a separate key and all hosts had only keys they needed, a client of a server could not attack other clients of the server, but it could attack the server and also attack its own clients (i.e. modify packets from other servers). To not allow the server/peer to be authenticated with other keys extend the authentication test to check if the key ID in the received packet is equal to the configured key number. As a consequence, it's no longer possible to authenticate two peers to each other with two |