Fix email header manipulation issues #17262
Conversation
src/Mailer/Message.php
Outdated
| @@ -999,7 +999,7 @@ protected function formatAddress(array $address): array | |||
| $return[] = $email; | |||
| } else { | |||
| $encoded = $this->encodeForHeader($alias); | |||
| if (preg_match('/[^a-z0-9+\-\\=? ]/i', $encoded)) { | |||
| if ($encoded === $alias && preg_match('/[^a-z0-9+\-\\=? ]/i', $encoded)) { | |||
There was a problem hiding this comment.
Unfortunately this reintroduces the vulnerability. mb_encode_mimeheader sometimes splits the encoded string into encoded and not encoded pieces: "test ?test" results in "test =?UTF-8?B?P3Rlc3Q=?=". I don't know how the resulting string would be handled correctly according to the RFCs.
Looking at the PHPMailer project it seems they have their own encoding method that always encodes the whole string, see https://github.com/PHPMailer/PHPMailer/blob/e88da8d679acc3824ff231fdc553565b802ac016/src/PHPMailer.php#L3591C21-L3591C39.
There was a problem hiding this comment.
Encoding the entire address alias could be a solution for us as well then. I re-introduced this comparison because we would otherwise be putting encoded values in quoted strings which would then be treated as literal values and not encoded content.
There was a problem hiding this comment.
I took a look at the PHPMailer implementation and it doesn't correctly handle a scenario that is important to the CakePHP community which is encoding email headers in ISO-2022-JP encoding. I also re-read the RFC 2047 and my initial interpretation was wrong. I've reverted my changes.
markstory
force-pushed
the
email-header
branch
2 times, most recently
from
0afa021
to
4502ab2
Compare
If `Message` addresses are fed unvalidated user data, email recipients can be manipulated and other headers may be injected. This issue and patch were authored by Waldemar Bartikowski who reported the issue via our security mailing list.
markstory
force-pushed
the
email-header
branch
from
4502ab2
to
718ffe5
Compare
If
Messageaddresses are fed unvalidated user data, email recipients can be manipulated and other headers may be injected.This issue and patch were authored by Waldemar Bartikowski who reported the issue via our security mailing list.