Bug 1347549 (CVE-2016-10739) - CVE-2016-10739 glibc: getaddrinfo should reject IP addresses with trailing characters
Summary: CVE-2016-10739 glibc: getaddrinfo should reject IP addresses with trailing ch...
Alias: CVE-2016-10739
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Whiteboard: impact=moderate,public=20160428,repor...
Keywords: Security
Depends On: 1331390 1673465
Blocks: 1303701
TreeView+ depends on / blocked
Reported: 2016-06-17 08:33 UTC by Cedric Buissart 🐶
Modified: 2019-03-01 13:58 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-08-19 11:20:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 20018 None None None 2019-04-18 02:49 UTC
Sourceware 24111 None None None 2019-04-18 02:49 UTC

Description Cedric Buissart 🐶 2016-06-17 08:33:19 UTC
For historic reasons, inet_addr and inet_aton accept trailing garbage.  Some parsers rely on this (for example, libresolv when it parses “nameserver” directives in /etc/resolv.conf).

This causes problems because some applications assume that a successful parse as an IPv4 address means that the string consists of just an IPv4 address, and nothing more.

Glibc should add a check for trailing garbage and relegate the old behavior to a compatibility symbol.

For backporting, glibc should just fix getaddrinfo (and related functions if necessary) so that they will not accept trailing garbage.

Upstream bug :

Additional note : 
When used in combination with flaw described in CVE-2016-5699, an attacker could direct an HTTP connection to a malicious server, using the following combined issues:

* Python's httplib does not validate HTTP header values. A malicious 'Host' header with quoted new lines can inject additional headers and more
* glibc's getaddrinfo() ignores new lines and everything after a new line character when the first part looks like a IPv4 address

See the following blog post for additional information:

Comment 1 Cedric Buissart 🐶 2016-06-17 08:44 UTC
Created attachment 1168979 [details]
Demo program

Comment 2 Cedric Buissart 🐶 2016-06-17 09:26:07 UTC
[ Copy of Christian Heimes' original comment from BZ 1303699 ]

compile and run with gcc -o hostname hostname.c && ./hostname

The demo uses gethostbyname() and getaddrinfo() with AF_INET hint to look up the hostname "\r\nspam".

Comment 3 Cedric Buissart 🐶 2016-06-17 09:27:05 UTC
[ Copy of Carlos O'Donell's original comment from BZ 1303699 ]

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 space as decided by isspace, with the rest of the string after the first space being ignored. As '\r' is a valid space character the rest of the string is ignored (includeing the '\r').

This flexible behaviour is allowed because it makes parsing space-separated lists of addresses (as C strings) easier to manage. You advance the pointer between the address blocks and call inet_aton. In this case getaddrinfo uses inet_aton to determine the validity of the input string, and so considers "\r\nspam" a valid name parameter and it is immediately converted into the address structure for

The flexible behaviour is used internally in several places in glibc to parse configuration files.

I'd suggest glibc should fix it like this, but upstream needs consulting:
- Version inet_aton to allow the old behaviour and keep it for old programs.
- The new version should strictly reject any IPv4 address with garbage.
- Code that relies on the old behaviour needs to be updated to strdupa and then split the string and parse the pieces.

This isn't going to get fixed any time soon, so the python fix certainly has to go in.

Comment 5 Andrej Nemec 2017-09-08 12:09:11 UTC

Red Hat Product Security has rated this issue as having Moderate security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

Note You need to log in before you can comment on or make changes to this bug.