http://bugzilla.suse.com/show_bug.cgi?id=926323 Bug ID: 926323 Summary: VUL-1: CVE-2015-1821,CVE-2015-1822, 2015-1853: chrony: multiple vulnerabilities Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: opensuse-communityscreening@forge.provo.novell.com Reporter: astieger@suse.com QA Contact: opensuse-communityscreening@forge.provo.novell.com CC: david.bahi@emc.com, mkudlvasr@novell.com, mrueckert@suse.com Found By: Security Response Team Blocker: --- Reported against network:time chrony, not in openSUSE or SLE. Does not have a designated maintainer, CC project maintainers and recent updaters. CVE-2015-1821 chrony: Heap out of bound write in address filter =============================================================== https://bugzilla.redhat.com/show_bug.cgi?id=1209632 Miroslav Lichvar of Red Hat reports: When NTP or cmdmon access is configured (from chrony.conf or over authenticated cmdmon) with a subnet size that is not divisible by 4 and address that has nonzero bits in the 4-bit subnet remainder (e.g. f0::/3), the TableNode array index is calculated incorrectly and it may write past the array. CVE-2015-1822 chrony: uninitialized pointer in cmdmon reply slots ================================================================= https://bugzilla.redhat.com/show_bug.cgi?id=1209632 Miroslav Lichvar of Red Hat reports: The last pointer in the list of allocated reply slots that are used to save authenticated cmdmon replies is not initialized. This one was actually found couple months ago and it's already fixed in git, but only recently I realized it could have security implications. An authenticated attacker can allocate and deallocate memory with other commands (e.g. allow/deny) and can force allocation of new reply slots by making new requests and not acknowledging previous replies, and then let chronyd write a reply to an invalid memory. CVE-2015-1853 chrony: authentication doesn't protect symmetric associations against DoS attacks =============================================================================================== https://bugzilla.redhat.com/show_bug.cgi?id=1209572 Miroslav Lichvar of Red Hat reports: An attacker knowing that NTP hosts A and B are peering with each other (symmetric association) can send a packet 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. This is a known denial-of-service attack, described at [1]. According to the document the NTP authentication is supposed to protect symmetric associations against this attack, but that doesn't seem to be the case. The state variables are updated even when authentication fails and the peers are sending packets with originate timestamps that don't match the transmit timestamps on the receiving side. This seems to be a very old problem, it's in the oldest ntp version I could find (xntp3.3wy). It's also in the NTPv3 (RFC 1305) and NTPv4 (RFC 5905) specifications, so other NTP implementations with support for symmetric associations and authentication may be vulnerable too. For authentication using symmetric keys it should be sufficient to move the code updating the state variables after the MAC is validated (TEST5). For autokey that's not enough, it seems the attacker can still reset the protocol with crypto-NAK or CRYPTO_ASSOC messages and possibly other ways. I'm not sure if this can be fixed for autokey in general. [1] https://www.eecis.udel.edu/~mills/onwire.html -- You are receiving this mail because: You are on the CC list for the bug.