Report information
The Basics
Id:
23006
Status:
open
Worked:
55 minutes
Users:
cathya: 50 minutes
RT_System: 35 minutes
Priority:
Medium/Medium
Queue:

BugTracker
Version Fixed:
(no value)
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
(no value)
Priority:
(no value)
Severity:
S3 Low
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
bug

Dates
Created:Wed, 26 Jan 2011 01:43:03 -0500
Updated:Fri, 07 Jul 2017 01:34:11 -0400
Closed:Wed, 26 Jan 2011 03:50:03 -0500



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

Subject: test
Date: Wed, 26 Jan 2011 17:42:25 +1100
To: dhcp-bugs@isc.org
From: dave b <db.pub.mail@gmail.com>
test
Subject: Re: [ISC-Bugs #23006] AutoReply: test
Date: Wed, 26 Jan 2011 17:59:35 +1100
To: dhcp-bugs@isc.org
From: dave b <db.pub.mail@gmail.com>
Hi I was actually wondering if bug 19839 was ever fixed. [0] I also find it hard to believe that there is no *public* bug tracker for isc-dhcp. On a side note the isc mailman site, https://lists.isc.org, is running an ancient version of mailman which is vulnerable to a number bug known bugs. [0] - http://mandriva.598463.n5.nabble.com/Bug-51179-dhcp-NEW-dhclient-crashes-with-a-buffer-overflow-td674983.html
Subject: Re: [ISC-Bugs #23006] AutoReply: test
Date: Wed, 26 Jan 2011 21:08:28 +1100
To: dhcp-bugs@isc.org
From: dave b <db.pub.mail@gmail.com>
Also, this is amusing: ( and I probably got this entirely wrong :P - and I doubt it is a real issue) dhcpclient.c dhcp() ... char addrbuf[4*16]; ... ... The following comment is just plain wrong: /* piaddr() returns its result in a static buffer sized 4*16 (see common/inet.c). */ Why? because sizeof pbuf is 46. source: static char pbuf[sizeof("ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255")]; Ok. Now in dhcpv6() ... char addrbuf[sizeof("ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff")]; the sizeof addrbuf is 40. Following along: /* Discard, with log, packets from quenched sources. */ for (ap = packet->interface->client->config->reject_list ; ap ; ap = ap->next) { if (addr_match(&packet->client_addr, &ap->match)) { WOOPS ---> strcpy(addrbuf, piaddr(packet->client_addr)); log_info("%s from %s rejected by rule %s", dhcpv6_type_names[packet->dhcpv6_msg_type], addrbuf, piaddrmask(&ap->match.addr, &ap->match.mask)); return; } } From the strcpy manual: The strcpy() function copies the string pointed to by src, including the terminating null byte ('\0'), to the buffer pointed to by dest. The strings may not overlap, and the destination string dest must be large enough to receive the copy. Hum but (for dhcpv6) addrbuf is sizeof 40 and the max of the source string is sizeof 46. Woops.
Subject: Re: [ISC-Bugs #23006] AutoReply: test
Date: Wed, 26 Jan 2011 23:11:31 +1100
To: dhcp-bugs@isc.org
From: Mark Andrews <marka@isc.org>
In message <rt-3.8.6-55512-1296036545-509.23006-4-0@isc.org>, "dave b via RT" w rites: > Also, this is amusing: ( and I probably got this entirely wrong > :P - and I doubt it is a real issue) > > dhcpclient.c > > dhcp() > ... > char addrbuf[4*16]; > ... > ... > The following comment is just plain wrong: > > /* piaddr() returns its result in a static > buffer sized 4*16 (see common/inet.c). */ > > Why? because sizeof pbuf is 46. > source: static char > pbuf[sizeof("ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255")]; > > Ok. > > Now in dhcpv6() > ... > > char addrbuf[sizeof("ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff")]; > the sizeof addrbuf is 40. > > Following along: > > /* Discard, with log, packets from quenched sources. */ > for (ap = packet->interface->client->config->reject_list ; > ap ; ap = ap->next) { > if (addr_match(&packet->client_addr, &ap->match)) { > > WOOPS ---> strcpy(addrbuf, piaddr(packet->client_addr)); > > > > log_info("%s from %s rejected by rule %s", > dhcpv6_type_names[packet->dhcpv6_msg_type], > addrbuf, > piaddrmask(&ap->match.addr, &ap->match.mask) > ); > return; > } > } > > >From the strcpy manual: > The strcpy() function copies the string pointed to by src, > including the terminating null byte ('\0'), to the buffer pointed to > by dest. The strings may not overlap, and the destination string dest > must be large enough to receive the copy. > > Hum but (for dhcpv6) addrbuf is sizeof 40 and the max of the source > string is sizeof 46. Woops. 45 is the biggest legal input. No presentation address exceeds 39. The two form where a dotted quad are emitted have the following forms neither of which is anywhere near 46 bytes in length. ::111.222.333.444 ::ffff:111.222.333.444 However if a flag was ever added to say emit dotted quad then you would have arbitary prefixes and it could be reached. > -- > Ticket History: https://bugs.isc.org/Ticket/Display.html?id=23006 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Subject: Re: [ISC-Bugs #23006] AutoReply: test
Date: Wed, 26 Jan 2011 23:28:32 +1100
To: dhcp-bugs@isc.org
From: dave b <db.pub.mail@gmail.com>
First off what happened to bug 19839 ? --------------- Ok continuing with this bug.... The man page for inet_ntop states the following: AF_INET6 src points to a struct in6_addr (in network byte order) which is converted to a representation of this address in the most appropriate IPv6 network address format for this address. The buffer dst must be at least INET6_ADDRSTRLEN bytes long. INET6_ADDRSTRLEN is 46,( #define INET6_ADDRSTRLEN 46 ) I prefer to not disagree with manuals (46 > 40). Even if you decide to ignore this -> In the following *should* be fixed: 1. the incorrect comment needs to be either removed or 'corrected' 2. addrbuf for ipv6 should be at least 46 or INET6_ADDRSTRLEN long.
Subject: Re: [ISC-Bugs #23006] AutoReply: test
Date: Thu, 27 Jan 2011 00:33:44 +1100
To: dhcp-bugs@isc.org
From: Mark Andrews <marka@isc.org>
> First off what happened to bug 19839 ? Fixed in June 2009. 4.2-first, 4.1.1b2, 4.0.2b2, 3.1.3b1 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Subject: Re: [ISC-Bugs #23006] AutoReply: test
Date: Sat, 5 Mar 2011 14:42:18 +1100
To: dhcp-bugs@isc.org
From: dave b <db.pub.mail@gmail.com>
... no feedback on that?
CC: db.pub.mail@gmail.com, 622380-forwarded@bugs.debian.org, 622380@bugs.debian.org
Subject: [db.pub.mail@gmail.com: Bug#622380: isc-dhcp-client: IPv6 address buffer size mismatch and comment error]
Date: Thu, 25 Aug 2011 22:44:15 -0700
To: dhcp-bugs@isc.org
From: Andrew Pollock <apollock@debian.org>
Hello, One of our users reported this bug. I'm not sure if it's already reported in your bug tracker or not. Please maintain the Cc to keep our bug tracking system in the loop. regards Andrew ----- Forwarded message from david b <db.pub.mail@gmail.com> ----- Date: Wed, 13 Apr 2011 01:44:47 +1000 From: david b <db.pub.mail@gmail.com> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: Bug#622380: isc-dhcp-client: minor bug X-Mailer: reportbug 4.12.6 Package: isc-dhcp-client Version: 4.1.1-P1-15+squeeze2 Severity: important I have given up on upstream & and their bug tracking is "closed" anyway. Over a few emails I sent the following to isc. " In dhcpclient.c dhcp() ... char addrbuf[4*16]; ... ... The following comment is just plain wrong: /* piaddr() returns its result in a static buffer sized 4*16 (see common/inet.c). */ Why? because sizeof pbuf is 46. source: static char pbuf[sizeof("ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255")]; Ok. Now in dhcpv6() ... char addrbuf[sizeof("ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff")]; the sizeof addrbuf is 40. Following along: /* Discard, with log, packets from quenched sources. */ for (ap = packet->interface->client->config->reject_list ; ap ; ap = ap->next) { if (addr_match(&packet->client_addr, &ap->match)) { Ah... ---> strcpy(addrbuf, piaddr(packet->client_addr)); log_info("%s from %s rejected by rule %s", dhcpv6_type_names[packet->dhcpv6_msg_type], addrbuf, piaddrmask(&ap->match.addr, &ap->match.mask)); return; } } >>From the strcpy manual: The strcpy() function copies the string pointed to by src, including the terminating null byte ('\0'), to the buffer pointed to by dest. The strings may not overlap, and the destination string dest must be large enough to receive the copy. The man page for inet_ntop states the following: AF_INET6 src points to a struct in6_addr (in network byte order) which is converted to a representation of this address in the most appropriate IPv6 network address format for this address. The buffer dst must be at least INET6_ADDRSTRLEN bytes long. INET6_ADDRSTRLEN is 46,( #define INET6_ADDRSTRLEN 46 ) I prefer to not disagree with manuals (46 > 40). Even if you decide to ignore this -> In the following *should* be fixed: 1. the incorrect comment needs to be either removed or 'corrected' 2. addrbuf for ipv6 should be at least 46 or INET6_ADDRSTRLEN long. " -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38.2 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages isc-dhcp-client depends on: ii debianutils 3.4 Miscellaneous utilities specific t ii iproute 20100519-3 networking and traffic control too ii isc-dhcp-common 4.1.1-P1-15+squeeze2 common files used by all the isc-d ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib isc-dhcp-client recommends no packages. Versions of packages isc-dhcp-client suggests: pn avahi-autoipd <none> (no description available) pn resolvconf <none> (no description available) -- Configuration Files: /etc/dhcp/dhclient.conf changed [not included] -- no debconf information ----- End forwarded message -----
Hi Andrew,

> One of our users reported this bug. I'm not sure if it's already
> reported in
> your bug tracker or not.
It is - and there has been some feedback to the original submitter.  It's bug ticket #23006.  I'll ask engineering to comment further as it's not clear to me what the outcome is to be on it.

> Please maintain the Cc to keep our bug tracking system in the loop.
I've added the original submitter and 622380@bugs.debian.org.  I wasn't sure if we also needed 622380-forwarded@bugs.debian.org ?

Once I've heard back, I'm most likely going to merge this new ticket with the original.

We hear you loud and clear on the closed bug tracking - this is oft-discussed and we're hoping to do <something> about it, but not sure what and when.  In the meantime, please bear with us.  You can always email further questions to a submitted bug ticket.  Since earlier this year, ISC support has been triaging and monitoring bug ticket traffic - and will help if it looks like something is being overlooked that shouldn't be (though response times can vary as our main focus is our support customer questions/problems).

Kind regards,

Cathy


Hi Andrew,

> > One of our users reported this bug. I'm not sure if it's already
> > reported in
> > your bug tracker or not.
> It is - and there has been some feedback to the original submitter.
> It's bug
> ticket #23006. I'll ask engineering to comment further as it's not
> clear to me
> what the outcome is to be on it.
I've merged your new ticket with the original bug report (as you'll see from the change of bug ticket reference in the subject line of this email).

Engineering feedback is that this shouldn't present an actual problem - although we will look into this at some point.  Currently it doesn't appear to us to be urgent, but could you confirm whether or not this is causing issues for the original reporter?

Kind regards,

Cathy

CC: apollock@debian.org, 622380@bugs.debian.org
Subject: Re: [ISC-Bugs #23006] Bug#622380: isc-dhcp-client: IPv6 address buffer size mismatch and comment error
Date: Wed, 14 Sep 2011 04:11:03 +1000
To: dhcp-bugs@isc.org
From: dave bl <db.pub.mail@gmail.com>
It isn't causing any issues. I reported it as I thought it was slightly amusing (but harmless).