From: Dmitry Potapov <dpotapov@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Fix buffer overflow in git-grep
Date: Wed, 16 Jul 2008 15:54:20 +0400 [thread overview]
Message-ID: <20080716115420.GD2925@dpotapov.dyndns.org> (raw)
In-Reply-To: <alpine.DEB.1.00.0807161232110.8503@eeepc-johanness>
On Wed, Jul 16, 2008 at 12:35:06PM +0200, Johannes Schindelin wrote:
> >
> > while (tree_entry(tree, &entry)) {
> > - strcpy(path_buf + len, entry.path);
> > + int te_len = tree_entry_len(entry.path, entry.sha1);
> > + if (len + te_len >= PATH_MAX + tn_len)
> > + die ("path too long: %s", path_buf+tn_len);
> > + memcpy(path_buf + len, entry.path, te_len);
>
> That is brutal. Does grep_tree() not work on tree objects in memory? In
> that case, you prevent the user from grepping, only because she is on a
> suboptimal platform, _even if_ even that platform could cope with it.
Sure, but other git commands do not work much better in this case.
In fact, what you called as "brutal" may be considered as very
polite comparing to what other git commands did.
For instance, git show will show you nothing at all and exit with 0.
The same problem with git whatchanged. The whole history mysteriously
disappeared at that commit, and git whatchanged exited with 0 without
any error or warning... Though git log will show you all history, but
if you run it with -p then it will also exit with zero at this commit
silently like previously history do not exist at all. So, I didn't see
any reason to make git grep to work in the situation where practically
any other git command does not. I guess, they should be corrected too,
but I did not have time to look at them yet.
>
> It's not like the path is ever used to access a file, right?
>
> Maybe you should convert the path_buf to a strbuf instead.
It is probably a good suggestion, but I just wanted to provided a quick
fix to what may be considered as security issue. Of course, you usually
do not grep on untrusted repos, but if you did and something nasty
happened to you. I don't think it will help Git's reputation as being
secure and reliable...
Now the question is whether we really want to fix all Git commands that
do not touch the work tree to work with filenames longer than PATH_MAX?
Dmitry
next prev parent reply other threads:[~2008-07-16 11:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-16 10:15 [PATCH] Fix buffer overflow in git-grep Dmitry Potapov
2008-07-16 10:35 ` Johannes Schindelin
2008-07-16 11:54 ` Dmitry Potapov [this message]
2008-07-16 14:33 ` Dmitry Potapov
2008-07-16 14:47 ` Johannes Schindelin
2008-07-16 14:54 ` [PATCH] Fix buffer overflow in git diff Dmitry Potapov
2008-07-16 14:54 ` [PATCH] Fix buffer overflow in prepare_attr_stack Dmitry Potapov
2008-07-16 15:21 ` Johannes Sixt
2008-07-16 15:39 ` [PATCH v2] " Dmitry Potapov
2008-07-16 15:33 ` [PATCH v2] Fix buffer overflow in git-grep Dmitry Potapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080716115420.GD2925@dpotapov.dyndns.org \
--to=dpotapov@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).