From: mkoegler@auto.tuwien.ac.at (Martin Koegler)
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: input validation in receive-pack
Date: Tue, 1 Jan 2008 22:34:51 +0100 [thread overview]
Message-ID: <20080101213451.GA26772@auto.tuwien.ac.at> (raw)
In the function "static const char *update(struct command *cmd)" in
receive-pack.c:
| if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
| !is_null_sha1(old_sha1) &&
| !prefixcmp(name, "refs/heads/")) {
| struct commit *old_commit, *new_commit;
| struct commit_list *bases, *ent;
|
| old_commit = (struct commit *)parse_object(old_sha1);
| new_commit = (struct commit *)parse_object(new_sha1);
| bases = get_merge_bases(old_commit, new_commit, 1);
| for (ent = bases; ent; ent = ent->next)
| if (!hashcmp(old_sha1, ent->item->object.sha1))
| break;
| free_commit_list(bases);
| if (!ent) {
| error("denying non-fast forward %s"
| " (you should pull first)", name);
| return "non-fast forward";
| }
| }
As far as I understand the code, it assumes, that sha1 values provided
by the client really point to a commit. Shouldn't there be a check for
the object type?
Some lines above:
| if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
| error("refusing to create funny ref '%s' remotely", name);
| return "funny refname";
| }
Is this code really correct? All refnames starting with "refs/" may
only contain allowed characters, while all other may contain any
characters (except \0 and \n)?
For the updating code path, lock_any_ref_for_update calls
check_ref_format, so the error will happen latter. For the delete code
path, the refname seems not to be checked.
In the update code path, the check is done in refs.c:
| struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1, int flags)
| {
| if (check_ref_format(ref) == -1)
| return NULL;
| return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
| }
check_ref_format may also return -2 (less than two name levels) and -3
(* at the end), which are ignored. Is it really intended, that
receive-pack can create such refs.
mfg Martin Kögler
next reply other threads:[~2008-01-01 21:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-01 21:34 Martin Koegler [this message]
2008-01-02 3:07 ` input validation in receive-pack Junio C Hamano
2008-01-02 5:01 ` Daniel Barkalow
2008-01-02 5:46 ` Junio C Hamano
2008-01-02 15:53 ` Daniel Barkalow
2008-01-02 19:14 ` Junio C Hamano
2008-01-02 7:51 ` Martin Koegler
2008-01-02 8:01 ` Junio C Hamano
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=20080101213451.GA26772@auto.tuwien.ac.at \
--to=mkoegler@auto.tuwien.ac.at \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).