[issue34155] email.utils.parseaddr mistakenly parse an email

STINNER Victor added the comment: I reopen the issue since Python 2.7 is still vulnerable. -- resolution: fixed -> status: closed -> open ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

Riccardo Schirone added the comment: CVE-2019-16056 has been assigned to this issue. See https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16056 . -- nosy: +rschiron ___ Python tracker

[issue34155] email.utils.parseaddr mistakenly parse an email

Larry Hastings added the comment: All PRs merged. Thanks, everybody! -- resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

Larry Hastings added the comment: New changeset 063eba280a11d3c9a5dd9ee5abe4de640907951b by larryhastings (Abhilash Raj) in branch '3.5': [3.5] bpo-34155: Dont parse domains containing @ (GH-13079) (#15317) https://github.com/python/cpython/commit/063eba280a11d3c9a5dd9ee5abe4de640907951b

[issue34155] email.utils.parseaddr mistakenly parse an email

Łukasz Langa added the comment: Downgraded the severity since 3.6 - 3.9 are merged. -- nosy: +lukasz.langa priority: deferred blocker -> critical ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

Abhilash Raj added the comment: 2.7 needs a separate PR since the code is very different and my familiarity with 2.7 version of email package is very limited. I am going to work on a separate patch later this week for 2.7. -- ___ Python tracker

[issue34155] email.utils.parseaddr mistakenly parse an email

STINNER Victor added the comment: > Created a backport PR for 3.5. Thanks. I reviewed it (LGTM). What about Python 2.7, it's also vulnerable, no? -- ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

Abhilash Raj added the comment: Created a backport PR for 3.5. -- stage: patch review -> resolved ___ Python tracker ___ ___

[issue34155] email.utils.parseaddr mistakenly parse an email

Change by Abhilash Raj : -- pull_requests: +15036 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/15317 ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

Kyle Stanley added the comment: > This is already backported to 3.6. I am not sure about what gets backported > to 3.5 right now, I don't even see a 'Backport to 3.5' label on Github (which > made me think we are discouraged to backport to 3.5). I can work on a manual > backport if needed?

[issue34155] email.utils.parseaddr mistakenly parse an email

Abhilash Raj added the comment: @Victor: This is already backported to 3.6. I am not sure about what gets backported to 3.5 right now, I don't even see a 'Backport to 3.5' label on Github (which made me think we are discouraged to backport to 3.5). I can work on a manual backport if needed?

[issue34155] email.utils.parseaddr mistakenly parse an email

STINNER Victor added the comment: This issue is a security issue so Python 2.7, 3.5, 3.6 should also be fixed, no? -- status: closed -> open versions: +Python 2.7, Python 3.5, Python 3.6 ___ Python tracker

[issue34155] email.utils.parseaddr mistakenly parse an email

STINNER Victor added the comment: I change the issue type to security because of https://bugs.python.org/issue34155#msg340534: "Note that this bug was used in an actual security attack so it is serious". -- type: behavior -> security ___ Python

[issue34155] email.utils.parseaddr mistakenly parse an email

Abhilash Raj added the comment: Closing this since teh PRs are merged. -- stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

Ned Deily added the comment: New changeset 13a19139b5e76175bc95294d54afc9425e4f36c9 by Ned Deily (Miss Islington (bot)) in branch '3.6': bpo-34155: Dont parse domains containing @ (GH-13079) (GH-14826) https://github.com/python/cpython/commit/13a19139b5e76175bc95294d54afc9425e4f36c9

[issue34155] email.utils.parseaddr mistakenly parse an email

miss-islington added the comment: New changeset 217077440a6938a0b428f67cfef6e053c4f8673c by Miss Islington (bot) in branch '3.8': bpo-34155: Dont parse domains containing @ (GH-13079) https://github.com/python/cpython/commit/217077440a6938a0b428f67cfef6e053c4f8673c --

[issue34155] email.utils.parseaddr mistakenly parse an email

miss-islington added the comment: New changeset c48d606adcef395e59fd555496c42203b01dd3e8 by Miss Islington (bot) in branch '3.7': bpo-34155: Dont parse domains containing @ (GH-13079) https://github.com/python/cpython/commit/c48d606adcef395e59fd555496c42203b01dd3e8 --

[issue34155] email.utils.parseaddr mistakenly parse an email

Change by miss-islington : -- pull_requests: +14620 pull_request: https://github.com/python/cpython/pull/14826 ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

Change by miss-islington : -- pull_requests: +14618 pull_request: https://github.com/python/cpython/pull/14824 ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

miss-islington added the comment: New changeset 8cb65d1381b027f0b09ee36bfed7f35bb4dec9a9 by Miss Islington (bot) (jpic) in branch 'master': bpo-34155: Dont parse domains containing @ (GH-13079) https://github.com/python/cpython/commit/8cb65d1381b027f0b09ee36bfed7f35bb4dec9a9 --

[issue34155] email.utils.parseaddr mistakenly parse an email

Change by miss-islington : -- pull_requests: +14619 pull_request: https://github.com/python/cpython/pull/14825 ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

jpic added the comment: Thanks for the kind words Cyril, sorry that this patch doesn't address exactly the issue that you have described initially, but rather the security issue related to it. The exception depending on the parsing issue is already supported by the new API, although it's

[issue34155] email.utils.parseaddr mistakenly parse an email

Cyril Nicodème added the comment: This thread has been really interesting to follow, I'm glad to have opened it :) I would agree with Barry here, it should follow the documentation. BUT, I would suggest to add a "strict" parameter that would throw exceptions depending on the parsing issue

[issue34155] email.utils.parseaddr mistakenly parse an email

Barry A. Warsaw added the comment: I still think the only way to read the documentation for parseaddr('a@b@c') is to return ('', '') - a tuple of empty strings. The documentations says: "Returns a tuple of that information, unless the parse fails, in which case a 2-tuple of ('', '') is

[issue34155] email.utils.parseaddr mistakenly parse an email

Abhilash Raj added the comment: slight typo in the previous message: s/fallback to `get_unstructured` /fallback to *something*/g -- ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

Abhilash Raj added the comment: I agree that we currently abandon parsing (raise `HeaderParseError`) when we encounter a unexpected token when parsing domain (expected token is dot-atom-text). However, that mechanism is meant to signal the higher level parser that we should look for a

[issue34155] email.utils.parseaddr mistakenly parse an email

jpic added the comment: Thanks for your explanation, but in perspective with other invalid domains, such as "foo." currently resulting in an empty string too: >>> email.message_from_string('From: >>> a@foo.',policy=email.policy.default)['from'].addresses[0].domain '' Do you think this

[issue34155] email.utils.parseaddr mistakenly parse an email

Abhilash Raj added the comment: I don't know if we can make the API consistent between parseaddr and the parsing header value since they are completely different even right now. Like you already noticed there is no way to register defects and instead parseaddr returns ('', '') to denote the

[issue34155] email.utils.parseaddr mistakenly parse an email

jpic added the comment: The email API does error recovery without loading invalid domains into the domain variable which could lead to dangerous situations, example with "a@foo.": >>> email.message_from_string('From: >>> a@foo.',policy=email.policy.default)['from'].addresses[0].domain '' In

[issue34155] email.utils.parseaddr mistakenly parse an email

Abhilash Raj added the comment: How about we go a slightly different route than suggested by jpic and instead of returning a None value, we return the entire rest of the string as the domain? That would take care of the security issue since it won't be a valid domain anymore. msg =

[issue34155] email.utils.parseaddr mistakenly parse an email

jpic added the comment: At is allowed in the local part if quoted, the proposed patch acts within get_domain() and getdomain() and does not affect local part parsing. This still works: >>> parseaddr('"fo@bar"@bar.com') ('', '"fo@bar"@bar.com') >>> email.message_from_string('From:

[issue34155] email.utils.parseaddr mistakenly parse an email

Windson Yang added the comment: Frome the answer from Alnitak (https://stackoverflow.com/questions/12355858/how-many-symbol-can-be-in-an-email-address). Maybe we should raise an error when the address has multiple @ in it. -- ___ Python tracker

[issue34155] email.utils.parseaddr mistakenly parse an email

jpic added the comment: The pull request has been updated to mimic net/mail's behavior rather than trying to workaround user input. Before: >>> email.message_from_string('From: a...@malicious.org@important.com', policy=email.policy.default)['from'].addresses (Address(display_name='',

[issue34155] email.utils.parseaddr mistakenly parse an email

jpic added the comment: I haven't found this specific case in an RFC, but checked Go's net/mail library behavior and it just considers it broken: $ cat mail.go package main import "fmt" import "net/mail" func main() { fmt.Println(({}).Parse("a...@example.com"))

[issue34155] email.utils.parseaddr mistakenly parse an email

Change by Roundup Robot : -- keywords: +patch pull_requests: +12994 stage: -> patch review ___ Python tracker ___ ___

[issue34155] email.utils.parseaddr mistakenly parse an email

Barry A. Warsaw added the comment: Well, at least we're not alone. Here's a screen capture from Mail.app Version 12.4 (3445.104.8). -- Added file: https://bugs.python.org/file48295/Screen Shot 2019-05-02 at 22.07.27.png ___ Python tracker

[issue34155] email.utils.parseaddr mistakenly parse an email

Windson Yang added the comment: I found the issue located in https://github.com/python/cpython/blob/master/Lib/email/_parseaddr.py#L277 elif self.field[self.pos] in '.@': # email address is just an addrspec # this isn't very efficient since we start over self.pos = oldpos

[issue34155] email.utils.parseaddr mistakenly parse an email

Ned Deily added the comment: @barry, @r.david.murray, With the additional info about attacks in the wild, should we now consider this a security issue? If so, someone needs to provide an actual PR. (Raising the priority to "deferred blocker" pending evaluation.) -- nosy:

[issue34155] email.utils.parseaddr mistakenly parse an email

Change by Jakub Wilk : -- nosy: -jwilk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34155] email.utils.parseaddr mistakenly parse an email

Dain Dwarf added the comment: Hello, kind of new here. I just wanted to note that the issue that lead to Tchap's security attack still exists in the non-deprecated message_from_string function: email.message_from_string('From: a...@malicious.org@important.com',

[issue34155] email.utils.parseaddr mistakenly parse an email

Jamesie Pic added the comment: Given the situation, could raising a SecurityWarning and a DeprecationWarning fix this issue ? -- nosy: +Jamesie Pic ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34155] email.utils.parseaddr mistakenly parse an email

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34155] email.utils.parseaddr mistakenly parse an email

Change by Nicolas Évrard : -- nosy: +nicoe ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34155] email.utils.parseaddr mistakenly parse an email

