Skip to content

Fix out-of-bounds reads when parsing some malformed headers#9

Merged
jstedfast merged 4 commits into
jstedfast:masterfrom
jwilk-forks:oob
Jul 31, 2017
Merged

Fix out-of-bounds reads when parsing some malformed headers#9
jstedfast merged 4 commits into
jstedfast:masterfrom
jwilk-forks:oob

Conversation

@jwilk

@jwilk jwilk commented Jul 30, 2017

Copy link
Copy Markdown
Contributor

This fixes multiple bugs that made GMime read past the terminating null byte.

Reproducer:

From: <@[0
To: 0@[
Subject: =??
Content-Type: text/plain; charset="\

Found using American Fuzzy Lop.

jwilk added 4 commits July 30, 2017 23:21
If a malformed address ended right after dtext, the original code would
jump over the terminating null byte.
If a malformed address ended right after dtext, the original code would
read past the terminating null byte.
strchr("BbQq", ...) was meant to check for these four characters, but
it returns true also for the null byte.

If a header ended with the "=?<charset>?" sequence, the original code
would read past the terminating null byte.
If a malformed header ended right after backslash, the original code
would jump over the terminating null byte.
@coveralls

Copy link
Copy Markdown

Coverage Status

Coverage decreased (-0.04%) to 56.221% when pulling c34f418 on jwilk-forks:oob into b29c54c on jstedfast:master.

@jstedfast
jstedfast merged commit f65a15a into jstedfast:master Jul 31, 2017
Comment thread gmime/internet-address.c
do {
while (is_dtext (*inptr))
while (*inptr && is_dtext (*inptr))
g_string_append_c (str, *inptr++);

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

I wonder if is_dtext() could be fixed to bail on '\0'

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.

3 participants