Headline
CVE-2023-27043: Parsing errors in email/_parseaddr.py lead to incorrect value in email address part of tuple · Issue #102988 · python/cpython
The e-mail module of Python 0 - 2.7.18, 3.x - 3.11 incorrectly parses e-mail addresses which contain a special character. This vulnerability allows attackers to send messages from e-ail addresses that would otherwise be rejected.
Hello, I agree that not all of the cases being checked in the example python script are a problem. In the case of adding a , that is actually how a list of addresses is delimitated so for getaddresses() to return 2 address tuples is valid. However, parseaddr() is only for parsing a single address. So much so, that it is hard coded to only return the first element of the list returned by the parser return addrs[0]. The main solution for this in parseaddr() in my PR is to check if the returned list of parsed addresses is longer than one. The proposed solution in my PR for getaddresses() is to count the number of addresses which are in the input to be the same as the number of addresses returned by the parser. Additionally, it will check for a [ in the returned email address and replace that with an empty tuple instead. I even added all of the wacky address header examples from RFC 2822 to the test_email.py file. With my change in place, all valid inputs are still parsed correctly and all tests pass.
#102990
For all of the cases being checked, they all cause the parser to return both alice address and the bob address in the email address part of their own tuple. So, if the [email protected]([email protected] is a valid address followed by an incomplete comment, why should it return the incomplete comment in the email address part of it’s own tuple? When Golang parses that address it returns a parsing error <nil> mail: misformatted parenthetical comment
Python getaddresses() output which puts the misformatted parenthetical comment in the email address part of an additional tuple:
[('’, ‘[email protected]’), ('’, ‘[email protected]’)]
My feeling is that if what is put in the email address part of the tuple is not a valid email address, it should return a parsing error instead.
As for the attacks, the email address may not have actually come in via an email. For example, if users signup for an account with an email address, that email address may be put into a HTML form field. If parseaddr() is used to parse this and check the email address returned with a whitelist, it will check [email protected] and pass but signup emails would be sent to [email protected].
This was the case for the Tchap system
Tchap: The super (not) secure app of the French government
https://medium.com/@fs0c131y/tchap-the-super-not-secure-app-of-the-french-government-84b31517d144
The need to validate email addresses for things like account signup is very common practice. Even the company I work for allows for user signup with an email address, and we used parseaddr() to check the addresses with a blacklist. In retrospect, the attack examples I provided in the original post are not good. I should have described these 2 attacks instead. I agree that an email server can send whatever it likes in any of the email headers. However, in the case of account signup the attack only takes place if the email address is a valid email address where the attacker can receive the signup completion link.
Golang will return a parsing error indicating that when these headers are parsed they are returning more than a single address.
"Thomas Dwyer" <[email protected]> <nil>
<[email protected]> <nil>
<nil> mail: expected single address, got "<[email protected]>"
<nil> mail: misformatted parenthetical comment
<nil> mail: expected single address, got ")<[email protected]>"
<nil> mail: expected single address, got "<<[email protected]>"
<nil> mail: expected single address, got "><[email protected]>"
<nil> mail: expected single address, got "@<[email protected]>"
<nil> mail: expected single address, got ",[email protected]>"
<nil> mail: expected single address, got ":<[email protected]>"
<nil> mail: expected single address, got ";<[email protected]>"
"[email protected]." <[email protected]> <nil>
<nil> mail: expected single address, got "\"<[email protected]>"
<nil> mail: expected single address, got "[<[email protected]>"
<nil> mail: expected single address, got "]<[email protected]>"
<nil> mail: expected single address, got "<[email protected]>"Related news
Ubuntu Security Notice 7015-3 - USN-7015-1 fixed several vulnerabilities in Python. This update provides the corresponding updates for CVE-2023-27043 for python2.7 in Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, and Ubuntu 22.04 LTS, and for python3.5 in Ubuntu 16.04 LTS. It was discovered that the Python email module incorrectly parsed email addresses that contain special characters. A remote attacker could possibly use this issue to bypass certain protection mechanisms. It was discovered that Python allowed excessive backtracking while parsing certain tarfile headers. A remote attacker could possibly use this issue to cause Python to consume resources, leading to a denial of service. It was discovered that the Python email module incorrectly quoted newlines for email headers. A remote attacker could possibly use this issue to perform header injection. It was discovered that the Python http.cookies module incorrectly handled parsing cookies that contained backslashes for quot...
Ubuntu Security Notice 7015-1 - It was discovered that the Python email module incorrectly parsed email addresses that contain special characters. A remote attacker could possibly use this issue to bypass certain protection mechanisms. It was discovered that Python allowed excessive backtracking while parsing certain tarfile headers. A remote attacker could possibly use this issue to cause Python to consume resources, leading to a denial of service.
Red Hat Security Advisory 2024-0256-03 - An update for python3 is now available for Red Hat Enterprise Linux 8.
IBM Cognos Dashboards on Cloud Pak for Data 4.7.0 could allow a remote attacker to bypass security restrictions, caused by a reverse tabnabbing flaw. An attacker could exploit this vulnerability and redirect a victim to a phishing site. IBM X-Force ID: 262482.