Summary: | <net-misc/ntp-4.2.8-r1: Multiple vulnerabilities (CVE-2014-{9293,9294,9295,9296}) | ||||||
---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | Tobias Heinlein (RETIRED) <keytoaster> | ||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | critical | CC: | arm64, base-system, bircoph, c.affolter, creideiki+gentoo-bugzilla, dennis, evert.gentoo, gentoo, himbeere, hu, klondike, mike, mike, randalla, reillyeon, stuartl, tb, ts77, tyler.parsons-gentoo | ||||
Priority: | Normal | ||||||
Version: | unspecified | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
URL: | http://www.kb.cert.org/vuls/id/852879 | ||||||
Whiteboard: | A1 [glsa] | ||||||
Package list: | Runtime testing required: | --- | |||||
Bug Depends on: | 515494, 533232, 533238 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Tobias Heinlein (RETIRED)
![]() CWE-332: Insufficient Entropy in PRNG - CVE-2014-9293 If no authentication key is defined in the ntp.conf file, a cryptographically-weak default key is generated. CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) - CVE-2014-9294 ntp-keygen before 4.2.7p230 uses a non-cryptographic random number generator with a weak seed to generate symmetric keys. CWE-121: Stack Buffer Overflow - CVE-2014-9295 A remote unauthenticated attacker may craft special packets that trigger buffer overflows in the ntpd functions crypto_recv() (when using autokey authentication), ctl_putdata(), and configure(). The resulting buffer overflows may be exploited to allow arbitrary malicious code to be executed with the privilege of the ntpd process. CWE-389: Error Conditions, Return Values, Status Codes - CVE-2014-9296 A section of code in ntpd handling a rare error is missing a return statement, therefore processing did not stop when the error was encountered. This situation may be exploitable by an attacker. The Whiteboard is based on CWE-121 as the main vulnerability. Created attachment 392066 [details, diff]
example 4.2.8 bump
The new release, 4.2.8, is a major version bump but so far it doesn't look like too bad of a change. It does add a dependency on libevent and the configure option --with-yielding-select is required to make cross-compiling to work. There may be other considerations but I haven't found them yet.
This patch is against CoreOS rather than Gentoo and drops the extra man pages tarball (I'm not going to bother with figuring out that part for now) but otherwise should be applicable.
(In reply to mike@marineau.org from comment #2) > Created attachment 392066 [details, diff] [details, diff] > example 4.2.8 bump Installing net-misc/ntp-4.2.8 with your patch compiles fine but even with the default config it crashes after a few seconds with "out of memory". This is on a pax-enabled amd64 system with lots of memory available. (In reply to Dennis Lichtenthäler from comment #3) > (In reply to mike@marineau.org from comment #2) > > Created attachment 392066 [details, diff] [details, diff] [details, diff] > > example 4.2.8 bump > > Installing net-misc/ntp-4.2.8 with your patch compiles fine but even with > the default config it crashes after a few seconds with "out of memory". This > is on a pax-enabled amd64 system with lots of memory available. i have been using it since this morning and it seems to work fine for me so i went ahead and committed the ebuild to the tree for broader testing. If you still have issues, please open a separate bug for investigation. Lets not pollute the security bug. Thanks for the updated ebuild. Apparently we have at least bug 533232 and bug 533238 which could be considered blockers for stabilization. Seeing how this bug has attracted quite a few Cc entries already due to its severity, I'd like to see the new version stable ASAP. Markos, I suppose we don't want to go ahead with stabilization when we have build failures with USE="-ssl", right? Do we have any other alternative? (In reply to Tobias Heinlein from comment #5) > Markos, I suppose we > don't want to go ahead with stabilization when we have build failures with > USE="-ssl", right? Do we have any other alternative? USE="-ssl" should be fixed now. There are no other pending problems at the moment. I suppose it's ok to start the stabilization in a couple of days. (In reply to Tobias Heinlein from comment #5) > Seeing how this bug has attracted quite a few Cc entries already due to its > severity, I'd like to see the new version stable ASAP. Markos, I suppose we > don't want to go ahead with stabilization when we have build failures with > USE="-ssl", right? Do we have any other alternative? SSP and hardened kernels should mitigate these partially :) And by these I meant the stack overflows, the missing return and the broken crypto is a fully different history :P @base-system, security I have been analyzing and contextualizing the patches for the overflow and the missing return. Relevant bugs on ntp bugzies with patches can be found at http://bugs.ntp.org/show_bug.cgi?id=2667 http://bugs.ntp.org/show_bug.cgi?id=2668 http://bugs.ntp.org/show_bug.cgi?id=2669 and http://bugs.ntp.org/show_bug.cgi?id=2670 I can prepare backported versions of these if necessary against -r10 or -r11. (The only one which seems problematic is 2668). The analysis I made of them is as follows: 2667 and 2670 require autokey enabled which means you have added the autokey keyword somewhere on a host (there are practically no public hosts providing autokey authenticated ntp). The first could lead to a buffer overflow on the stack which may be mitigated by SSP, the second could lead to a breach of authenticity but may also cause more serious issues. The work around would be disabling autokey for now. 2668 and 2669 seem to be related to the way configurations are handled. It can probably be worked around with proper restrictions (which I think we provide) to prevent configuration updates. Both involve overflowing a buffer in global space so taking control of the program is less likely to happen specially if ASLR is being used. If you want the patches backported ping on IRC and I'll get my hands onto it. I'm in favor of stabilizing this version. But I cannot speak for the whole base-system team. (In reply to Lars Wendler (Polynomial-C) from comment #10) > I'm in favor of stabilizing this version. But I cannot speak for the whole > base-system team. Yes lets focus on 4.2.8 Arches, please test and mark stable: =net-misc/ntp-4.2.8-r1 Target keywords : "alpha amd64 arm arm64 hppa ia64 ppc ppc64 s390 sh sparc x86" CC: alpha@gentoo.org,amd64@gentoo.org,arm@gentoo.org,arm64@gentoo.org,hppa@gentoo.org,ia64@gentoo.org,ppc@gentoo.org,ppc64@gentoo.org,s390@gentoo.org,sh@gentoo.org,sparc@gentoo.org,x86@gentoo.org Stable for alpha/amd64/arm/ia64/ppc/ppc64/s390/sh/sparc/x86 CVE-2014-9296 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-9296): The receive function in ntp_proto.c in ntpd in NTP before 4.2.8 continues to execute after detecting a certain authentication error, which might allow remote attackers to trigger an unintended association change via crafted packets. CVE-2014-9295 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-9295): Multiple stack-based buffer overflows in ntpd in NTP before 4.2.8 allow remote attackers to execute arbitrary code via a crafted packet, related to (1) the crypto_recv function when the Autokey Authentication feature is used, (2) the ctl_putdata function, and (3) the configure function. CVE-2014-9294 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-9294): util/ntp-keygen.c in ntp-keygen in NTP before 4.2.7p230 uses a weak RNG seed, which makes it easier for remote attackers to defeat cryptographic protection mechanisms via a brute-force attack. CVE-2014-9293 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-9293): The config_auth function in ntpd in NTP before 4.2.7p11, when an auth key is not configured, improperly generates a key, which makes it easier for remote attackers to defeat cryptographic protection mechanisms via a brute-force attack. Stable for HPPA. Releasing GLSA since only non-supported arches are left. It seems ntp-2.8.1-r1 requires libevent[threads] Please look make[4]: Entering directory '/var/tmp/portage/net-misc/ntp-4.2.8-r1/work/ntp-4.2.8/sntp' CCLD sntp /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -levent_pthreads collect2: error: ld returned 1 exit status Makefile:872: recipe for target 'sntp' failed (In reply to Maxim Britov from comment #17) > It seems ntp-2.8.1-r1 requires libevent[threads] > Please look > > make[4]: Entering directory > '/var/tmp/portage/net-misc/ntp-4.2.8-r1/work/ntp-4.2.8/sntp' > CCLD sntp > /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../i686-pc-linux-gnu/bin/ld: > cannot find -levent_pthreads > collect2: error: ld returned 1 exit status > Makefile:872: recipe for target 'sntp' failed I've the same issue on all of my non-threaded machines. Should we open a separate bug for this? IMHO this is a show stopper. (In reply to Thomas Beutin from comment #18) > (In reply to Maxim Britov from comment #17) > > It seems ntp-2.8.1-r1 requires libevent[threads] > > Please look > > > > make[4]: Entering directory > > '/var/tmp/portage/net-misc/ntp-4.2.8-r1/work/ntp-4.2.8/sntp' > > CCLD sntp > > /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../i686-pc-linux-gnu/bin/ld: > > cannot find -levent_pthreads > > collect2: error: ld returned 1 exit status > > Makefile:872: recipe for target 'sntp' failed > > I've the same issue on all of my non-threaded machines. > Should we open a separate bug for this? > IMHO this is a show stopper. yes, you should open separate one, it's irrelevant issues. (In reply to Dennis Lichtenthäler from comment #3) > (In reply to mike@marineau.org from comment #2) > > Created attachment 392066 [details, diff] [details, diff] [details, diff] > > example 4.2.8 bump > > Installing net-misc/ntp-4.2.8 with your patch compiles fine but even with > the default config it crashes after a few seconds with "out of memory". This > is on a pax-enabled amd64 system with lots of memory available. I got a google result talking about ntp bug 2646 seems related https://bugs.archlinux.org/task/41593 unfortunately the ntp website haven't get up for days and there is no archive so no way to be sure With two months waiting for arm64, we need to move the security bug along. If any action is required for arm64 please open a separate bug. Maintainer(s), please drop the vulnerable version(s). @maintainers: ping for cleanup |