Object parsing hardening by pks-t · Pull Request #3956 · libgit2/libgit2 · GitHub
Skip to content

Object parsing hardening#3956

Merged
ethomson merged 2 commits into
libgit2:masterfrom
pks-t:pks/object-parsing-hardening
Oct 9, 2016
Merged

Object parsing hardening#3956
ethomson merged 2 commits into
libgit2:masterfrom
pks-t:pks/object-parsing-hardening

Conversation

@pks-t

@pks-t pks-t commented Oct 7, 2016

Copy link
Copy Markdown
Member

See the commit messages for more info. These commits fix #3936 and #3937. I bet there are more issues around here which I'd like to find. I think I'll try some more fuzzing with AFL around the object-parsing logic sometimes soon.

When parsing tree entries from raw object data, we do not verify
that the tree entry actually has a filename as well as a valid
object ID. Fix this by asserting that the filename length is
non-zero as well as asserting that there are at least
`GIT_OID_RAWSZ` bytes left when parsing the OID.
@pks-t

pks-t commented Oct 7, 2016

Copy link
Copy Markdown
Member Author

Comment thread src/commit.c Outdated
GITERR_CHECK_ALLOC(commit->raw_message);
} else {
commit->raw_message = git__strdup("");
GITERR_CHECK_ALLOC(commit->raw_message);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tiny nitpick: This line could be moved beneath the if/else blocks.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, agreed, realized the same after posting this PR. Will change

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Thanks for your careful eyes

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

When parsing a commit, we will treat all bytes left after parsing
the headers as the commit message. When no bytes are left, we
leave the commit's message uninitialized. While uncommon to have
a commit without message, this is the right behavior as Git
unfortunately allows for empty commit messages.

Given that this scenario is so uncommon, most programs acting on
the commit message will never check if the message is actually
set, which may lead to errors. To work around the error and not
lay the burden of checking for empty commit messages to the
developer, initialize the commit message with an empty string
when no commit message is given.
@pks-t pks-t force-pushed the pks/object-parsing-hardening branch from 594a409 to a719ef5 Compare October 9, 2016 11:27
@ethomson ethomson merged commit aae8953 into libgit2:master Oct 9, 2016
@ethomson

ethomson commented Oct 9, 2016

Copy link
Copy Markdown
Member

@pks-t pks-t deleted the pks/object-parsing-hardening branch October 10, 2016 07:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Read out-of-bounds in git_oid_nfmt

3 participants