Repository navigation
[security] CVE-2021-29921: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal #80565
Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2021-05-25.10:26:41.541>
created_at = <Date 2019-03-20.23:40:09.514>
labels = ['type-security', 'deferred-blocker', '3.8', '3.9', '3.10', 'library']
title = '[security] CVE-2021-29921: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal'
updated_at = <Date 2021-08-19.09:20:50.963>
user = 'https://github.com/TV4Fun'bugs.python.org fields:
activity = <Date 2021-08-19.09:20:50.963>
actor = 'lukasz.langa'
assignee = 'none'
closed = True
closed_date = <Date 2021-05-25.10:26:41.541>
closer = 'pablogsal'
components = ['Library (Lib)']
creation = <Date 2019-03-20.23:40:09.514>
creator = 'Joel Croteau'
dependencies = []
files = []
hgrepos = []
issue_num = 36384
keywords = ['patch', '3.8regression', '3.9regression']
message_count = 40.0
messages = ['338514', '338694', '339204', '339205', '339206', '339210', '339211', '339572', '389826', '389847', '390046', '390128', '390331', '390340', '390353', '390361', '392423', '392572', '392684', '392692', '392696', '392697', '394162', '394316', '394322', '394327', '394379', '394380', '394390', '399784', '399798', '399801', '399803', '399804', '399805', '399809', '399893', '399895', '399898', '399899']
nosy_count = 18.0
nosy_names = ['ncoghlan', 'vstinner', 'eric.smith', 'christian.heimes', 'ned.deily', 'pmoody', 'docs@python', 'lukasz.langa', 'mgorny', 'Julian', 'python-dev', 'serhiy.storchaka', 'steve.dower', 'pablogsal', 'miss-islington', 'Joel Croteau', 'gc2', 'achraf-mer']
pr_nums = ['12577', '25099', '25815', '27801', '27824', '27825', '27826', '27827']
priority = 'deferred blocker'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'security'
url = 'https://bugs.python.org/issue36384'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']
Activity
TV4Fun commentedon Mar 20, 2019
I understand to a certain extent the logic in not allowing IPv4 octets that might ambiguously be octal, but in practice, it just seems like it creates additional parsing hassle needlessly. I have never in many years of working on many networked systems seen anyone use dotted octal format, it is actually specifically forbidden by RFC 3986 (https://tools.ietf.org/html/rfc3986#section-7.4), and it means that the ipaddress module throws exceptions on many perfectly valid IP addresses just because they have leading zeroes. Since the module doesn't support dotted octal or dotted hex anyway, this check seems a little pointless. If nothing else, there should be a way to disable this check by specifying that your IPs are in fact dotted decimal, otherwise it seems like it's just making you have to do extra parsing work or just write your own implementation.
ericvsmith commentedon Mar 23, 2019
I agree that this is not a useful check.
ncoghlan commentedon Mar 30, 2019
New changeset e653d4d by Nick Coghlan (Joel Croteau) in branch 'master':
bpo-36384: Remove check for leading zeroes in IPv4 addresses (GH-12577)
e653d4d
ncoghlan commentedon Mar 30, 2019
I've merged the change for Python 3.8 (thanks Joel!).
I'm not sure whether to classify it as an enhancement or as an interoperability bug fix, though, so I've put the status to pending and added Ned to the nosy list to get his thoughts as the Python 3.7 RM.
ned-deily commentedon Mar 30, 2019
ipaddress is behaving as documented:
"The following constitutes a valid IPv4 address:
A string in decimal-dot notation, consisting of four decimal integers in the inclusive range 0–255, separated by dots (e.g. 192.168.0.1). Each integer represents an octet (byte) in the address. Leading zeroes are tolerated only for values less than 8 (as there is no ambiguity between the decimal and octal interpretations of such strings). [...]"
https://docs.python.org/3/library/ipaddress.html
I can sort of understand imposing that restriction in a Python 2 world where leading zeros implied octal and Python 3 outright rejects such forms of integers to avoid the ambiguity. That said, there's no particular reason why the components of an IPv4 string acceptable to ipaddress *have* to follow the same rules so I'm +0 on making the change at all. It's a bit of a stretch to consider it a bug when it appears to be behaving as documented but I would expect such a change to fix more problems than causing them so I'm OK if you want to backport it.
But, in any case, the documentation for 3.8 and/or 3.7 needs to be updated.
serhiy-storchaka commentedon Mar 30, 2019
See also the article "Ping and FTP Resolve IP Address with Leading Zero as Octal" (https://web.archive.org/web/20061206211851/http://support.microsoft.com/kb/115388).
This is still true in Windows 10.
So it is safer to reject IPv4 addresses with leading zeros that can be ambiguously interpreted. Otherwise this can create a security hole.
ericvsmith commentedon Mar 30, 2019
I think it should be 3.8 only, and the docs should be updated. Apologies for not catching that earlier: I searched via Google, which was a mistake.
ncoghlan commentedon Apr 7, 2019
The recommended handling in the article that Serhiy mentions is to strip the leading zeroes, which the ipaddress module will still do - it's only being made more tolerant on input. That means it will become usable as a prefilter step (pass string with potentially leading zeroes to ipaddress, get string with no leading zeroes out).
So that means the one part we missed is the docs update (together with a versionchanged note in the module docs themselves)
39 remaining items
ambv commentedon Aug 17, 2021
What do you mean by this?
Our understanding is that this is a low-severity CVE because in order for this to be a vulnerability, you'd have to have both:
Access to both then allows you at best to circumvent IP address-based access control or denial of service. However, access to just 1. allows you to input any IP address to achieve the same goals.
Hence low-severity.
It is a bona fide breaking change. Any IP address configuration saved in files or databases which might have used leading zeroes would be rejected by 3.8.12. The same was true for 3.9.5 but since this release series has much higher exposure (still receiving binary installers and regular-cadence bugfixes), it was less controversial to include it.
If you still feel this ought to be fixed in 3.8, please elaborate.
achraf-mer commentedon Aug 17, 2021
Even though I agree with you assessment on the root cause of the issue itself, it is listed as critical in https://nvd.nist.gov/vuln/detail/CVE-2021-29921, which means most commercial scan tools will also flag python 3.8 as critical, and this could prevent users from going with python 3.8 on production. (our case too)
IMHO I still think this should be solved in 3.8, otherwise there is really no other alternative but to upgrade to python 3.9 which is a hassle, since all 3.8.x are "critically vulnerable", had the CVE in https://nvd.nist.gov/vuln/detail/CVE-2021-29921 not been marked as critical, then we could have used python 3.8 knowing the two conditions you mentioned earlier.
ambv commentedon Aug 17, 2021
I was unaware of the "CRITICAL" base score assigned by NIST to this. Alright, let's port this back then. There are a few things the PR will need.
tiran commentedon Aug 17, 2021
"CRITICAL" is a ridiculous high assessment for this bug. Somebody ticked all the scary boxes in the CVSS form like "total loss of control".
tiran commentedon Aug 17, 2021
The CVE was rated https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H&version=3.1, which is equivalent to a RCE with authentication bypass.
I would rate the issue https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N&version=3.1, maybe A:L.
ambv commentedon Aug 17, 2021
New changeset 03dd89d by achraf-mer in branch '3.8':
[3.8] bpo-36384: Leading zeros in IPv4 addresses are no longer tolerated (GH-25099) (GH-27801)
03dd89d
ambv commentedon Aug 19, 2021
New changeset 6ebfe8d by Łukasz Langa in branch '3.8':
[3.8] bpo-36384: [doc] Correct typos in CVE-2021-29921 fix description (GH-27825)
6ebfe8d
ambv commentedon Aug 19, 2021
New changeset 0fd66e4 by Łukasz Langa in branch 'main':
bpo-36384: [doc] Mention CVE-2021-29921 fix in 3.8.12 (GH-27824)
0fd66e4
miss-islington commentedon Aug 19, 2021
New changeset 1204dfc by Miss Islington (bot) in branch '3.10':
bpo-36384: [doc] Mention CVE-2021-29921 fix in 3.8.12 (GH-27824)
1204dfc
ambv commentedon Aug 19, 2021
New changeset 9882025 by Miss Islington (bot) in branch '3.9':
bpo-36384: [doc] Mention CVE-2021-29921 fix in 3.8.12 (GH-27824) (GH-27827)
9882025