Karthikeyan Singaravelan added the comment: Relevant attack from matrix blog post. https://matrix.org/blog/2019/04/18/security-update-sydent-1-0-2/ > sydent uses python's email.utils.parseaddr function to parse the input email > address before sending validation mail to it, but it turns out

[issue34155] email.utils.parseaddr mistakenly parse an email

Stéphane Bortzmeyer added the comment: Note that this bug was used in an actual security attack so it is serious https://medium.com/@fs0c131y/tchap-the-super-not-secure-app-of-the-french-government-84b31517d144 https://twitter.com/fs0c131y/status/1119143946687434753 -- nosy:

[issue34155] email.utils.parseaddr mistakenly parse an email

Kal Sze added the comment: Another failure case: >>> from email.utils import parseaddr >>> parseaddr('fo@o...@bar.com') ('', 'fo@o') If I understand the RFC correctly, the correct results should be ('', '') because there are two '@' signs. The first '@' would need to be quoted for the

[issue34155] email.utils.parseaddr mistakenly parse an email

Karthikeyan Singaravelan added the comment: Ah sorry, I was typing so long and had an idle session that I didn't realize @r.david.murray added a comment with the explanation. Just to add I tried using Perl module (https://metacpan.org/release/Email-Address) that uses regex for parsing that

