Re: traceroute-4.4BSD (slack) heap overflow

[Cristi Dumitrescu <cristid () CHIP RO>]

Yep, I know, that's exactly why I posted it here, because I found no proper
way to exploit it, even by modifying /etc/hosts :)
Btw, isn't there any environment variable that allows you to specify the
hosts file being used?

----- Original Message -----
From: "Oliver Friedrichs" <of () securityfocus com>
To: "'Cristi Dumitrescu'" <cristid () CHIP RO>; <vuln-dev () securityfocus com>
Sent: Friday, January 05, 2001 10:05 AM
Subject: RE: traceroute-4.4BSD (slack) heap overflow


> The thing is that the BIND resolver limits the hostname length internally,
> so your resolver will never get a hostname that long (luckily), unless you
> happen to go and add it to /etc/hosts yourself (which you need root to do
> anyways).
>
> - Oliver
>
> > -----Original Message-----
> > From: Cristi Dumitrescu [mailto:cristid () CHIP RO]
> > Sent: Thursday, January 04, 2001 6:08 PM
> > To: VULN-DEV () SECURITYFOCUS COM
> > Subject: traceroute-4.4BSD (slack) heap overflow
> >
> >
> > Hi,
> >
> > A while ago I was studying the source code for this
> > traceroute... I found
> > this in the inetname function:
> >
> > ...
> >         static char line[50];
> > ...
> >         if (cp)
> >                 (void) strcpy(line, cp);
> >         else {
> > ...
> >
> > The cp variable holds at that point the hostname for the
> > current host it's
> > tracing. If the hostname is something like a little bit
> > bigger than 4096+50
> > chars it will overflow some other variables from the heap.
> > You can easily
> > check this out by modifying your /etc/hosts, I remember I
> > made it segfault,
> > tho I don't remember exactly how. Anyway, I debugged it and
> > ltraced for a
> > couple of hours and I doubt an exploit could be done,
> > especially given the
> > fact that it's a hostname we're overflowing. So, I thought
> > I'd post it here,
> > maybe someone thinks of a way to actually do something with this.