requests.utils function accepts invalid ip/cidr input

[disconnect3d]

TLDR: On some libc implementations (e.g. glibc) the socket.inet_aton function parses IP strings trailed with whitespace and garbage, and this function is used by requests utility functions which if used externally, may cause bugs or/and security vulnerabilities.

An example of the issue can be seen below:

I have written a more detailed description of the socket.inet_aton's underlying problem on Python's bugtracker issue 37495. It is yet to be decided if this is going to be fixed in Python.

Expected Result

The requests.utils functions address_in_network, is_ipv4_address and is_valid_cidr should fail with invalid input.

Actual Result

Incorrect IP strings do not return an error and instead return as if the trailing garbage did not exist in the IP string.

Reproduction Steps

import requests

print(requests.utils.address_in_network('1.1.1.1 wtf', '1.1.1.1/24'))
print(requests.utils.is_ipv4_address('1.1.1.1 disconnect3d was here...'))
print(requests.utils.is_valid_cidr('1.1.1.1 obviously not but yes/24'))

System Information

The issue is related to libc implementation and has been tested on glibc 2.27 and 2.29.

It also occurs on MacOS which I am not sure if it is based on glibc.

[HJones82493]

PR #5135
I feel as though the call to the socket library is actually unnecessary here.

[disconnect3d]

Ping @kennethreitz @Lukasa @sigmavirus24 @nateprewitt @slingamn can we finally get some love here and get this fixed?

This could probably also be marked as a security issue since if someone uses this in a security relevant context, they can get in trouble. (Although I doubt and hope that nobody does use those functions in such a way).

[sigmavirus24]

These are not intended for use by others. The fact the language has no way of making things as private or internal means that we can't stop people from giving a function not intended for public use garbage or getting garbage out

[sigmavirus24]

Also, @disconnect3d rather than demand free labor of others, you're welcome to submit a fix for this

[disconnect3d]

These are not intended for use by others. The fact the language has no way of making things as private or internal means that we can't stop people from giving a function not intended for public use garbage or getting garbage out

The typical way to mark this is to prefix the name with underscore or two ;).

[sigmavirus24]

Yeah and people still use it from this library so we stopped bothering. I've been maintaining this library for almost a decade now. Writing python for longer. I know what the convention is and I know people don't care

[HJones82493]

Is there an argument against using socket.inet_pton instead of socket.inet_aton? It seems like socket.inet_pton has had its implementation fixed to not accept the extra strings and could solve this whole problem? If there's historical reason to not use it in these contexts, that's fine, but it seems like a simple fix (I'd be more than willing to submit something for review for it) if not.

[vcapparelli]

PR #6675
@disconnect3d , the socket implementation was replaced by ipaddress, fixing the bugs

[disconnect3d]

Thanks! :)

…

On Thu, 28 Mar 2024 at 02:33, Vítor Capparelli ***@***.***> wrote: PR #6675 <#6675> @disconnect3d <https://github.com/disconnect3d> , the socket implementation was replaced by ipaddress, fixing the bugs — Reply to this email directly, view it on GitHub <#5131 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMLWCTYXD6D26KQNEHTDGDY2NXPTAVCNFSM4H5MK2VKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSGQZDIMRVGY2A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[victorwss]

We already have a PR and I think that it is ok. Can it be merged? If not, why?