PSF-2019-13 ssl.match_hostname() ignores extra string after whitespace in IPv4 address
Python's ssl.match_hostname incorrectly validates IPv4 addresses with trailing whitespace, potentially bypassing certificate checks in older versions.
- Exploited in the wild
- Not known
- Login needed
- Not needed
- Attackable
- Over the internet
- Victim action needed
- Not needed
- Fix
- None listed
What is PSF-2019-13?
PSF-2019-13 is a vulnerability, published on 1 Jul 2019. An attacker can exploit it over the internet without logging in, with no action from the victim.
Official description
inet_aton() accepts trailing characters after a valid IP. Because of
that, Python ssl.match_hostname('1.1.1.1 ; this should not work but does')
succeeded when it should fail.
The issue was introduced in bpo-32819 <https://bugs.python.org/issue32819>_ by commit aef1283b <https://github.com/python/cpython/commit/aef1283ba428e33397d87cee3c54a5110861552d>_.
Only Python 3.7 and newer are affected. It's a potential security bug
although low severity. For one Python 3.7 and newer no longer use
ssl.match_hostname() to verify hostnames and IP addresses of a
certificate: matching is performed by OpenSSL.
It should not possible to register a x509 certificate with a hostname with spaces.
The glibc function inet_aton() accepts input as valid if said input is
a IPv4 address followed by zero or more characters that are valid
white-space as decided by isspace(), with the rest of the string after
the first white-space being ignored. As '\r' is a valid white-space
character the rest of the string is ignored (including the '\r'). See
glibc bug 24111: Deprecate inet_addr, inet_aton <https://sourceware.org/bugzilla/show_bug.cgi?id=24111>_.
Which versions are affected by PSF-2019-13?
How do I fix PSF-2019-13?
No fix has been published for PSF-2019-13 yet. Limit exposure of the affected software until one is available.
Is PSF-2019-13 being exploited?
There is no known exploitation of PSF-2019-13 in the wild and no public exploit code.