[20093] in bugtraq
Re: ntpd =< 4.0.99k remote buffer overflow
daemon@ATHENA.MIT.EDU (Crist Clark)
Mon Apr 9 03:56:29 2001
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <3ACE31F2.FE41292C@globalstar.com>
Date: Fri, 6 Apr 2001 14:15:30 -0700
Reply-To: Crist Clark <crist.clark@GLOBALSTAR.COM>
From: Crist Clark <crist.clark@GLOBALSTAR.COM>
X-To: Durval Menezes <durval@TMP.COM.BR>
To: BUGTRAQ@SECURITYFOCUS.COM
Durval Menezes wrote:
>
> Hello,
>
> On Fri, Apr 06, 2001 at 12:24:53AM -0400, Erik Fichtner wrote:
> > On Thu, Apr 05, 2001 at 08:52:43AM -0300, Durval Menezes wrote:
> > > Tried here against stock xntpd 3.5f (from xntpd-3.5f-3.i386.rpm) on a Redhat
> > > Linux 3.0.3 w/ kernel 2.0.36, and the exploit didn't have ANY effect: no
> > > root shell was spawned, and the daemon stayed up. An "strace" of the running
> > > xntpd process confirmed this: no exec syscalls were attempted.
> >
> > [...]
> >
> > > Another vindication for those (like me) that don't like to run the
> > > "latest and greatest" versions of any code ....
> >
> > False hope, man.
> >
> > xntpd 3.5f [1] has the exact same ctl_getitem() that 4.0.99k has,
> > with the same char buf[128] that is poked at in the exact same way.
> > (line 1733 of xntpd/ntp_control.c)
> >
> > It's just a matter of fiddling with it until it's breakable on your
> > particular system.
>
> If it's really vulnerable, shouldn't it have at least dumped core?
[snip]
> But you are right, I should have checked. Will do it ASAP: compiling
> and running a "-g" version under GDB (or else inserting a few well-placed
> printf/syslog()'s) and exercising the attack should do it. My theory right
> now (without looking at the source code) is that the exploit has not worked
> because something else in the code (outside of ctl_getitem()) has prevented
> it.
I downloaded xntpd 3.5, built it on FreeBSD-STABLE, and gave it a shot
after you mentioned yours did not die. I got the same results. It stays
alive. I only looked at the xntpd debug output (not a debugger like gdb),
but it looked like the query was getting truncated before the reply was
formulated. The buffer overflow takes place while formulating the reply.
IIRC, the incoming query was always reported to be 500 bytes in the debug
output no matter how big I actually made it.
Again, I got diverted to more important things before I could put it in
gdb and wrap my head around the source code to figure out what it all
meant. But it might be a place to start. Look for the incoming query being
truncated early on.
--
Crist J. Clark Network Security Engineer
crist.clark@globalstar.com Globalstar, L.P.
(408) 933-4387 FAX: (408) 933-4926
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above. If
the reader of this e-mail is not the intended recipient, or the employee
or agent responsible to deliver it to the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this
e-mail in error, please contact postmaster@globalstar.com
