[issue37495] socket.inet_aton parsing issue on some libc versions

Change by Jeffrey Kintscher : -- nosy: +Jeffrey.Kintscher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37495] socket.inet_aton parsing issue on some libc versions

disconnect3d added the comment: Regarding the exception case: seems like OSError, since that's what originally was done and we don't want to break users of this code. -- ___ Python tracker

[issue37495] socket.inet_aton parsing issue on some libc versions

disconnect3d added the comment: Its a while since this has been reported. I think inet_aton_pton.py is fine, though, a commit adding it should explain why we do it this way. @vstinner can you push this patch further or do you want me to do it? --

[issue37495] socket.inet_aton parsing issue on some libc versions

STINNER Victor added the comment: Attached inet_aton_pton.py is a proof-of-concept which reimplements inet_aton() using inet_pton(). It supports a.b.c.d, a.b.c, a.b and a formats. I'm not sure which exception should be raised in case of parsing error. socket.inet_aton() raises

[issue37495] socket.inet_aton parsing issue on some libc versions

Christian Heimes added the comment: > inet_pton() requires an address family. Should we iterate on all supported > address families until one works? No, that is not necessary. inet_aton() only accepts IPv4 addresses. Therefore an emulation with inet_pton() would look like this: >>> import

[issue37495] socket.inet_aton parsing issue on some libc versions

STINNER Victor added the comment: One solution would to be reimplement socket.inet_aton() with inet_pton() internally. inet_pton() is well specified and standard (POSIX). inet_aton() is not ("inet_aton() is not specified in POSIX.1, but is available on most systems." says its Linux manual

[issue37495] socket.inet_aton parsing issue on some libc versions

Christian Heimes added the comment: CVE-2016-10739 was filed against glibc. We cannot re-use a CVE number from another product in CPython. You can only reference that a CVE causes a security bug. -- title: [CVE-2016-10739] socket.inet_aton parsing issue on some libc versions ->

[issue37495] socket.inet_aton parsing issue on some libc versions

STINNER Victor added the comment: January 2019, Florian Weimer created the issue "Deprecate inet_addr, inet_aton" in glibc: https://sourceware.org/bugzilla/show_bug.cgi?id=24111 inet_aton() ignores extra string "for historic reasons". More info at:

[issue37495] socket.inet_aton parsing issue on some libc versions

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37495] socket.inet_aton parsing issue on some libc versions

Change by Karthikeyan Singaravelan : -- nosy: +christian.heimes ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37495] socket.inet_aton parsing issue on some libc versions

Aldwin Pollefeyt added the comment: indeed, can confirm that a string starting with valid ip address and a space followed with anything, will not trigger the exception. do_ping('1.1.1.1 1.256.300.1 ; whoami') => no exception -- ___ Python tracker

[issue37495] socket.inet_aton parsing issue on some libc versions

Aldwin Pollefeyt added the comment: >From : >https://docs.python.org/3.9/library/subprocess.html#security-considerations Security Considerations Unlike some other popen functions, this implementation will never implicitly call a system shell. This means that all characters, including shell

[issue37495] socket.inet_aton parsing issue on some libc versions

Change by Dominik Czarnota : -- type: -> security ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37495] socket.inet_aton parsing issue on some libc versions

New submission from Dominik Czarnota : The socket.inet_aton Python function uses libc's inet_aton function. This, on some implementations, for example the latest GNU C Library (glibc 2.29 as of today), accepts whitespace with trailing characters after a valid IP. An example can be seen below: