Date: Sun, 15 Mar 1998 15:39:31 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
cc: djgpp AT delorie DOT com
Subject: Re: Where to get the latest sources for djtar
In-Reply-To: <6e901q$qpp$1@antares.lu.erisoft.se>
Message-ID: <Pine.SUN.3.91.980315153908.9861I-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On 12 Mar 1998, Martin Stromberg wrote:

> Well, I think I still can get a stack overwrite with the latest djtar.
> Try to "djtar -x" a file containing directories. Then "djtar -x" the
> same file again. When djtar asks you for a new directory name give it
> "1" as new directory name. Then "djtar -x" the same file again (again).
> When djtar asks you for a new directory name give it "1" as new 
> directory name again, then when djtar asks you for a new directory name
> (as 1 already existed) give it "22". Voila crash is a fact.

I cannot reproduce this crash.  Please post the shortest archive that
shows the bug.  Did you use the version of `djtar' from the last alpha
release?

> I think I see the problem in the code but I'm not sure exactly how to 
> fix it:
> Lines 149-150 of src/utils/djtar/djtar.c are
>       sprintf(new, "%s%s", ch->new, fname+strlen(ch->old));
>       strcpy(fname, new);
> 
> This will make the length of new grow and grow and finally overwrite the
> stack.

As far as I can see, in all the cases where these lines execute,
`fname' is declared as an array of dimension PATH_MAX.  PATH_MAX is
512, so I doubt whether it could be overwritten by any reasonable-
length file name.