[Bug network/18665] New: In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer.

[Bug network/18665] New: In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer.

[rhollida at ciena dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

            Bug ID: 18665
           Summary: In send_dg, the recvfrom function is NOT always using
                    the buffer size of a newly created buffer.
           Product: glibc
           Version: 2.20
            Status: NEW
          Severity: normal
          Priority: P2
         Component: network
          Assignee: unassigned at sourceware dot org
          Reporter: rhollida at ciena dot com
  Target Milestone: ---

description:

When the thisanssizp pointer variable on line 1257 is updated, thisanssizp =
anssizp2, i.e assigned a new address,
this change causes the thisanssizp pointer variable used in the recvfrom
function on line 1282 to use the
wrong size if a new buffer is created after the thisanssizp address has been
changed at line 1257.

The size of the buffer used will be what was stored at the address assigned at
line 1257, and not the size of the newly created buffer.

The program will crash if the calculated size of the buffer used is 0. The
recvfrom function will
not crash, but any further accesses to the buffer where the bytes read was 0
from the recvfrom function
will crash the program. 

Initially at line 1230:
thisanssizp = anssizp;
-the thisanssizp gets assigned the address of anssizp when the send_dg function
is first called.

At line 1257:
thisanssizp = anssizp2;
-the thisanssizp address gets updated after we have received a packet.

At line 1273: 
*anssizp = MAXPACKET;
-the size of a new packet is assigned to *anssizp, and not *thisanssizp, when a
new buffer is created.

At line 1282:
recvfrom(pfd[0].fd, (char*)*thisansp, *thisanssizp, 
-the recvfrom function uses the size from *thisanssizp which is wrong.
-it can be seen here that thisansp will contain the address of a newly created
buffer, but the *thisanssizp, will contain the size from the aligned_resplen,
instead of MAXPACKET.

Fix:

Use the size pointer *thisanssizp, instead of *thisansp, when creating the new
buffer.

u_char *newp = malloc (MAXPACKET);
                        if (newp != NULL) {
                                <*anssizp = MAXPACKET;>     :REMOVED LINE:
                                *thisanssizp = MAXPACKET;   :ADDED LINE:
                                *thisansp = ans = newp;
                                if (thisansp == ansp2)
                                  *ansp2_malloced = 1;

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/18665] In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer.

[rhollida at ciena dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

--- Comment #1 from Robert <rhollida at ciena dot com> ---
This issue is referencing the send_dg function in res_send.c 
and referencing lines in res_send.c from glibc-2.21. 
This code is almost exact from what is in 2.20

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/18665] In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer.

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #2 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Robert from comment #1)
> This issue is referencing the send_dg function in res_send.c 
> and referencing lines in res_send.c from glibc-2.21. 
> This code is almost exact from what is in 2.20

Thanks for the bug report. Do you have a test case that triggers this scenario?
Do you have a patch or suggested fix?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/18665] In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer.

[rhollida at ciena dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

--- Comment #3 from Robert <rhollida at ciena dot com> ---
This is my suggested fix for this issue:

Use the size pointer *thisanssizp, instead of *thisansp, when creating the new
buffer.

u_char *newp = malloc (MAXPACKET);
                        if (newp != NULL) {
                                <*anssizp = MAXPACKET;>     :REMOVED LINE:
                                *thisanssizp = MAXPACKET;   :ADDED LINE:
                                *thisansp = ans = newp;
                                if (thisansp == ansp2)
                                  *ansp2_malloced = 1;

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/18665] In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer.

[rhollida at ciena dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

--- Comment #4 from Robert <rhollida at ciena dot com> ---
Overview:

A condition occurs when the recvfrom function receives data using a newly
created buffer but
does not use the newly created buffer size then the buffer is accessed and
causes the program to
crash. 

In send_dg in res_send.c 
-referencing lines in res_send.c from glibc-2.21

Conditions that create the crash.
1. Receive a packet that fills up the buffer, 2048 bytes, used in the recvfrom
function on line 1282.
2. The aligned_resplen calculation, on line 1243, becomes 0. (buffer size -
packet size received = 0)
3. The condition on line 1268 is met;  *thisanssizp < *thisresplenp, (the
calculated size left < the received size), 0 < 2048,.
   and a new buffer is created at line 1271 with buffer size MAXPACKET; 
4. The recvfrom function on line, 1282, now uses the newly created buffer to
receive DNS data,

   ISSUE: The recvfrom function is NOT using the buffer size from the newly
created buffer, 
       but from the aligned_resplen calculation which was 0.
       The recvfrom function is reading 0 bytes into the new buffer, and should
be reading MAXPACKET bytes into the buffer.

5. The res_queriematch function attempts to use the data read into the buffer:
thisansp, at location: thisansp + thisanssizp, 
   these are invalid pointers, and cause the program to crash.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/18665] In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer.

[rhollida at ciena dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

--- Comment #5 from Robert <rhollida at ciena dot com> ---
I assume this is happening because this code was never sufficiently tested with
large packets. 

I had done some statistics which show typical packet lengths received for DNS
queries. 

Received packet lengths:
122, 128, 47, 80, 59, 73, 226, 50, 161 

It looks like the code that allocates more buffer space starting on line
1271, is not used much, so probably does not get a lot of testing, because most
of the time the default buffer of 2048 bytes is less than the largest packet I
received of 161 bytes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/18665] In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer.

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/18665] In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer.

[fweimer at redhat dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3019 bytes --]

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security?

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
Robert, you need to tell us which function you call, with which parameters.  A
full backtrace from the crash often shows this information.  A PCAP file
created with “tcpdump -n -s 0 -w file.pcap” would be helpful, too.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-29336-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Aug 22 20:30:42 2015
Return-Path: <glibc-bugs-return-29336-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 91308 invoked by alias); 22 Aug 2015 20:30:41 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 91256 invoked by uid 48); 22 Aug 2015 20:30:37 -0000
From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/984] Respond to changed resolv.conf in gethostbyname
Date: Sat, 22 Aug 2015 20:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: 2.3.5
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: gotom at debian dot or.jp
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: component
Message-ID: <bug-984-131-coxjwBYO7W@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-984-131@http.sourceware.org/bugzilla/>
References: <bug-984-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg00376.txt.bz2
Content-length: 371

