requests.utils function accepts invalid ip/cidr input

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.

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

@kennethreitz

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).

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

@disconnect3d

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

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 ;).

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

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.

@disconnect3d

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

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: ***@***.***>

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

Navigation Menu

Repository navigation

requests.utils function accepts invalid ip/cidr input #5131

Expected Result

Actual Result

Reproduction Steps

System Information

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

requests.utils function accepts invalid ip/cidr input #5131

Description

Expected Result

Actual Result

Reproduction Steps

System Information

Activity

HJones82493 commented on Jul 10, 2019

disconnect3d commented on Nov 29, 2023

sigmavirus24 commented on Nov 29, 2023

sigmavirus24 commented on Nov 29, 2023

disconnect3d commented on Nov 29, 2023

sigmavirus24 commented on Nov 30, 2023

HJones82493 commented on Nov 30, 2023

vcapparelli commented on Mar 28, 2024

disconnect3d commented on Mar 28, 2024

victorwss commented on Feb 7, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions