[20070] in bugtraq
Re: ntpd =< 4.0.99k remote buffer overflow
daemon@ATHENA.MIT.EDU (Durval Menezes)
Fri Apr 6 16:40:00 2001
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <20010406083817.C17140@tmp.com.br>
Date: Fri, 6 Apr 2001 08:38:18 -0300
Reply-To: Durval Menezes <durval@TMP.COM.BR>
From: Durval Menezes <durval@TMP.COM.BR>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20010406002453.T1715@obfuscation.org>; from
techs@obfuscation.org on Fri, Apr 06, 2001 at 12:24:53AM -0400
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?
I think that, when you exercise a buffer overflow against a program that's
vulnerable, if that buffer overflow isn't "tuned" (i.e., the forced syscalls
aren't the right number or the right parameters, the stack frame isn't as
expected, or even it's not the right CPU), there would be a *very*high*
probability (almost a certainty) of aborting the program somehow (either
because of an invalid instruction, or because of an invalid syscall number,
or because the stack frame format was violated).
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.
> The previously posted patch is a pretty rough way to escape, but it seems
> to work just fine.
Thanks for the info.
Best Regards,
--
Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)