[issue34155] email.utils.parseaddr mistakenly parse an email

Mark Sapiro added the comment: I agree that my example with an @ in the 'display name', although actually seen in the wild, is non-compliant, and that the behavior of parseaddr() in this case is not a bug. Sorry for the noise. -- ___ Python

[issue34155] email.utils.parseaddr mistakenly parse an email

Karthikeyan Singaravelan added the comment: Is this a case of realname having @ inside an unquoted string? As I can see from the RFC the acceptable characters of an atom other than alphabets and digits that comprises a phrase are ['!', '#', '$', '%', '&', "'", '*', '+', '-', '/', '=', '?',

[issue34155] email.utils.parseaddr mistakenly parse an email

R. David Murray added the comment: The formatting of that doctest paragraph got messed up. Let me try again: >>> m = message_from_string("From: John Doe j...@example.com \n\n", policy=default) >>> m['From'].addresses (Address(display_name='', username='John Doe jdoe',

[issue34155] email.utils.parseaddr mistakenly parse an email

R. David Murray added the comment: >>> m = message_from_string("From: John Doe j...@example.com >>> \n\n", policy=default) >>> m['From'].addresses(Address(display_name='', username='John Doe jdoe', domain='example.com'),) The new policies have more error recovery for non-RFC compliant

[issue34155] email.utils.parseaddr mistakenly parse an email

Mark Sapiro added the comment: The issue is illustrated much more simply as follows: email.utils.parseaddr('John Doe j...@example.com ') returns ('', 'John Doe j...@example.com') whereas it should return ('John Doe j...@example.com', 'ot...@example.net') I'll look at developing a patch.

[issue34155] email.utils.parseaddr mistakenly parse an email

Jakub Wilk added the comment: You should not use decode_header() on the whole From header, because that loses information. You should parse the header first, then decode the parts that could be RFC2047-encoded. Quoting : > NOTE: Decoding and

[issue34155] email.utils.parseaddr mistakenly parse an email

R. David Murray added the comment: Ah, maybe it doesn't handle it completely correctly; that decode looks different now that I look at it in detail. -- ___ Python tracker

[issue34155] email.utils.parseaddr mistakenly parse an email

R. David Murray added the comment: Oops, I left out a step in that cut and paste. For completeness: >>> x = x[3:] -- ___ Python tracker ___

[issue34155] email.utils.parseaddr mistakenly parse an email

R. David Murray added the comment: That does appear to be a bug. Note that the new email API handles it correctly: >>> x = """ ... > From: =?utf-8?Q?z...@redacted.com.cn=E3=82=86=E2=86=91=E3=82=86?= ... =?utf-8?Q?=E3=82=83=E3=82=85=E3=81=87=E3=81=BA=E3=81=BD=E3=81=BC"\=E3?=

[issue34155] email.utils.parseaddr mistakenly parse an email

New submission from Cyril Nicodème : Hi! I'm trying to parse some emails, and I discovered that email.utils.parseaddr wrongly parse an email. Here's the corresponding header: > From: =?utf-8?Q?z...@redacted.com.cn=E3=82=86=E2=86=91=E3=82=86?=