For more detail on the research which lead me to find this issue, please see:

https://gist.github.com/ndavison/a495de6dce836dcb035f751f8e340599

This is a secret Gist of a blog post I intend to publish at some point. This Gist URL is also currently in the possession of AWS Security (in regards to the fact SES processes the payload as a valid email address) - please do not share this URL outside of the immediate PHP security group (I suspect I didn't need to say this, but just to be sure :)).

<aaa@bbb.com> is interpreted as route-addr, a concept that is well
defined in RFC 822 (but already discouraged there, and dropped
from RFC 2822).  It is not quite valid as route-addr, because at
least one phrase would have to come before the "<", but since
mailparse's parsing is liberal, that's not a bug per se.

What is rather suprising to me, though, is that such route-addrs
are added as addresses without any further indication (e.g. by
having another boolean field "is_route_address" or such).

Another potential security impact of how the payload is parsed by mailparse_rfc822_parse_addresses is what I touched on regarding the absence of commas - after confirming the string doesn't contain a comma, a developer may pass the returning Array directly to a mail API which accepts an Array for the 'to' addresses thinking there can only be one address, however the response from mailparse_rfc822_parse_addresses contains two when given this payload.

I may be missing something in the RFC(s) when making the assumption that no comma means it's safe to assume only one address is present.

Doesn't look like security issue. mailparse_rfc822_parse_addresses() is clearly documented as returning multiple addresses, its return type is array. Of course, for any bug, a scenario can be contrived where security function could depend on this bug not being present, but this alone is not enough to classify every bug as security issue.

I agree security scenarios can be contrived for basically any bug, but in this case I believe any instance where a developer sends a string into an email function they reasonably ensured is only 1 address, and it spits out 2, that could be particularly problematic for an app's security posture (as email is often linked to sensitive information or identity/auth(z) functionality).

This is a bit unrelated to the original bug (similar threat, different payload), but I've also noticed that mailparse_rfc822_parse_addresses will terminate at a null byte (without error) which could allow an attacker to get an email on one domain but the rest of the PHP code may treat the string to be another domain. Snippet for this:

$ php -r 'print_r(mailparse_rfc822_parse_addresses("aaa@bbb.com\x00.ddd.com"));'
Array
(
    [0] => Array
        (
            [display] => aaa@bbb.com
            [address] => aaa@bbb.com
            [is_group] => 
        )

)

This wouldn't really be a problem if the output of mailparse_rfc822_parse_addresses is used for both determining the address for app logic and for the mail server, but if for some reason this was only used for one of those, then it could result in vulnerabilities.

Should I open a new bug for this?

That's definitely a separate issue, though I am not sure whether it's a bug... mailparse_rfc822_parse_addresses() does not promise you to validate strings as email addresses. So if you're using it in security-sensitive context as validator, you are probably doing it wrong. You should use whitelist filter instead. Probably something like FILTER_VALIDATE_EMAIL.

Hi there,

I was looking to publish the writeup I linked to earlier which references this bug. I note that some comments here suggest this is not being treated as a security issue - does this indicate that you would be okay for me to publish the writeup?

I have confirmed from AWS that they are not treating the parsing of the <x@y.com>a@b.com payload as a valid address as a security issue so there is no need for this to remain private from my perspective.