Skip to content

Commit 03dd89d

Browse files
achraf-merambv
andauthored
[3.8] bpo-36384: Leading zeros in IPv4 addresses are no longer tolerated (GH-25099) (GH-27801)
Reverts commit e653d4d and makes parsing even more strict. Like socket.inet_pton() any leading zero is now treated as invalid input. Signed-off-by: Christian Heimes <[email protected]> Co-authored-by: Łukasz Langa <[email protected]>
1 parent d7f5796 commit 03dd89d

File tree

5 files changed

+57
-6
lines changed

5 files changed

+57
-6
lines changed

Doc/library/ipaddress.rst

Lines changed: 13 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -104,8 +104,7 @@ write code that handles both IP versions correctly. Address objects are
104104
1. A string in decimal-dot notation, consisting of four decimal integers in
105105
the inclusive range 0--255, separated by dots (e.g. ``192.168.0.1``). Each
106106
integer represents an octet (byte) in the address. Leading zeroes are
107-
tolerated only for values less than 8 (as there is no ambiguity
108-
between the decimal and octal interpretations of such strings).
107+
not tolerated to prevent confusion with octal notation.
109108
2. An integer that fits into 32 bits.
110109
3. An integer packed into a :class:`bytes` object of length 4 (most
111110
significant octet first).
@@ -117,6 +116,18 @@ write code that handles both IP versions correctly. Address objects are
117116
>>> ipaddress.IPv4Address(b'\xC0\xA8\x00\x01')
118117
IPv4Address('192.168.0.1')
119118

119+
120+
.. versionchanged:: 3.8
121+
122+
Leading zeros are tolerated, even in ambiguous cases that look like
123+
octal notation.
124+
125+
.. versionchanged:: 3.8.12
126+
127+
Leading zeros are no longer tolerated and are treated as an error.
128+
IPv4 address strings are now parsed as strict as glibc
129+
:func:`~socket.inet_pton`.
130+
120131
.. attribute:: version
121132

122133
The appropriate version number: ``4`` for IPv4, ``6`` for IPv6.

Doc/whatsnew/3.8.rst

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2307,3 +2307,19 @@ URL by the parser in :mod:`urllib.parse` preventing such attacks. The removal
23072307
characters are controlled by a new module level variable
23082308
``urllib.parse._UNSAFE_URL_BYTES_TO_REMOVE``. (See :issue:`43882`)
23092309

2310+
2311+
Notable changes in Python 3.8.12
2312+
================================
2313+
2314+
Changes in the Python API
2315+
-------------------------
2316+
2317+
Starting with Python 3.8.12 the :mod:`ipaddress` module no longer accepts
2318+
any leading zeros in IPv4 address strings. Leading zeros are ambiguous and
2319+
interpreted as octal notation by some libraries. For example the legacy
2320+
function :func:`socket.inet_aton` treats leading zeros as octal notatation.
2321+
glibc implementation of modern :func:`~socket.inet_pton` does not accept
2322+
any leading zeros.
2323+
2324+
(Originally contributed by Christian Heimes in :issue:`36384`, and backported
2325+
to 3.8 by Achraf Merzouki)

Lib/ipaddress.py

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1173,6 +1173,11 @@ def _parse_octet(cls, octet_str):
11731173
if len(octet_str) > 3:
11741174
msg = "At most 3 characters permitted in %r"
11751175
raise ValueError(msg % octet_str)
1176+
# Handle leading zeros as strict as glibc's inet_pton()
1177+
# See security bug bpo-36384
1178+
if octet_str != '0' and octet_str[0] == '0':
1179+
msg = "Leading zeros are not permitted in %r"
1180+
raise ValueError(msg % octet_str)
11761181
# Convert to integer (we know digits are legal)
11771182
octet_int = int(octet_str, 10)
11781183
if octet_int > 255:

Lib/test/test_ipaddress.py

Lines changed: 17 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -97,10 +97,23 @@ def pickle_test(self, addr):
9797
class CommonTestMixin_v4(CommonTestMixin):
9898

9999
def test_leading_zeros(self):
100-
self.assertInstancesEqual("000.000.000.000", "0.0.0.0")
101-
self.assertInstancesEqual("192.168.000.001", "192.168.0.1")
102-
self.assertInstancesEqual("016.016.016.016", "16.16.16.16")
103-
self.assertInstancesEqual("001.000.008.016", "1.0.8.16")
100+
# bpo-36384: no leading zeros to avoid ambiguity with octal notation
101+
msg = "Leading zeros are not permitted in '\d+'"
102+
addresses = [
103+
"000.000.000.000",
104+
"192.168.000.001",
105+
"016.016.016.016",
106+
"192.168.000.001",
107+
"001.000.008.016",
108+
"01.2.3.40",
109+
"1.02.3.40",
110+
"1.2.03.40",
111+
"1.2.3.040",
112+
]
113+
for address in addresses:
114+
with self.subTest(address=address):
115+
with self.assertAddressError(msg):
116+
self.factory(address)
104117

105118
def test_int(self):
106119
self.assertInstancesEqual(0, "0.0.0.0")
Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
:mod:`ipaddress` module no longer accepts any leading zeros in IPv4 address
2+
strings. Leading zeros are ambiguous and interpreted as octal notation by
3+
some libraries. For example the legacy function :func:`socket.inet_aton`
4+
treats leading zeros as octal notatation. glibc implementation of modern
5+
:func:`~socket.inet_pton` does not accept any leading zeros. For a while
6+
the :mod:`ipaddress` module used to accept ambiguous leading zeros.

0 commit comments

Comments
 (0)