Bug 34813 (CVE-2001-0414)

For the record, FreeBSD has fixed it (and made the exploitation attempts logged) as follows:

http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/ntp/ntpd/ntp_control.c.diff?r1=1.1&r2=1.2

As far as I understood (from Bugtraq) this also affects RH 6 xntpd, right?
Logging breakin attempts would be very good, nod.

Created attachment 14723 [details]
Patch for Rawhide ntp-4.0.99k-13 -- that srpmworks apparently if you have RH7 or recent rawhide, RH 6.0 doesn't like it..

Yeah, that's caused by the ugly glibc-2.2 hack (patch0).

But anyway, you should use xntp3 for RHL62 when upgrading.  As the name changed,
you might have
a nasty surprise as xntp3 -> ntp upgrade lost the syslevel config ('chkconfig
--list | grep ntp').

Attached is my patch I used for xntp3.  Very similar.

Created attachment 14727 [details]
xntp3 (RHL62) patch

we are working on a fix.

Debian checked in security patches yesterday for potato -- you may want to take
a look at the patch.

The debian patch is 100% same.  I think it has originated on ntp-hackers list or the like.

ALSO, when creating the errata for xntp3, please also fix the following (possible) problems
(by Jarno Huuskonen):

diff -uNr xntp3-5.93/libntp/msyslog.c xntp3-5.93.sec/libntp/msyslog.c
--- xntp3-5.93/libntp/msyslog.c Tue Aug 12 09:21:29 1997
+++ xntp3-5.93.sec/libntp/msyslog.c     Wed Oct  4 19:53:08 2000
@@ -141,7 +141,7 @@
          *n++ = '\n';
        *n = '\0';
 
-       vsprintf(buf, nfmt, ap);
+       vsnprintf(buf, 1024, nfmt, ap);
 #if !defined(VMS) && !defined (SYS_VXWORKS)
        if (syslogit)
 #ifndef SYS_WINNT
diff -uNr xntp3-5.93/xntpd/ntp_io.c xntp3-5.93.sec/xntpd/ntp_io.c
--- xntp3-5.93/xntpd/ntp_io.c   Fri Mar 13 03:47:05 1998
+++ xntp3-5.93.sec/xntpd/ntp_io.c       Wed Oct  4 19:54:56 2000
@@ -915,7 +915,7 @@
              fd, addr->sin_family, (int)ntohs(addr->sin_port),
              (u_long)ntohl(addr->sin_addr.s_addr),
              IN_CLASSD(ntohl(addr->sin_addr.s_addr)), flags);
-      msyslog(LOG_ERR, buff);
+      msyslog(LOG_ERR, "%s", buff);
       closesocket(fd);
 
       /*

And can RH7.1 ship with a kosher version please:)

I'm not sure I entirely understand how NTP works (I just install it, specify a
server a watch my clock stay in sync) but it would be good if it didn't offer
service to others by default - ie it operated as a client only.  

Further, is there any reason the server component needs to run as root?  It only
reads the current time, it seems that its only the client that need special
rights (update the system clock)?

The server updates it's own clock too.

Root privileges can be dropped if the capability to change system clock is held
back.  This can be
done using kernel capabilities.  I've made an RPM package to do this (patch and
part of the 
packaging by Chris Wing and Jarno Huuskonen), but it requires kernel >= 2.2.18. 

I hope ntp no longer runs as root in future RHL releases.

Well as RedHat needs to ship 2.2.19 anyway (ptrace, plus about 17 other security
fixes) it shouldn't be a problem.

Can you post a link to the patch/package?

Also, as metioned on bugtraq - http://www.securityfocus.com/archive/1/174372

Could RedHat ship with

restrict default ignore

in the ntp.conf by default?

I'm interested how that command _really_ affects the behaviour.  Specifically,
I'd like to know whether that command drops the replies to local ntp queries
too or not.  And if not, how big the time window there is for someone to spoof
the reply.

As for the droproot + chroot src.rpm, it's available at
http://www.netcore.fi/pekkas/linux/.
You will also need libcap library from the same location (original from PLD; not
100% optimized
for RHL at this point, but works). 

Please also see:

---
  Modified files:        (Branch: RELENG_4)
    contrib/ntp/ntpd     ntp_control.c 
  Log:
  MFC revs 1.3 and 1.4:
    - Correct off-by-one error and buffer underflow from previous fix
    - int -> unsigned char fixes
    - Prevent potential syslog DoS
---
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/ntp/ntpd/ntp_control.c.diff?r1=1.1.1.2.2.1&r2=1.1.1.2.2.2

Bug fixxed, update notices sent, marking resolved.

References:
[1] http://support.ntp.org/bin/view/Main/SecurityNotice#Buffer_overflow_in_ntp_control_c
[2] http://www.kb.cert.org/vuls/id/970472
[3] http://www.securityfocus.com/bid/2540

Relevant upstream patch:
[4] http://bk.ntp.org/ntp-dev/ntpd/ntp_control.c?PAGE=diffs&REV=3ad7a383UGBkNC2MgvTqEy1tGTi-PQ