The critical IP address validation vulnerability in the Python standard library ipaddress is similar to the bug that was discovered in the "netmask" library earlier this year.
The researchers who discovered the crucial flaw in netmask also found the same flaw in this Python module and named it the CVE-2021-29921 identifier.
BleepingComputer first posted on a crucial IP validation flaw in the netmask library, which is used by thousands of applications, in March.
The vulnerability tracked as CVE-2021-28918 (Critical), CVE-2021-29418 (Medium), and CVE-2021-29424 (High), was found in both the npm and Perl versions of netmask, as well as some other related libraries.
According to Victor Viale, Sick Codes, Kelly Kaoudis, John Jackson, and Nick Sahler, the ipaddress standard library implemented in Python 3.3 is also affected by this vulnerability. The bug, labeled CVE-2021-29921, affects the ipaddress standard library's inappropriate parsing of IP addresses.
The ipaddress module in Python enables developers to quickly construct IP addresses, networks, and interfaces, as well as parse and normalize IP addresses in various formats.
An IPv4 address can be expressed in a number of ways, including decimal, integer, octal, and hexadecimal, though decimal is the most common.
The IPv4 address of BleepingComputer, for example, is 104.20.59.209 in decimal format, but it can also be expressed in the octal format as 0150.0024.0073.0321. When typed 0127.0.0.1/ into Chrome's address bar, the browser treats the entire string as an IP address in octal format, according to BleepingComputer's tests.
The IP address switches to its decimal equivalent of 87.0.0.1 when you press enter or return, which is how most applications are expected to handle ambiguous IP addresses.
The fact that 127.0.0.1 is a loopback address rather than a public IP address is noteworthy; however, its ambiguous representation converts it to a public IP address that points to a different host entirely.
Sections of an IPv4 address can be interpreted as octal if prefixed with a "0," according to the IETF's original specification for ambiguous IP addresses. Any leading zeros in the Python standard library ipaddress, on the other hand, will be stripped and discarded.
Researchers Sick Codes and Victor Viale demonstrated that Python's ipaddress library can simply discard any leading zeroes in a proof-of-concept test. In other words, '010.8.8.8' will be treated as '10.8.8.8' by Python's ipaddress module, rather than '8.8.8.8'.
"Improper input validation of octal strings in Python 3.8.0 thru v3.10 stdlib ipaddress allows unauthenticated remote attackers to perform indeterminate [Server-Side Request Forgery (SSRF), Remote File Inclusion (RFI), and Local File Inclusion (LFI) attacks] on many programs that rely on Python stdlib IP address," stated the researchers.
A discussion had shortly followed among Python maintainers as to the reasons behind this commit, and practical reasons for introducing this change when it came to handling ambiguous IP addresses. Although discussions about an upcoming patch are ongoing, exact details on what version of Python will it contain are fuzzy.
On the other hand, one of the Python maintainers Victor Stinner said:
"Passing IPv4 addresses with leading zeros is rare. You don't have to change the [sic] IP address for that, you can pre-process your inputs: it works on any Python version with or without the patch," suggesting an alternative solution to the issue.
