Bug#889285: bind9: CVE-2017-3139 affects debian too: assertion failure in validator.c:1858

2018-02-07 Thread Roberto C . Sánchez 
On Sat, Feb 03, 2018 at 05:17:01PM +0100, Salvatore Bonaccorso wrote:
> 
> The bug was about CVE-2017-3137, it's never a good idea to mix up
> things ;-).

This is true.  However, it appears that Ondrej Zary's comment to #860225
on 2017-09-02 is in fact related to CVE-2017-3139.  Since one of the
bind9 maintainers was the one to raise the issue of CVE-2017-3139 in
that same bug, I don't see a related follow-up report from a user to be
problematic.

> Anyway thanks that you took action and filled a new bug
> for this issue you are experiencing.
> 
> JTR, since Red Hat does not provide much details on the CVE-2017-3139
> we cannot say Debian is affected as well by this very same CVE. Since
> it's not clear, what CVE-2017-3139 is in detail, I have removed the
> CVE in the subject of this bug.
> 
It is true that there is information provided by RedHat regarding the
details of the vulnerability.  The RHSA mentioned in #860225 is also
linked from this RedHat BZ:

https://bugzilla.redhat.com/show_bug.cgi?id=1447743

However, there are no useful details there either.  I did some digging
and located the bind9 source RPM references in RHSA-2017:1202 and its
immediate predecessor.  By comparing the packages, I was able to
identify the specific patch that was associated with that RHSA.  I have
attached the patch to this email.  The name of the patch refers to
another RedHat BZ entry:

https://bugzilla.redhat.com/show_bug.cgi?id=1447407

That one is not accessible to the public, so we have no way of knowing
the details there.  Additionally, the related upstream RT tickets are
also not public.

Note that the attached patch appears to be based on commit
07dbb507d2913fc35c7edbe3692a976e3248a911 from upstream's git repository:

https://source.isc.org/git/bind9.git

The upstream changes appear to include a hunk in resolver.c which does
not appear in the RedHat patch.  That chunk would also not apply to the
wheezy version of bind9.

