Bug 15014 (CVE-2015-0235) - gethostbyname_r() returns EINVAL (22) instead of ERANGE (34) (CVE-2015-0235)
Summary: gethostbyname_r() returns EINVAL (22) instead of ERANGE (34) (CVE-2015-0235)
Status: RESOLVED FIXED
Alias: CVE-2015-0235
Product: glibc
Classification: Unclassified
Component: network (show other bugs)
Version: 2.17
: P2 normal
Target Milestone: 2.18
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 19683 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-01-12 21:41 IST by Peter Klotz
Modified: 2016-02-20 13:51 IST (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security+


Attachments
Source that demonstrates the problem (347 bytes, text/x-c++src)
2013-01-12 21:41 IST, Peter Klotz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Klotz 2013-01-12 21:41:29 IST
Created attachment 6817 [details]
Source that demonstrates the problem

Under certain circumstances gethostbyname_r() returns EINVAL (22) instead of ERANGE (34).

The attached source demonstrates the problem.

[user@host devel]$ g++ -W -Wall -DDNS_BUFFER_SIZE=37 dnslookup.cpp -o dnslookup
[user@host devel]$ ./dnslookup brain
error: 22 (Unknown resolver error)

[user@host devel]$ g++ -W -Wall -DDNS_BUFFER_SIZE=38 dnslookup.cpp -o dnslookup
[user@host devel]$ ./dnslookup brain

My /etc/hosts file contains this line to resolve host "brain":

10.18.1.19      brain

Using a 37 byte buffer gethostbyname_r() returns EINVAL. With a 38 byte buffer gethostbyname_r() return ERANGE once, the buffer is doubled and the lookup succeeds.

I can reproduce this behavior in RHEL5 (glibc 2.5), RHEL6 (glibc 2.12) and Arch Linux (glibc 2.17) on x86_64.

Is there a minimum size for the buffer to start with? I found nothing in the manpage.
Comment 1 Andreas Schwab 2013-05-21 10:57:13 IST
Fixed by d5dd618
Comment 2 Florian Weimer 2015-01-27 15:07:32 IST
Per <http://www.frsag.org/pipermail/frsag/2015-January/005722.html>, CVE-2015-0235 was assigned to this issue.
Comment 3 nsh 2015-01-27 23:40:56 IST
Right, obviously this is with all due deference and respect and I hope nobody takes it the wrong way and thinks I'm being a dick or anything, but: 

Could we take this moment and look back maybe somewhat systematically over other closed bugs that were deemed of low importance and no security impact which involved very clearly increasing the size of a buffer so that it becomes big enough to not get overflowed? 

This could save a lot on a lot of shitty logo design and hot air and generally silliness in the future...

Best, 
nsh
Comment 4 joseph@codesourcery.com 2015-01-28 01:59:19 IST
Florian *has* reviewed over 3000 past glibc bugs for security impact 
(there are a fair number more, mostly older bugs, not yet given a security 
flag), but as this case illustrates it may not be apparent from the bug 
description that a buffer overrun was involved at all (the subject of this 
bug rather suggests a conformance issue with a wrong errno value).

Now, if someone else wants to do their own review of over 3000 bugs with 
"security-" flag, and to query cases where they disagree with that 
assessment, that would be welcome, but probably also very tedious and not 
likely to find many cases of misclassified bugs.
Comment 5 nsh 2015-01-28 12:10:05 IST
I appreciate that from the bug metadata it's not apparent at all, and (now) appreciate the work that has been and continues to be put into evaluating security implications of bugs. In this case, at least, even a trivial grep of the diff for 'buffer' would flag a mind suitably predisposed towards suspicion.

Could there be some more low-hanging automated patch-analysis fruits? Perhaps there exists some static analysis tool designed to classify along these lines, or if not, some more general tool might be specialized to the task. 

I should look into it and try a little myself, I suppose, to see if I'm being over optimistic about the like reward to invested effort. 

Best, 
nsh
Comment 6 Florian Weimer 2016-02-20 13:51:03 IST
*** Bug 19683 has been marked as a duplicate of this bug. ***