Bug 163692 - net-dns/bind: DNSSEC error and dereferencing freed fetch context (CVE-2007-049[34])
|
Bug#:
163692
|
Product: Gentoo Security
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: rajiv@gentoo.org
|
|
Component: Vulnerabilities
|
|
|
URL:
|
|
Summary: net-dns/bind: DNSSEC error and dereferencing freed fetch context (CVE-2007-049[34])
|
|
Keywords:
|
|
Status Whiteboard: A/B3 [glsa]
|
|
Opened: 2007-01-25 01:43 0000
|
From: Mark_Andrews@isc.org
Subject: Internet Systems Consortium Security Advisory.
Date: January 24, 2007 7:23:26 PM EST
To: bind-announce@isc.org
Internet Systems Consortium Security Advisory.
BIND 9: dereferencing freed fetch context
12 January 2007
Versions affected:
BIND 9.3.0, 9.3.1, 9.3.2, 9.3.3
BIND 9.4.0a1, 9.4.0a2, 9.4.0a3, 9.4.0a4, 9.4.0a5, 9.4.0a6, 9.4.0b1
9.4.0b2, 9.4.0b3, 9.4.0b4, 9.4.0rc1
BIND 9.5.0a1 (Bind Forum only)
Severity: Low
Exploitable: Remotely
Description:
It is possible for the named to dereference (read) a freed
fetch context. This can cause named to exit unintentionally.
Workaround:
Disable / restrict recursion (to limit exposure).
Fix:
Upgrade to BIND 9.2.8, BIND 9.3.4 or BIND 9.4.0rc2.
Additionally this will be fixed in the upcoming BIND 9.5.0a2.
Revision History:
pls provide updated ebuilds
this has been fixed in 9.3.4 and 9.2.8
bind and bind/tools 9.2.8, 9.3.4 and 9.4.0_rc2 have been committed to the tree.
(In reply to comment #3)
> bind and bind/tools 9.2.8, 9.3.4 and 9.4.0_rc2 have been committed to the tree.
>
Thanks Martin.
Hi arches, please test and mark stable when appropriate, thanks.
Target keywords are bind-9.2.8 and bind-9.3.4
9.3.4 wants idnkit but idnkit blocks <9.4...
coffee someone?
my fault, wrong idnkit's block fixed.
bind-tools must be in sync with bind. i.e. stabilize 'em too, please.
ohhh someone's not gonna like me... 9.3.4 it still breaks on hardened-x86:
grsec: From xxx.xxx.xxx.xxx: signal 6 sent to /usr/sbin/named[named:11336]
uid/euid:40/40 gid/egid:40/40, parent /sbin/init[init:1] uid/euid:0/0
gid/egid:0/0 by /usr/sbin/named[named:852] uid/euid:40/40 gid/egid:40/40,
parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
net-dns/bind-tools-9.3.4 marked stable for HPPA.
(In reply to comment #13)
> ohhh someone's not gonna like me... 9.3.4 it still breaks on hardened-x86:
>
> grsec: From xxx.xxx.xxx.xxx: signal 6 sent to /usr/sbin/named[named:11336]
> uid/euid:40/40 gid/egid:40/40, parent /sbin/init[init:1] uid/euid:0/0
> gid/egid:0/0 by /usr/sbin/named[named:852] uid/euid:40/40 gid/egid:40/40,
> parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
>
Same behavior here on hardened-x86:
grsec: From XXX.XXX.XXX.XXX: signal 6 sent to /usr/sbin/named[named:22469]
uid/euid:40/40 gid/egid:40/40, parent /sbin/init[init:1] uid/euid:0/0
gid/egid:0/0 by /usr/sbin/named[named:10807] uid/euid:40/40 gid/egid:40/40,
parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Will happen within a few seconds of named reporting in the logs that is has
finished starting up and is running.
I suggest we mask bind for hardened arches only. Is named the only program
that reports a problem? (i.e. do we need to mask bind-tools too or just bind)?
*** Bug 163691 has been marked as a duplicate of this bug. ***
It's an old and well-known bind issue. I vote Yes for a GLSA.
I'm hearing from a few people about problems on hardened on amd64 and x86, also
mentioned in comment #15 and comment #16 , fyi.
In addition, this bug is related (I found that out after i posted last comment,
appologies for spam) bug #158664
GLSA 200702-06, see bug 158664 for hardened-related issues