https://sourceware.org/bugzilla/show_bug.cgi?id˜4

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |network

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/18665] In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer (CVE-2015-7547)

[bnnf-yellowbot at blurcompany dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

Mark winds <bnnf-yellowbot at blurcompany dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bnnf-yellowbot@blurcompany.
                   |                            |com

--- Comment #26 from Mark winds <bnnf-yellowbot at blurcompany dot com> ---
They are not correctly handled. Please refer to C99, 7.19.6.2, paragraph 9,
which defines an input item as:

"the longest sequence of input characters which does not exceed any specified
field width and which is, or is a prefix of, a matching input sequence"

Paragraph 10 then reads:
http://sasphhs.pennhillswiki.com/
"If the input item is not a matching sequence, the execution of the directive
fails: this condition is a matching failure."

Clearly in the case of sscanf("0xz", "%x%c", &x, &c), the first "input item" is
"0x", and it is not a matching sequence for the %x conversion (see the
specification of strtoul, in terms of which scanf %x is specified), so the
result must be a matching failure.
http://pennhillswiki.com/ 
If you're going to wrongly mark this bug as "RESOLVED", at least mark it
"WONTFIX" rather than "INVALID" and acknowledge that it's a bug that you're
unwilling to fix, and that glibc is intentionally non-conformant in this
matter.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/18665] In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer (CVE-2015-7547)

[bnnf-yellowbot at blurcompany dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

--- Comment #27 from Mark winds <bnnf-yellowbot at blurcompany dot com> ---
Scanning "0xz" for %x results in an input item of "0x" with "z" pushed back
into the unread buffer. The bug has nothing to do with pushbacks, because the
right data is pushed back. The bug is that a non-matching input item is treated
as a match rather than a matching error.

Perhaps you thought I was saying the input item should be "0", successfully
converted, with "x" as the next unread character in the buffer. Of course this
is wrong and I do not believe such a thing.
https://www.targetedwebtraffic.com/
Perhaps you should try reading the actual language standard rather than
assuming you're right.

-- 
You are receiving this mail because:
You are on the CC list for the bug.