> What seem clear is that apparently a fix in Debian wheezy's bind9
> version causes the regression you notices. Thus I suggest the LTS team
> to try to find the defective patch introducing the issue and then
> issue just a regression update (without referencing CVE-2017-3139. If
> its on the other hand clear that Debian wheezy used the very same
> patch for a previous issue, and CVE-2017-3139 applies as well for
> Debian wheezy, then obviously it's fine to use the CVE).
> 
I examined the changes made from 9.8.4.dfsg.P1-6+nmu2+deb7u15 to
9.8.4.dfsg.P1-6+nmu2+deb7u16, which included fixes for CVE-2017-3136,
CVE-2017-3137, and CVE-2017-3138.  After examining the changes and
comparing them to the related upstream commits, I am convinced that the
fix for CVE-2017-3137 in 9.8.4.dfsg.P1-6+nmu2+deb7u16 is correct and
complete.  I would consider my examination thorough, but not exhaustive
owing to the large volume of change and some departures that are clearly
a result of the upsteam changes being backported to the bind9 in wheezy.
I am further convinced that the problem reported by Ondrej Zary in
#860225 and by Vladislav Kurz are both identical occurrences of
CVE-2017-3139.

In order to confirm the latter hypothesis, I built the current wheezy
version of bind9 and ran the dnssec test.  The test passed.  I then
stripped the changes to validator.c from the attached patch and applied
the remainder to the current wheezy version of bind9, built, and ran the
dnssec test again.  This time the test failed.  This seems to indicate
that the version of bind9 in wheezy is vulnerable to CVE-2017-3139.  I
then applied the remaining validator.c changes, rebuilt, and ran the
dnssec test again.  This time the test passed.

Based on these findings, I conclude that wheezy bind9 is vulnerable to
CVE-2017-3139.  I propose to do the following:

- Mark CVE-2017-3139 as affecting wheezy in the security tracker
- Prepare and upload a version 9.8.4.dfsg.P1-6+nmu2+deb7u20 upload that
  incorporates the CVE-2017-3139 patch from RedHat (and which closes
  this bug, #889285)
- Release a DLA per the normal procedure

I am now in the process of preparing the package for upload, but I will
wait a couple of days to allow for any objections and/or suggestions.

Regards,

-Roberto

-- 
Roberto C. Sánchez
>From 1d31a0cf1712d3eb001a686c06fe1225ba48fd04 Mon Sep 17 00:00:00 2001
From: Mark Andrews 
Date: Sat, 6 Oct 2012 14:56:33 +1000
Subject: [PATCH] 3391. [bug] DNSKEY that encountered a CNAME failed. [RT
 #31262]

(original commit 07dbb507d2913fc35c7edbe3692a976e3248a911)
---
 bin/tests/system/dnssec/clean.sh |  1 +
 bin/tests/system/dnssec/ns3/secure.example.db.in |  4 ++
 bin/tests/system/dnssec/ns3/sign.sh  |  4 +-
 bin/tests/system/dnssec/tests.sh | 66 
 lib/dns/validator.c  |  4 ++
 5 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/bin/tests/system/dnssec/clean.sh b/bin/tests/system/dnssec/clean.sh
index

Bug#889285: bind9: CVE-2017-3139 affects debian too: assertion failure in validator.c:1858

2018-02-03 Thread Salvatore Bonaccorso 
Control: retitle -1 bind9: assertion failure in validator.c:1858

Hi

On Sat, Feb 03, 2018 at 11:12:30AM +0100, Vladislav Kurz wrote:
> This is a followup to archived bug #860225.
> 
> Although
> https://security-tracker.debian.org/tracker/CVE-2017-3139 states that
> debian is not affected by CVE-2017-3139, I observed this behavior on
> debian wheezy:
> 
> Feb  3 08:38:07 server named[16906]: validator.c:1858: INSIST(rdataset->type 
> == ((dns_rdatatype_t)dns_rdatatype_dnskey)) failed, back trace
> Feb  3 08:38:07 server named[16906]: #0 0x7f9b66798e19 in ??
> Feb  3 08:38:07 server named[16906]: #1 0x7f9b650d5f3a in ??
> Feb  3 08:38:07 server named[16906]: #2 0x7f9b66094e57 in ??
> Feb  3 08:38:07 server named[16906]: #3 0x7f9b6609b599 in ??
> Feb  3 08:38:07 server named[16906]: #4 0x7f9b650f4dfd in ??
> Feb  3 08:38:07 server named[16906]: #5 0x7f9b64aa8b50 in ??
> Feb  3 08:38:07 server named[16906]: #6 0x7f9b64492fbd in ??
> Feb  3 08:38:07 server named[16906]: exiting (due to assertion failure)
> 
> Ondrej Zary reported this on Sat, 02 Sep 2017 in bug #860225 but it
> was closed and archived without answer. May I ask why?

The bug was about CVE-2017-3137, it's never a good idea to mix up
things ;-). Anyway thanks that you took action and filled a new bug
for this issue you are experiencing.

JTR, since Red Hat does not provide much details on the CVE-2017-3139
we cannot say Debian is affected as well by this very same CVE. Since
it's not clear, what CVE-2017-3139 is in detail, I have removed the
CVE in the subject of this bug.

What seem clear is that apparently a fix in Debian wheezy's bind9
version causes the regression you notices. Thus I suggest the LTS team
to try to find the defective patch introducing the issue and then
issue just a regression update (without referencing CVE-2017-3139. If
its on the other hand clear that Debian wheezy used the very same
patch for a previous issue, and CVE-2017-3139 applies as well for
Debian wheezy, then obviously it's fine to use the CVE).

Regards,
Salvatore

Bug#889285: bind9: CVE-2017-3139 affects debian too

2018-02-03 Thread Roberto C . Sánchez 
On Sat, Feb 03, 2018 at 02:37:14PM +0100, Vladislav Kurz wrote:
> Hello LTS team,
> 
> please have a look at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889285
> 
> I think it is the same bug as CVE-2017-3139 which was considered to affect
> only RedHat, but it seems to affect debian wheezy too.
> 
> Please check if it is possible to apply the same fixes as RedHat did.
> Or at leas update the bind package in wheezy-backports to match the version
> and security fixes from debian jesssie.
> 
I am taking a look at this now.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#889285: [Pkg-dns-devel] Bug#889285: bind9: CVE-2017-3139 affects debian too: assertion failure in validator.c:1858

2018-02-03 Thread Ondřej Surý 
Control: tags -1 +wheezy

You should probably contact the Debian LTS team as it affects wheezy that’s 
maintained by LTS Team.

Ondrej
--
Ondřej Surý 

> On 3 Feb 2018, at 11:12, Vladislav Kurz  wrote:
> 
> Package: bind9
> Version: 1:9.8.4.dfsg.P1-6+nmu2+deb7u19
> Severity: grave
> Tags: security
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> This is a followup to archived bug #860225.
> 
> Although
> https://security-tracker.debian.org/tracker/CVE-2017-3139 states that
> debian is not affected by CVE-2017-3139, I observed this behavior on
> debian wheezy:
> 
> Feb  3 08:38:07 server named[16906]: validator.c:1858: INSIST(rdataset->type 
> == ((dns_rdatatype_t)dns_rdatatype_dnskey)) failed, back trace
> Feb  3 08:38:07 server named[16906]: #0 0x7f9b66798e19 in ??
> Feb  3 08:38:07 server named[16906]: #1 0x7f9b650d5f3a in ??
> Feb  3 08:38:07 server named[16906]: #2 0x7f9b66094e57 in ??
> Feb  3 08:38:07 server named[16906]: #3 0x7f9b6609b599 in ??
> Feb  3 08:38:07 server named[16906]: #4 0x7f9b650f4dfd in ??
> Feb  3 08:38:07 server named[16906]: #5 0x7f9b64aa8b50 in ??
> Feb  3 08:38:07 server named[16906]: #6 0x7f9b64492fbd in ??
> Feb  3 08:38:07 server named[16906]: exiting (due to assertion failure)
> 
> Ondrej Zary reported this on Sat, 02 Sep 2017 in bug #860225 but it
> was closed and archived without answer. May I ask why?
> 
> I had a look in the relevant bug report at redhat, but they do not
> provide much details https://bugzilla.redhat.com/show_bug.cgi?id=1447743
> So I'm not 100% sure it is the same bug.
> 
> 
> *** Please consider answering these questions, where appropriate ***
> 
>   * What led up to the situation?
>   * What exactly did you do (or not do) that was effective (or
> ineffective)?
>   * What was the outcome of this action?
>   * What outcome did you expect instead?
> 
> *** End of the template - remove these lines ***
> 
> 
> -- System Information:
> Debian Release: 7.11
>  APT prefers oldoldstable
>  APT policy: (500, 'oldoldstable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.2.0-5-686-pae (SMP w/1 CPU core)
> Locale: LANG=sk_SK, LC_CTYPE=sk_SK (charmap=ISO-8859-2)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages bind9 depends on:
> ii  adduser3.113+nmu3
> ii  bind9utils 1:9.8.4.dfsg.P1-6+nmu2+deb7u19
> ii  debconf [debconf-2.0]  1.5.49
> ii  libbind9-801:9.8.4.dfsg.P1-6+nmu2+deb7u19
> ii  libc6  2.13-38+deb7u12
> ii  libcap21:2.22-1.2
> ii  libdns88   1:9.8.4.dfsg.P1-6+nmu2+deb7u19
> ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u9
> ii  libisc84   1:9.8.4.dfsg.P1-6+nmu2+deb7u19
> ii  libisccc80 1:9.8.4.dfsg.P1-6+nmu2+deb7u19
> ii  libisccfg821:9.8.4.dfsg.P1-6+nmu2+deb7u19
> ii  liblwres80 1:9.8.4.dfsg.P1-6+nmu2+deb7u19
> ii  libssl1.0.01.0.1t-1+deb7u3
> ii  libxml22.8.0+dfsg1-7+wheezy12
> ii  lsb-base   4.1+Debian8+deb7u1
> ii  net-tools  1.60-24.2
> ii  netbase5.0
> 
> bind9 recommends no packages.
> 
> Versions of packages bind9 suggests:
> pn  bind9-doc   
> ii  dnsutils1:9.8.4.dfsg.P1-6+nmu2+deb7u19
> pn  resolvconf  
> pn  ufw 
> 
> -- Configuration Files:
> /etc/bind/named.conf.local changed:
> //
> // Do any local configuration here
> //
> // Consider adding the 1918 zones here, if they are not used in your
> // organization
> include "/etc/bind/zones.rfc1918";
> 
> /etc/bind/named.conf.options changed:
> options {
>directory "/var/cache/bind";
>// If there is a firewall between you and nameservers you want
>// to talk to, you may need to fix the firewall to allow multiple
>// ports to talk.  See http://www.kb.cert.org/vuls/id/800113
>// If your ISP provided one or more IP addresses for stable 
>// nameservers, you probably want to use them as forwarders.  
>// Uncomment the following block, and insert the addresses replacing 
>// the all-0's placeholder.
>// forwarders {
>//0.0.0.0;
>// };
>auth-nxdomain no;# conform to RFC1035
>listen-on-v6 { none; };
>listen-on { 127.0.0.1; };
>dnssec-enable yes;
>dnssec-validation auto;
>dnssec-lookaside auto;
> };
> 
> 
> -- debconf information:
>  bind9/different-configuration-file:
>  bind9/run-resolvconf: true
>  bind9/start-as-user: bind
> 
> ___
> pkg-dns-devel mailing list
> pkg-dns-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel

Bug#889285: bind9: CVE-2017-3139 affects debian too: assertion failure in validator.c:1858

2018-02-03 Thread Vladislav Kurz 
Package: bind9
Version: 1:9.8.4.dfsg.P1-6+nmu2+deb7u19
Severity: grave
Tags: security
Justification: renders package unusable

Dear Maintainer,

This is a followup to archived bug #860225.

Although
https://security-tracker.debian.org/tracker/CVE-2017-3139 states that
debian is not affected by CVE-2017-3139, I observed this behavior on
debian wheezy:

Feb  3 08:38:07 server named[16906]: validator.c:1858: INSIST(rdataset->type == 
((dns_rdatatype_t)dns_rdatatype_dnskey)) failed, back trace
Feb  3 08:38:07 server named[16906]: #0 0x7f9b66798e19 in ??
Feb  3 08:38:07 server named[16906]: #1 0x7f9b650d5f3a in ??
Feb  3 08:38:07 server named[16906]: #2 0x7f9b66094e57 in ??
Feb  3 08:38:07 server named[16906]: #3 0x7f9b6609b599 in ??
Feb  3 08:38:07 server named[16906]: #4 0x7f9b650f4dfd in ??
Feb  3 08:38:07 server named[16906]: #5 0x7f9b64aa8b50 in ??
Feb  3 08:38:07 server named[16906]: #6 0x7f9b64492fbd in ??
Feb  3 08:38:07 server named[16906]: exiting (due to assertion failure)

Ondrej Zary reported this on Sat, 02 Sep 2017 in bug #860225 but it
was closed and archived without answer. May I ask why?

I had a look in the relevant bug report at redhat, but they do not
provide much details https://bugzilla.redhat.com/show_bug.cgi?id=1447743
So I'm not 100% sure it is the same bug.


*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- System Information:
Debian Release: 7.11
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-5-686-pae (SMP w/1 CPU core)
Locale: LANG=sk_SK, LC_CTYPE=sk_SK (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/bash

Versions of packages bind9 depends on:
ii  adduser3.113+nmu3
ii  bind9utils 1:9.8.4.dfsg.P1-6+nmu2+deb7u19
ii  debconf [debconf-2.0]  1.5.49
ii  libbind9-801:9.8.4.dfsg.P1-6+nmu2+deb7u19
ii  libc6  2.13-38+deb7u12
ii  libcap21:2.22-1.2
ii  libdns88   1:9.8.4.dfsg.P1-6+nmu2+deb7u19
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u9
ii  libisc84   1:9.8.4.dfsg.P1-6+nmu2+deb7u19
ii  libisccc80 1:9.8.4.dfsg.P1-6+nmu2+deb7u19
ii  libisccfg821:9.8.4.dfsg.P1-6+nmu2+deb7u19
ii  liblwres80 1:9.8.4.dfsg.P1-6+nmu2+deb7u19
ii  libssl1.0.01.0.1t-1+deb7u3
ii  libxml22.8.0+dfsg1-7+wheezy12
ii  lsb-base   4.1+Debian8+deb7u1
ii  net-tools  1.60-24.2
ii  netbase5.0

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind9-doc   
ii  dnsutils1:9.8.4.dfsg.P1-6+nmu2+deb7u19
pn  resolvconf  
pn  ufw 

-- Configuration Files:
/etc/bind/named.conf.local changed:
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";

/etc/bind/named.conf.options changed:
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk.  See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable 
// nameservers, you probably want to use them as forwarders.  
// Uncomment the following block, and insert the addresses replacing 
// the all-0's placeholder.
// forwarders {
//  0.0.0.0;
// };
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { none; };
listen-on { 127.0.0.1; };
dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;
};


-- debconf information:
  bind9/different-configuration-file:
  bind9/run-resolvconf: true
  bind9/start-as-user: bind