Bug 216309 - Buffer Overflow in NTP WWV Refclock Driver
Buffer Overflow in NTP WWV Refclock Driver
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ntp (Show other bugs)
6
All Linux
medium Severity high
: ---
: ---
Assigned To: Miroslav Lichvar
Brian Brock
:
Depends On:
Blocks: 216853
  Show dependency treegraph
 
Reported: 2006-11-18 22:27 EST by Doug Mitchell
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-13 12:44:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Doug Mitchell 2006-11-18 22:27:41 EST
Description of problem:
ntpd crashes after reading first successful timestamp from WWV Audio Refclock
driver.

Version-Release number of selected component (if applicable):
ntp-4.2.2p1-3


Steps to Reproduce:
1.  Enable WWV Audio Refclock Driver and feed with signal
2.  Wait for sync-up and good timestamps
3.  Boom
  
Actual results:

wwv: timecode 50 ?C 2000 000 00:01:00  S +0 0 127 WV15 54 15 15.6 8
wwv3 59 0011   0 6769  3440  16.9  8805  24.4  7590
wwv3  0 0031   0 6769  3010  16.9   385  -0.6     0
*** buffer overflow detected ***: /usr/sbin/ntpd terminated
======= Backtrace: =========
/lib64/libc.so.6(__chk_fail+0x2f)[0x2aaaab22ddff]
/lib64/libc.so.6[0x2aaaab22d3b9]
/lib64/libc.so.6(__printf_fp+0x2537)[0x2aaaab1960f7]
/lib64/libc.so.6(_IO_vfprintf+0x181f)[0x2aaaab19077f]
/lib64/libc.so.6(__vsprintf_chk+0x9d)[0x2aaaab22d45d]
/lib64/libc.so.6(__sprintf_chk+0x80)[0x2aaaab22d3a0]
/usr/sbin/ntpd[0x555555591510]
/usr/sbin/ntpd[0x5555555929cd]
/usr/sbin/ntpd[0x55555559301c]
/usr/sbin/ntpd[0x555555569891]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x2aaaab16aa44]
/usr/sbin/ntpd[0x555555561a09]
======= Memory map: ========

Program received signal SIGABRT, Aborted.
0x00002aaaab17d1b5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00002aaaab17d1b5 in raise () from /lib64/libc.so.6
#1  0x00002aaaab17eb20 in abort () from /lib64/libc.so.6
#2  0x00002aaaab1b467b in __libc_message () from /lib64/libc.so.6
#3  0x00002aaaab22ddff in __chk_fail () from /lib64/libc.so.6
#4  0x00002aaaab22d3b9 in _IO_str_chk_overflow () from /lib64/libc.so.6
#5  0x00002aaaab1960f7 in __printf_fp () from /lib64/libc.so.6
#6  0x00002aaaab19077f in vfprintf () from /lib64/libc.so.6
#7  0x00002aaaab22d45d in __vsprintf_chk () from /lib64/libc.so.6
#8  0x00002aaaab22d3a0 in __sprintf_chk () from /lib64/libc.so.6
#9  0x0000555555591510 in wwv_rsec (peer=0x5555557ca2b0,
bit=-4513.3117646225419) at refclock_wwv.c:1916
#10 0x00005555555929cd in wwv_rf (peer=0x5555557ca2b0, isig=511) at
refclock_wwv.c:1774
#11 0x000055555559301c in wwv_receive (rbufp=0x55555585d560) at refclock_wwv.c:841
#12 0x0000555555569891 in ntpdmain (argc=<value optimized out>, argv=<value
optimized out>) at ntpd.c:987
#13 0x00002aaaab16aa44 in __libc_start_main () from /lib64/libc.so.6
#14 0x0000555555561a09 in _start () from /usr/sbin/ntpd
(gdb) 



Expected results:


Additional info:
It seems that someone tried to put more than 50 bytes in a 50 byte buffer at
refclock_wwv.c:1916 or thereabouts.  Also note that ntpd is full of unbounded
sprintf's that should probably snprintf's someday.

Thanks,
Doug
Comment 1 Doug Mitchell 2006-11-19 00:36:12 EST
Also requires that flag4 (CLK_FLAG4) to be set for debugging for crash to occur.
 Here is the line from my ntp.conf that enables debugging:

fudge 127.127.36.0 flag4 1

And that should have been "too many bytes in an 80 byte buffer".

Thanks,
Doug
Comment 2 Miroslav Lichvar 2006-11-20 08:51:00 EST
Thanks for the report, I will put a fix to updates.

Reported upstream: https://ntp.isc.org/bugs/show_bug.cgi?id=738
Comment 3 Lubomir Kundrak 2006-11-20 12:27:52 EST
I remove the the Security Response Team from the CC list, for I believe (and
agree with mlichvar) this does not have any security consequences. The bug
is triggered only while debugging, and occurs in very early phase of daemon
startup ("after reading first successful timestamp").

Note You need to log in before you can comment on or make changes to this bug.