And the Microsoft DNS in active directory does not have those same problems?
That's a red herring for the Microsoft consultants to come in and spend your
company's money. IBM whole owned or not.
The die is cast at this point, IBM i will lose again because IBM won't stand
up for it.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Tuesday, March 17, 2015 10:55 AM
To: Midrange Systems Technical Discussion
Subject: RE: How to determine what version of bind you are running?
I have to really drill down into the 9. numbers.
From our security audit (done by a wholly owned company of IBM) we're
getting dinged hard because of this bind level. The audit report can
determine our level of bind is at BIND 9.7.4-P1.V7R1M0
The following are considered our top critical issues on our security audit
report (again, done by a wholly owned company of IBM):
3.1.1. ISC BIND: Handling of zero length rdata can cause named to terminate
unexpectedly (CVE-2012-1667) (dns-bindcve-
2012-1667)
ISC BIND 9.x before 9.7.6-P1, 9.8.x before 9.8.3-P1, 9.9.x before 9.9.1-P1,
and 9.4-ESV and 9.6-ESV before 9.6-ESV-R7-P1 does not properly handle
resource records with a zero-length RDATA section, which allows remote DNS
servers to cause a denial of service (daemon crash or data corruption) or
obtain sensitive information from process memory via a crafted record.
3.1.2. Obsolete ISC BIND installation (dns-bind-obsolete) ISC BIND versions
before 9.9 are considered obsolete. ISC will not fix security bugs in these
versions (even critical ones).
3.1.3. ISC BIND: Heavy DNSSEC validation load can cause a "bad cache"
assertion failure (CVE-2012-3817) (dns-bindcve-
2012-3817)
Description:
ISC BIND 9.4.x, 9.5.x, 9.6.x, and 9.7.x before 9.7.6-P2; 9.8.x before
9.8.3-P2; 9.9.x before 9.9.1-P2; and 9.6-ESV before 9.6-ESV-R7- P2, when
DNSSEC validation is enabled, does not properly initialize the failing-query
cache, which allows remote attackers to cause a denial of service (assertion
failure and daemon exit) by sending many queries.
3.1.4. ISC BIND: A specially crafted Resource Record could cause named to
terminate (CVE-2012-4244) (dns-bind-cve-
2012-4244)
Description:
ISC BIND 9.x before 9.7.6-P3, 9.8.x before 9.8.3-P3, 9.9.x before 9.9.1-P3,
and 9.4-ESV and 9.6-ESV before 9.6-ESV-R7-P3 allows remote attackers to
cause a denial of service (assertion failure and named daemon exit) via a
query for a long resource record.
3.1.5. ISC BIND: Specially crafted DNS data can cause a lockup in named
(CVE-2012-5166) (dns-bind-cve-2012-5166)
Description:
ISC BIND 9.x before 9.7.6-P4, 9.8.x before 9.8.3-P4, 9.9.x before 9.9.1-P4,
and 9.4-ESV and 9.6-ESV before 9.6-ESV-R7-P4 allows remote attackers to
cause a denial of service (named daemon hang) via unspecified combinations
of resource records.
3.1.6. ISC BIND: A specially crafted query can cause BIND to terminate
abnormally (CVE-2013-4854) (dns-bind-cve-
2013-4854)
Description:
The RFC 5011 implementation in rdata.c in ISC BIND 9.7.x and 9.8.x before
9.8.5-P2, 9.8.6b1, 9.9.x before 9.9.3-P2, and 9.9.4b1, and DNSco BIND
9.9.3-S1 before 9.9.3-S1-P1 and 9.9.4-S1b1, allows remote attackers to cause
a denial of service (assertion failure and named daemon exit) via a query
with a malformed RDATA section that is not properly handled during
construction of a log message, as exploited in the wild in July 2013.
It's getting to the point where we might dump serving DNS from IBM i.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 03/17/2015 11:39 AM
Subject: RE: How to determine what version of bind you are running?
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
9
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Tuesday, March 17, 2015 10:26 AM
To: midrange-l@xxxxxxxxxxxx
Subject: How to determine what version of bind you are running?
We have an external service that does some security checking. It says
we're
running bind level such and such. How do they determine that? The reason
I
am asking is that is one of our hold out lpar's still running IBM i 7.1
that
we've not yet upgraded to 7.2 and I am wondering if upgrading to 7.2 will
upgrade the level of bind. So I'd like to find out what level of bind 7.2
is running.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
