Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StackOverflowException upon parsing malformed message #355

Closed
MannyDustbeard opened this issue Nov 16, 2017 · 5 comments
Closed

StackOverflowException upon parsing malformed message #355

MannyDustbeard opened this issue Nov 16, 2017 · 5 comments
Labels
bug Something isn't working

Comments

@MannyDustbeard
Copy link

When malformed message is loaded, StackOverflowException occurs. Expected behavior is to throw a regular exception that can be handed by code. StackOverflowException terminates running application and there is no way to recover.

var path = @"StackOverflowMimeMessageExample.txt";
using (var reader = File.OpenRead(path))
{
    // This works
    var headers = HeaderList.Load(reader);
    reader.Seek(0, SeekOrigin.Begin);

    // This throws StackOverflowException and causes process teardown
    var msg = MimeMessage.Load(reader);
}

Below is StackOverflow message example :

StackOverflowMimeMessageExample.txt

@jstedfast jstedfast added the invalid This doesn't seem right label Nov 16, 2017
@jstedfast
Copy link
Owner

Are you sure? Because I just compiled and ran your code and it worked fine w/o any stack overflow exceptions.

I tried your StackOverflowMimeMessageExample.txt file in both Unix format and DOS format. Same results, no stack overflow.

@jstedfast jstedfast added bug Something isn't working and removed invalid This doesn't seem right labels Nov 16, 2017
@jstedfast
Copy link
Owner

If I duplicated the To header 10x, it finally crashed for me.

The problem is that the ':' inside of the encoded word tokens is not only invalid (not allowed within encoded-word tokens in address headers), it also signifies to the parser that everything preceding the ':' is the name of an address group and everything after it is a list of addresses.

Since group addresses can be recursive and the fact that it was a string of date strings, each digit in the date signified the name of a new group and it recursed forever and ever, eventually causing a stack overflow.

I'm adding a new ParserOptions property called MaxAddressGroupDepth (with a default value of 3 I think) that will prevent the parser from recursing these types of addresses more than X number of times before bailing out.

@MannyDustbeard
Copy link
Author

I noticed that exception if thrown much quicker on Windows/.NET and on Linux it just needs more malformed lines in the header, like you noticed too. Thank you for the quick solution!

@peteroupc
Copy link

Under RFC 5322 section 3.4, group syntax can't even be recursive -- groups within groups are not allowed in header fields that allow group syntax.

@jstedfast
Copy link
Owner

@peteroupc You are indeed correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants