84195 2002-11-13 05:28 /36 rader/ Aaron Howell <aaronh@amerion.net>
Importerad: 2002-11-13 05:28 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2369>
Ärende: [Fwd: Notice of serious vulnerabilities in ISC BIND 4 & 8]
------------------------------------------------------------
-----Forwarded Message-----
From: Peter Losher <Peter_Losher@isc.org>
To: bind-announce@isc.org
Subject: Notice of serious vulnerabilities in ISC BIND 4 & 8
Date: 12 Nov 2002 10:02:25 -0800
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
ISC is aware of several bugs which can result in serious
vulnerabilities in BIND as distributed by ISC. More information
about these vulnerabilities can be found here:
http://www.isc.org/products/BIND/bind-security.html
Upgrading to BIND version 9.2.1 is strongly recommended. However,
patches are available from ISC and new BIND 4 & 8 releases will be
forthcoming.
Questions on obtaining the patches should be directed to the Executive
Director of ISC <Lynda_McGinley@isc.org>.
- --
Peter_Losher@isc.org - Internet Software Consortium - OpenPGP E8048D08
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE90UIxPtVx9OgEjQgRAl5UAKDRqRztK2QNc8ZBxFPonNKOG+4AHgCgn/O/
DwniP+74yTUDpaGJ8H0cncI=
=q2oG
-----END PGP SIGNATURE-----
(84195) /Aaron Howell <aaronh@amerion.net>/(Ombruten)
84353 2002-11-14 15:10 /73 rader/ Michael Brennen <mbrennen@fni.com>
Importerad: 2002-11-14 15:10 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2385>
Ärende: Bind 8 bug experience
------------------------------------------------------------
Three bugs in bind 4 and 8 were announced this morning, November 12.
At least one has the possibility of arbitrary code execution, and
the ISC web site lists it as 'Serious'.
At 13:02 CST this afternoon per the ISC announcement, about an hour
after receiving the bug announcement, I requested bind 8 patches
from Lynda McGinley, Executive Director of ISC. I received a
response from her roughly 8 hours later this evening that I had been
added to the patch announce list. My thanks to Lynda for that, but
she did not give direct information on where to get the patches, and
I have received nothing from the patch announce list. I don't know
when I can expect to receive anything -- tonight, next week, or next
month?
Earlier today I asked Lynda a question: why were patches not made
available at the time of the announcement? Paraphrasing her
response, since I have not asked her permission to forward verbatim
what she wrote, she indicated that those in the bind forum that had
subscribed to the early security notification had the patches
readily available. She indicated that ISC wanted to make sure that
the right audience had the patches first.
I clarified to her that my understanding is that the early
notification subscription was for the purpose of vendors being
notified before public announcement so they could get software
packages updated and available prior to announcement. Lynda
affirmed this.
My response to her was that the right audience should change in
relation to announcement.
Those that paid to be notified early had that expectation fulfilled.
Before announcement, per current ISC practice, they are the right
audience, and they got bind 4 and 8 patches.
As of the moment of announcement, the right audience should be
expanded to include all those placed at risk because they use the
software. Failure to make the patches available suddenly puts many
systems at rapidly increasing risk.
I have not yet heard a satisfactory answer why were patches not
publicly available when this announcement was made. More troubling,
why has ISC not released the patches yet? As of 23:44 CST, about 12
hours after the first announcement, nothing beyond 8.3.3 is
available in the normal directories on ftp.isc.org, yet updates
clearly exist.
Per the ISS announcement, to the best of their knowledge no crackers
knew of these bugs, nor were there exploits available. From the
moment of the announcement, that is no longer true. If these were
truly unknown bugs, there was time to do this right, to fix the bugs
and get the updates available. That time advantage is eroding very
rapidly.
I had held off upgrading to bind 9 because of its newness. Observing
its release history, in my assessment it has not been any better
than bind 8. There have been too many beta, release candidate and
security fixes to be considered stable. Meanwhile, ISC's policies
left me with no real choice. I've dropped everything else this
evening and have upgraded to bind 9.
I don't know of a similar incident when the known patches to such a
serious problem were withheld by a software provider. This is
particularly true in the case of software of which its security and
stability are the most crucial to the operation of the Internet.
This raises troubling questions about the future management of bind.
What will happen when the next bind 9 bug hits?
-- Michael
(84353) /Michael Brennen <mbrennen@fni.com>/--------
Kommentar i text 84482 av Glen Bishop <glen@glenbishop.com>
Kommentar i text 84488 av Chris Adams <cmadams@hiwaay.net>
Kommentar i text 84517 av Matthew Dixon Cowles <matt@mondoinfo.com>
Kommentar i text 84520 av Jeremy C. Reed <reed@reedmedia.net>
84482 2002-11-15 18:23 /79 rader/ Glen Bishop <glen@glenbishop.com>
Importerad: 2002-11-15 18:23 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: glen@glenbishop.com
Mottagare: Bugtraq (import) <2399>
Kommentar till text 84353 av Michael Brennen <mbrennen@fni.com>
Ärende: Re: Bind 8 bug experience
------------------------------------------------------------
bind 4 and 8 patches are now available which appeared late last night
http://www.isc.org/products/BIND/patches/
-glen
>
> Three bugs in bind 4 and 8 were announced this morning, November 12. At
> least one has the possibility of arbitrary code execution, and
> the ISC web site lists it as 'Serious'.
>
> At 13:02 CST this afternoon per the ISC announcement, about an hour
> after receiving the bug announcement, I requested bind 8 patches
> from Lynda McGinley, Executive Director of ISC. I received a
> response from her roughly 8 hours later this evening that I had been
> added to the patch announce list. My thanks to Lynda for that, but she
> did not give direct information on where to get the patches, and I have
> received nothing from the patch announce list. I don't know when I can
> expect to receive anything -- tonight, next week, or next month?
>
> Earlier today I asked Lynda a question: why were patches not made
> available at the time of the announcement? Paraphrasing her
> response, since I have not asked her permission to forward verbatim what
> she wrote, she indicated that those in the bind forum that had
> subscribed to the early security notification had the patches
> readily available. She indicated that ISC wanted to make sure that the
> right audience had the patches first.
>
> I clarified to her that my understanding is that the early
> notification subscription was for the purpose of vendors being
> notified before public announcement so they could get software
> packages updated and available prior to announcement. Lynda
> affirmed this.
>
> My response to her was that the right audience should change in
> relation to announcement.
>
> Those that paid to be notified early had that expectation fulfilled.
> Before announcement, per current ISC practice, they are the right
> audience, and they got bind 4 and 8 patches.
>
> As of the moment of announcement, the right audience should be
> expanded to include all those placed at risk because they use the
> software. Failure to make the patches available suddenly puts many
> systems at rapidly increasing risk.
>
> I have not yet heard a satisfactory answer why were patches not
> publicly available when this announcement was made. More troubling, why
> has ISC not released the patches yet? As of 23:44 CST, about 12 hours
> after the first announcement, nothing beyond 8.3.3 is
> available in the normal directories on ftp.isc.org, yet updates
> clearly exist.
>
> Per the ISS announcement, to the best of their knowledge no crackers
> knew of these bugs, nor were there exploits available. From the
> moment of the announcement, that is no longer true. If these were truly
> unknown bugs, there was time to do this right, to fix the bugs and get
> the updates available. That time advantage is eroding very rapidly.
>
> I had held off upgrading to bind 9 because of its newness. Observing its
> release history, in my assessment it has not been any better
> than bind 8. There have been too many beta, release candidate and
> security fixes to be considered stable. Meanwhile, ISC's policies left
> me with no real choice. I've dropped everything else this
> evening and have upgraded to bind 9.
>
> I don't know of a similar incident when the known patches to such a
> serious problem were withheld by a software provider. This is
> particularly true in the case of software of which its security and
> stability are the most crucial to the operation of the Internet.
>
> This raises troubling questions about the future management of bind.
> What will happen when the next bind 9 bug hits?
>
> -- Michael
(84482) /Glen Bishop <glen@glenbishop.com>/---------
84488 2002-11-15 20:21 /34 rader/ Chris Adams <cmadams@hiwaay.net>
Importerad: 2002-11-15 20:21 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2405>
Kommentar till text 84353 av Michael Brennen <mbrennen@fni.com>
Ärende: Re: Bind 8 bug experience
------------------------------------------------------------
Once upon a time, Michael Brennen <mbrennen@fni.com> said:
> Three bugs in bind 4 and 8 were announced this morning, November 12.
> At least one has the possibility of arbitrary code execution, and
> the ISC web site lists it as 'Serious'.
>
> At 13:02 CST this afternoon per the ISC announcement, about an hour
> after receiving the bug announcement, I requested bind 8 patches
> from Lynda McGinley, Executive Director of ISC. I received a
> response from her roughly 8 hours later this evening that I had been
> added to the patch announce list. My thanks to Lynda for that, but
> she did not give direct information on where to get the patches, and
> I have received nothing from the patch announce list. I don't know
> when I can expect to receive anything -- tonight, next week, or next
> month?
I also (per the announcement from ISC) emailed Lynda McGinley
requesting patches. I never received a response. I kept watch on
the ISC web site and downloaded the patch last night (the file
timestamps in the patch are all Oct 30 2002, so the patch was ready
in plenty of time).
We cannot upgrade some of our servers to BIND 9 because it (in my
experience and in the experience of others) is not stable on Compaq/HP
Tru64 Unix. Repeated messages on the BIND mailing list by myself and
others have been ignored (except by other Tru64 users with the same
problems), so as far as I know, no work is going on to fix BIND 9 on
Tru64. We either run BIND 8 or don't run BIND (and despite the work
involved in switching, running something other than BIND is looking
good).
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
(84488) /Chris Adams <cmadams@hiwaay.net>/(Ombruten)
84517 2002-11-16 16:29 /32 rader/ Matthew Dixon Cowles <matt@mondoinfo.com>
Importerad: 2002-11-16 16:29 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2425>
Kommentar till text 84353 av Michael Brennen <mbrennen@fni.com>
Ärende: Re: Bind 8 bug experience
------------------------------------------------------------
> Three bugs in bind 4 and 8 were announced this morning, November 12.
> At least one has the possibility of arbitrary code execution
[. . .]
> I don't know of a similar incident when the known patches to such a
> serious problem were withheld by a software provider.
Speaking for myself, I never expected anything different. In my
experience, when security information is restricted, the people who
have it aren't particularly concerned about getting it to the people
who don't. More than a year and a half ago, when I saw ISC's message
indicating that security information about BIND would be withheld
from the public, I removed BIND from all my systems and installed
djbdns.
Particularly ironic in light of ISC's apparent delay in releasing
patches is this from the BIND Member Forum FAQ:
Q: So the bind-members Forum programme does not restrict or delay any
access to which the industry has become accustomed?
A: Right.
The documents referred to are archived at:
http://marc.theaimsgroup.com/?l=bind-announce&m=98097021832397
http://marc.theaimsgroup.com/?l=bind-announce&m=98126980802945
Regards,
Matt
(84517) /Matthew Dixon Cowles <matt@mondoinfo.com>/-
84520 2002-11-16 20:38 /42 rader/ Jeremy C. Reed <reed@reedmedia.net>
Importerad: 2002-11-16 20:38 av Brevbäraren
Extern mottagare: Michael Brennen <mbrennen@fni.com>
Mottagare: Bugtraq (import) <2428>
Kommentar till text 84353 av Michael Brennen <mbrennen@fni.com>
Ärende: Re: Bind 8 bug experience
------------------------------------------------------------
On Wed, 13 Nov 2002, Michael Brennen wrote:
> I have received nothing from the patch announce list. I don't know
> when I can expect to receive anything -- tonight, next week, or next
> month?
I received the patches from rc.isc.org at 2002-11-12 22:29:41 PST.
(I do not have any commercial arrangement with them.)
> As of the moment of announcement, the right audience should be
> expanded to include all those placed at risk because they use the
> software. Failure to make the patches available suddenly puts many
> systems at rapidly increasing risk.
I assume they are hoping that vendors can provide the updates quickly
before an exploit is public.
For example, Puget Sound Technology was able to use these patches to
provide new BIND binaries for their customers of the Binary Updates
for NetBSD service around midnight (PST).
http://www.pugetsoundtechnology.com/services/netbsd/updates/
> Per the ISS announcement, to the best of their knowledge no crackers
> knew of these bugs, nor were there exploits available. From the
> moment of the announcement, that is no longer true. If these were
Does that mean there is an exploit?
> I don't know of a similar incident when the known patches to such a
> serious problem were withheld by a software provider. This is
This has happened a few times already this year. (See discussions
about OpenSSH security release for example.)
But I see the patches were made October 30 (if the dates are
reliable).
Thirteen days is a long delay.
Jeremy C. Reed
http://www.isp-faq.com/
(84520) /Jeremy C. Reed <reed@reedmedia.net>/(Ombruten)
Kommentar i text 84481 av Olaf Kirch <okir@suse.de>
84481 2002-11-15 18:04 /44 rader/ Olaf Kirch <okir@suse.de>
Importerad: 2002-11-15 18:04 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2398>
Kommentar till text 84520 av Jeremy C. Reed <reed@reedmedia.net>
Sänt: 2002-11-16 20:38
Ärende: Re: Bind 8 bug experience
------------------------------------------------------------
On Wed, Nov 13, 2002 at 12:04:31PM -0800, Jeremy C. Reed wrote:
> But I see the patches were made October 30 (if the dates are reliable).
In fact I believe ISC have been sitting on this for almost a month.
The CVE IDs were assigned October 16, and I have reason to believe
that they learned of this no later than October 23.
Members of BIND Forum were notified last week, from what I'm told.
In my opinion, the main reason for ISC to use this method of
distributing the patches rather than going through established
channels (such as CERT) was to be able to convince software vendors
and other bodies using/distributing BIND to become a member of BIND
forum. I don't know if that worked out, but I have my doubts.
From my experience of the past two days, I believe they did not
expect there to be such a demand for the patches. I know that most
Linux distributors, as well as some BSD folks, tried to reach someone
at ISC for 36 hours, without success (we were notified of the issue
on Tuesday, approx 14 hours ahead of the publication of ISC's and
ISS's announcements). Some of that may be blamed on technical issues
(I found it curious that PGP-signed messages never got through, while
unsigned messages did), but probably not all of it.
The whole thing was a mess. Timelines for the publication of
_anything_, from advisories to patches to updates, were either
non-existing or shifting all the time.
I don't have very fond memories of the OpenSSH update of a few months
ago, but it is worth noting that the SSH folks gave everyone a chance
to cover their bases first, and then went on to disclose details of
the bug.
We all have our little complaints about CERT now and then, and I also
think that CERT could improve in this way or that. But incidents like
this one also serve to remind that independent (and financially
independently) bodies do make a very valuable contribution to the
security community as a whole. Things could be so much worse...
Olaf
--
Olaf Kirch | Anyone who has had to work with X.509 has probably
okir@suse.de | experienced what can best be described as
---------------+ ISO water torture. -- Peter Gutmann
(84481) /Olaf Kirch <okir@suse.de>/-------(Ombruten)
Kommentar i text 84580 av Paul Theodoropoulos <paul@anastrophe.com>
84580 2002-11-18 11:27 /36 rader/ Paul Theodoropoulos <paul@anastrophe.com>
Importerad: 2002-11-18 11:27 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2456>
Kommentar till text 84481 av Olaf Kirch <okir@suse.de>
Ärende: Re: Bind 8 bug experience
------------------------------------------------------------
There is an alternative to this insanity. It's called djbdns, and it
is proven secure, and proven reliable. I've been using it in
production for a year now, and performance has been
flawless. Thousands of other administrators will offer the same
assessment. BIND is a security mess - that's an empirical fact that
can't be denied by anyone who has been on the net any appreciable
amount of time.
Why worry about timelines for advisories or patches or updates
concerning this core service of the internet? Far easier to use
software that has been proven to be secure and reliable from concept
to execution (pun intended).
http://cr.yp.to/djbdns.html
MODERATORS: considering the 100% 'meta' quality of the post i'm
replying to, i certainly hope that you'll post this
'advisory'. People need to be aware that there are alternatives to
BIND. It's a disservice to the community to *not* allow through a
pointer to software that could save tens of thousands of
administrators this endlessly repeating headache of systems being
vulnerable to exploit via one of the single most crucial parts of th
internet infrastructure - DNS. all you need to do is look at the
history of exploits for bind, and compare it to djbdns - even if you
throw out all the years of data for BIND from before djbdns's
release.
At 06:41 AM 11/14/2002, Olaf Kirch wrote:
>The whole thing was a mess. Timelines for the publication of _anything_,
>from advisories to patches to updates, were either non-existing or
>shifting all the time.
Paul Theodoropoulos
http://www.anastrophe.com
http://folding.stanford.edu
The Nicest Misanthrope on the Net
(84580) /Paul Theodoropoulos <paul@anastrophe.com>/(Ombruten)
84506 2002-11-16 11:02 /61 rader/ Russ <Russ.Cooper@rc.on.ca>
Importerad: 2002-11-16 11:02 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2422>
Ärende: RE: ISS Security Advisory: Multiple Remote Vulnerabilities in BIND4 andBIND8 (fwd)
------------------------------------------------------------
Is this the sort of disclosure we can expect based on the (OIS)
Organization for Internet Safety's "code of conduct" and/or "best
practices" for vulnerability disclosure?
ISS is a founding member of OIS, together with @stake, Bindview,
Caldera, Foundstone, Guardent, Microsoft, NAI, Oracle, SGI, and
Symantec (Symantec owns SecurityFocus).
From [2]OIA FAQ page; "OIS was formed as a unique partnership between
leading security researchers and vendors, for the purpose of
proposing"..."processes for handling security vulnerabilities."
"OIS is committed to public review and comment on all proposed
processes.", therefore, I submit this public review and comment on a
process used by one of its founding members.
"Does OIS support pre-disclosure of vulnerability information to
select groups? No. We believe the software author should be given a
chance to create a fix before vulnerability information is made
public, but that there should be no further distribution of that
information until the fix is complete."
From [4]ISS X-Force Advisory; "The vulnerabilities described in this
advisory affect nearly all currently deployed recursive DNS servers
on the Internet."
and
The following ISS updates and product releases address the issues
described in this advisory. These updates are available from the ISS
Download Center (http://www.iss.net/download):
RealSecure Network Sensor XPU 20.7 and XPU 5.6
Internet Scanner XPU 6.20
RealSecure Guard 3.1 ebs
RealSecure Sentry 3.1 ebs
RealSecure Server Sensor 6.5 SR 3.3
System Scanner SR 3.08
ISS says that the ISC, which is the reference implementation of the
affected BIND versions, has made patches available. However, the ISC
website[3] tells visitors that they must email them to "speak to ISC
about patches", and indicate that new releases of the affected
versions are "coming soon". BIND 8.3.3. is still recommended and
available on the ISC site, despite the fact its affected by all three
of the vulnerabilities cited by ISS. This hardly constitutes them
having "made patches available".
There are also hundreds of BIND implementations that are affected
beyond the ISC implementation, and none of those vendors have any
indications of patches for this issue (or even information about this
issue). A quick check of all of the vendors listed on the ISC'
"Vendor products based on BIND" page shows that none of them have
anything up about the issues, whether it affects their products,
etc... this includes Nortel, Lucent, Checkpoint and others.
From [2]OIS FAQ page; "Does OIS exchange non-public vulnerability
information amongst its membership? No. The OIS Code of Conduct
prohibits the distribution of vulnerability information to anyone
other than the discoverer and the software author."
ISS had no trouble using this information to update all of their
products, clearly they distributed the vulnerability information to
all of their product teams, possibly 100's of people, in violation of
the OIS "code of conduct".
From [2]OIS FAQ page; "What does OIS think about the auctioning or
selling of non-public vulnerability information? We believe that it
is unethical to intentionally make one person more vulnerable than
another."
Clearly, anyone who is not using all of ISS' products are more
vulnerable than anyone else, if you have a vulnerable BIND server in
your environment. I'd call that "selling of non-public vulnerability
information", wouldn't you? This is class SYN-Flooding tactics.
It is also worth pointing out that ISS is the coordinator for the ISP
ISAC. Such a role should be played by someone who is beyond reproach
when it comes to the ethics of security vulnerabilities. In ISS' case
they can probably not worry too much about their members being upset
since the vast majority of ISPs are likely running unaffected
versions of BIND.
However, the vast majority of Corporate America, not to mention
companies, educational institutions, and smaller ISPs around the
world ARE affected. Our analysis shows that an attack based on these
vulnerabilities will be trivial, and that upgrading to BIND 9.x will
not be a quickly adopted path.
One tries to assume that ISS felt this information was going to leak
to the public soon and, therefore, needed to publish the alert in
order to maintain the media attention/credit. Yet in doing so not
only have they shown the total ineffectiveness of the OIS, they have
also put the majority of the Internet at unnecessary risk. They say
they know of no active attacks, so what was the reason to rush this
to the public? If someone else was going to leak it, it would have
been better to allow them to do so, and afterwards, follow up with
the public with their more detailed advisory. In the time between now
and whenever this unknown person would have leaked the information,
or a new attack released based on it, ISS may have been able to get
more vendors to provide patches for their implementations.
I coined the phrase "Responsible Disclosure"[1], and it was not
intended to be represented by actions like this taken by ISS in its
name. OIS should publicly denounce ISS' action if it expects to
maintain any credibility, and ISS should explain its reasoning as to
why it has put the Internet at greater risk due to its irresponsible
disclosure.
Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor
Ref: [1]Proposal - The Responsible Disclosure Forum
http://www.ntbugtraq.com/rdforum.asp [2]About the Organization for
Internet Safety http://www.oisafety.org/about.html [3]Internet
Software Consortium BIND Vulnerabilities
http://www.isc.org/products/BIND/bind-security.html [4]Internet
Security Systems Security Advisory November 12, 2002
http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21469
(84506) /Russ <Russ.Cooper@rc.on.ca>/-----(Ombruten)
85640 2002-11-29 09:25 /214 rader/ Vagner Sacramento <vagner@natalnet.br>
Importerad: 2002-11-29 09:25 av Brevbäraren
Extern mottagare: Iván Arce <core.lists.bugtraq@core-sdi.com>
Mottagare: Bugtraq (import) <2591>
Kommentar till text 85569 av Iván Arce <core.lists.bugtraq@core-sdi.com>
Ärende: RE: CAIS-ALERT: Vulnerability in the sending requests control of BIND
------------------------------------------------------------
>I am sorry to burst the bubble but this has been a known problem for
>more than 5 years:
Dear Iván,
At first site It may looks like the vulnerability reported cited by
you, but in fact It isn.t.
The CERT did the same question when we were doing tests. Of course,
if was the same attack released in 1993 the CERT had not released a
Vulnerability Note.
http://www.kb.cert.org/vuls/id/457875
>Original advisory posted in 1997:
>
>http://www.codetalker.com/advisories/sni/sni-12.html
>http://www.corest.com/common/showdoc.php?idx=133&idxseccion=10 (spanish)
I know this attack methodology. Christopher Schuba and Eugene
Spafford outline this attack in the paper "Addressing weaknesses in
the Domain Name System Protocol" in COAST Laboratory, Department of
Computer Science, Purdue University, 1993.
This attack is the simplest and most widely used attack to do DNS
Spoofing on bind 8.1.x, 4.9.3, 4.9.5 and 4.9.6. Bind running with
these versions increase the ID by 1 for each query. They don.t
randomize the dns id. This is a problem of pedictable ID's and not
the problem that I reported.
The algorithm initially used to generate ID in BIND 8.1.x and
4.9.[3-6]
u_int16_t nsid_next()
{
! if (nsid_state == 65535)
! nsid_state = 0;
! else
! nsid_state++;
return (nsid_state);
}
:-), :-)
BIND Versions current (8.3.4, 4.9.11) and older (8.2.x, 9.x) are not
vulnerable to the attack presented in this advisory (cited by you).
However, I get to implement DNS Spoofing attacks remotely with very
easily in the bind 8.3.4 ,4.9.11 and older bind, and I can prove
THIS.
The problem that I described attests BIND versions 4 and 8 do not
prevent sending of two or more resolution requests for the same
domain name allowing DNS Spoofing attacks with significant
probability of success, then I implemented specific techniques
(originals) to have good results in the attacks.
In the link cited by you, the attacker has complete control of
DNS.ATTACKER.COM's network, he can both spoof and sniff DNS packets
there. In particular, he can sniff DNS packets sent to
DNS.ATTACKER.COM. The attacker needs to get the IDs to send the
replies.
The attacker sniff DNS.ATTACKER.COM's local network and retrieve the
query packet sent by DNS.TARGET.COM to DNS. ATTACKER.COM. He can
then determine the query ID (qid0) and source port used by
DNS.TARGET.COM. Chances are that the next queries generated by
DNS.TARGET.COM will have query IDs that will fall in the range
[qid0,qid0+N] where N is dependent on the amount of queries
DNS.TARGET.COM is generating in the period of time on which the
attack takes place. N is usually <= 15 for most cases.
In this attack methodology (released by Schuba) is not implemented
anything to determine the source IP address that should be used in
the reply packet because the attacker get the victim DNS current ID
(sniffing technique) and other.
In my attack methodology, I implemented techniques to determine ID,
Source IP address and the attacker can apply the attack successfully
FROM any network. The attacker does not need to be at the same
DNS.ATTACKER.COM's local network. The attacker does not NEED to
sniff queries to determine the source port and ID.
The success probability in my attack methodology to implement of DNS
Spoofing attack in BIND 4 and BIND 8 is calculated by the equation:
n-request-sent/65535, where n-request-sent is the number of requests
sent simultaneously to the target DNS server.
Another difficulty that I have in the remote attack is to imprecision
from establishing the ID to be used in the replies. In example
presented, the attacker doesn.t have difficulty because the his host
keeps capturing all packets in its local net, applying a sniffer
technique. ;-):-)
>+ /*
>+ * The 16 bit space is very small and brute force attempts are
>+ * entirly feasible, we skip a random number of transaction ids
>+ * so that an attacker will not get sequential ids.
>+ */
Using only brute force, the attack is very difficult to be applied. I
tried this several times. I did several tests in my experiments. The
probability of success is very low to get implement the attack using only
brute force.
>I have not read BIND source for years, is this not explicitly mentioned
>anywhere in the source or docs or updated RFCs??
However, I have read BIND source for months currently.
The ISC has omitted the problem, but I think there is
.people. exploiting the vulnerability that I reported in underground.
wget ftp://ftp.isc.org/isc/bind/src/8.3.4/bind-src.tar.gz
tar .xvzf bind-src.tar.gz
cd src/bin/named
The bug is in this file: src/bin/named/ns_forw.c
In this function:
int ns_forw(struct databuf *nsp[], u_char *msg, int msglen,
struct sockaddr_in from, struct qstream *qsp, int dfd,
struct qinfo **qpp, const char *dname, int class, int type,
struct namebuf *np, int use_tcp, struct tsig_record *in_tsig)
{
..
//HERE
for (qp = nsqhead; qp != NULL; qp = qp->q_link) {
if (qp->q_id == id &&
memcmp(&qp->q_from, &from, sizeof qp->q_from) == 0 &&
((qp->q_cmsglen == 0 && qp->q_msglen == msglen &&
memcmp(qp->q_msg + 2, msg + 2, msglen - 2) == 0) ||
(qp->q_cmsglen == msglen &&
memcmp(qp->q_cmsg + 2, msg + 2, msglen - 2) == 0)
) {
ns_debug(ns_log_default, 3, "forw: dropped DUP
id=%d",
ntohs(id));
nameserIncr(from.sin_addr, nssRcvdDupQ);
return (FW_DUP);
}
}
}
//Insert this line of code to correct the problem ||
(!strcmp(qp->q_name,dname)) )
for (qp = nsqhead; qp != NULL; qp = qp->q_link) {
if (qp->q_id == id &&
memcmp(&qp->q_from, &from, sizeof qp->q_from) == 0 &&
((qp->q_cmsglen == 0 && qp->q_msglen == msglen &&
memcmp(qp->q_msg + 2, msg + 2, msglen - 2) == 0) ||
(qp->q_cmsglen == msglen &&
memcmp(qp->q_cmsg + 2, msg + 2, msglen - 2) == 0)
) || (!strcmp(qp->q_name,dname)) ) // HERE
{
ns_debug(ns_log_default, 3, "forw: dropped DUP
id=%d",
ntohs(id));
nameserIncr(from.sin_addr, nssRcvdDupQ);
return (FW_DUP);
}
}
>BTW, what does BIND 9 do to prevent this?
The BIND 9 doesn.t generate multiple simultaneous queries for the same
resource record.
Only THIS. The problem is in the BIND implementation. The ISC think not.
However, you can see and analyze that an only code line resolve part of
the problem. Of course It does not resolve problems of brute force
attacks, but resolve the problem that I reported.
|| (!strcmp(qp->q_name,dname)) )
If the ISC and other vendors correct their code, they will reduce
almost 98% success probability of an attacker to implement the
attack remotely. The 2 % is attacks successfully via brute force.
>> . configure anti-spoofing rules on the firewall or border router;
>>
>> . considering the network topology, set up the DNS server into a DMZ
>> (demilitarized zone).
>
>Maybe I am missing something but how will this prevent cache poisoning
>of the DNS server in the DMZ? (assuming it does recursion)
>Inbound DNS replies (with spoofed source IP address) to
>DNS requests forwarded to Internet servers will look perfectly valid to
the
>border router or firewall.
This way (DNS in the DMZ), you can to dropp packets sent to your DNS
that are using spoofed source IP address of your local network. This
is the first step to implement attack. The attacker has to do the
target DNS server to generate multiple simultaneous queries for the
same rr. If you has configured this option in named.conf:
allow-query{IP-internals;}; the attacker will try use IP-internal to
generate the queries for the same rr.
If the ISC doesn.t correct the problem, perhaps, I can send the
exploit that I implemented to the list (bugtraq and other).
I can assure that I get to implement DNS Spoofing attacks with high
probability of success with very facility in BIND 8.3.4 and 4.9.11
(Released November 16th, 2002 by ISC)
Iván, thanks by observations.
Regards,
Vagner Sacramento
(85640) /Vagner Sacramento <vagner@natalnet.br>/(Ombruten)
Kommentar i text 85622 av Iván Arce <core.lists.bugtraq@core-sdi.com>
85622 2002-11-28 18:52 /274 rader/ Iván Arce <core.lists.bugtraq@core-sdi.com>
Importerad: 2002-11-28 18:52 av Brevbäraren
Extern mottagare: <BUGTRAQ@SECURITYFOCUS.COM> <core.lists.bugtraq@corest.com>
Mottagare: Bugtraq (import) <2583>
Kommentar till text 85640 av Vagner Sacramento <vagner@natalnet.br>
Sänt: 2002-11-29 09:25
Ärende: RE: CAIS-ALERT: Vulnerability in the sending requests control of BIND
------------------------------------------------------------
Hi Vagner,
I understand your point but I think the problem remains
the same.
What I am saying is that the attack you mention is a variation
of the something known for years as a result of discussing a fix
for the predictable sequence ID problem, which in turn was triggered
by the SChuba and Spafford paper of 1993.
Namely that there is a fundamental design flaw than makes DNS
vulnerable to cache poisoning either way: a 16bits space for
query IDs is NOT ENOUGH. You can predict them, brute force the
entire space or elaborate any other attack with a good degree
of sucess in any case. Any way you at look it, 16 bits and weak
authentication of reponses will just not do suffice to prevent
the problem.
> At first site It may looks like the vulnerability reported cited by you,
> but in fact It isn.t.
>
> The CERT did the same question when we were doing tests. Of course, if was
> the same attack released in 1993 the CERT had not released a Vulnerability
> Note.
>
> http://www.kb.cert.org/vuls/id/457875
>
>
> >Original advisory posted in 1997:
> >
> >http://www.codetalker.com/advisories/sni/sni-12.html
> >http://www.corest.com/common/showdoc.php?idx=133&idxseccion=10 (spanish)
>
> I know this attack methodology. Christopher Schuba and Eugene Spafford
> outline this attack in the paper "Addressing weaknesses in the Domain Name
> System Protocol" in COAST Laboratory, Department of Computer Science,
> Purdue University, 1993.
The attack outlined in Schuba and Spafford paper calls for the
attacker to control a primary nameserver or to use source routed
packet.
The attack in the cited 1997 SNI advisory show that source routed
packets or control of a primary nameserver is not needed since the
query IDs can be predicted almost blindly.
This triggered discussion on how to fix the problem back
in 1997, and as the comments on the patch for the then
current BIND version suggest, there is no way to
fix the problem because even if you randomize the query
IDs, there isnt strong authentication of responses
(crypographically strong, that is) and even if there
was, 16 bits is just not enough to prevent sucessful
exploitation.
>
> This attack is the simplest and most widely used attack to do DNS Spoofing
> on bind 8.1.x, 4.9.3, 4.9.5 and 4.9.6. Bind running with these versions
> increase the ID by 1 for each query. They don.t randomize the dns id. This
> is a problem of pedictable ID's and not the problem that I reported.
>
> The algorithm initially used to generate ID in BIND 8.1.x and 4.9.[3-6]
>
> u_int16_t nsid_next()
> {
> ! if (nsid_state == 65535)
> ! nsid_state = 0;
> ! else
> ! nsid_state++;
> return (nsid_state);
> }
>
> :-), :-)
OpenBSD produced unpredictable query IDs since 1997 using
BIND-4.9.5-P1, why ISC and the "official" BINd did not incorporate
this and kept using predictable IDs up till 8.2.x escapes my
understanding.
>
> BIND Versions current (8.3.4, 4.9.11) and older (8.2.x, 9.x) are not
> vulnerable to the attack presented in this advisory (cited by you).
>
> However, I get to implement DNS Spoofing attacks remotely with very easily
> in the bind 8.3.4 ,4.9.11 and older bind, and I can prove THIS.
>
> The problem that I described attests BIND versions 4 and 8 do not prevent
> sending of two or more resolution requests for the same domain name
> allowing DNS Spoofing attacks with significant probability of success,
> then I implemented specific techniques (originals) to have good results in
> the attacks.
Even if you prevented this you what very good sucess probabilities
>
> In the link cited by you, the attacker has complete control of
> DNS.ATTACKER.COM's network, he can both spoof and sniff DNS packets there.
No, he has complete control of his own box, in order to spoof/sniff
one only needs to be root on your favourite Linux system or
Administrator on Windows, etc.
> In particular, he can sniff DNS packets sent to DNS.ATTACKER.COM. The
> attacker needs to get the IDs to send the replies.
Yes, that's in the 1997 advisory, but EVEN if he doesnt get the IDs
he can blindly send responses with different IDs hoping that
one will match the query ID of the DNS request.
>
> The attacker sniff DNS.ATTACKER.COM's local network and retrieve the query
> packet
> sent by DNS.TARGET.COM to DNS. ATTACKER.COM. He can then determine the
> query ID (qid0) and source port used by DNS.TARGET.COM. Chances are that
> the next queries generated by DNS.TARGET.COM will have query IDs that will
> fall in the range [qid0,qid0+N] where N is dependent on the amount of
> queries DNS.TARGET.COM is generating in the period of time on which the
> attack takes place. N is usually <= 15 for most cases.
>
> In this attack methodology (released by Schuba) is not implemented
> anything to determine the source IP address that should be used in the
> reply packet because the attacker get the victim DNS current ID (sniffing
> technique) and other.
This is obvious.. uh guess what the source IP address should be? If
I am trying to point www.microsort.org to my own IP, the source IP
address of my spoofed DNS responses should be that of microsort.org's
primary nameserver.
>
> In my attack methodology, I implemented techniques to determine ID, Source
> IP address and the attacker can apply the attack successfully FROM any
> network. The attacker does not need to be at the same DNS.ATTACKER.COM's
> local network. The attacker does not NEED to sniff queries to determine
> the source port and ID.
>
> The success probability in my attack methodology to implement of DNS
> Spoofing attack in BIND 4 and BIND 8 is calculated by the equation:
> n-request-sent/65535, where n-request-sent is the number of requests sent
> simultaneously to the target DNS server.
>
> Another difficulty that I have in the remote attack is to imprecision from
> establishing the ID to be used in the replies. In example presented, the
> attacker doesn.t have difficulty because the his host keeps capturing all
> packets in its local net, applying a sniffer technique. ;-):-)
>
>
> >+ /*
> >+ * The 16 bit space is very small and brute force attempts are
> >+ * entirly feasible, we skip a random number of transaction ids
> >+ * so that an attacker will not get sequential ids.
> >+ */
> Using only brute force, the attack is very difficult to be applied. I
> tried this several times. I did several tests in my experiments. The
> probability of success is very low to get implement the attack using only
> brute force.
The probability of sucess is exactly: m-responses-sent/65535 If I
sent 65535 DNS responses with a different ID on each one one of them
will hit the right ID.
The attack is basically the same.
Either you sent N spoofed requests or you send M spoofed responses.
The network traffic generated is also the same and in both cases
there is still a race to win against the real DNS.
>
>
> >BTW, what does BIND 9 do to prevent this?
> The BIND 9 doesn.t generate multiple simultaneous queries for the same
> resource record.
This does not prevent exploitation
> Only THIS. The problem is in the BIND implementation. The ISC think not.
No, the problem is in the protocol.
> However, you can see and analyze that an only code line resolve part of
> the problem. Of course It does not resolve problems of brute force
> attacks, but resolve the problem that I reported.
>
> || (!strcmp(qp->q_name,dname)) )
>
> If the ISC and other vendors correct their code, they will reduce almost
> 98% success probability of an attacker to implement the attack remotely.
> The 2 % is attacks successfully via brute force.
Perhaps a better fix would be not generating multiple queries for
the same resource record AND invalidating pending outgoing requests
when a thresold of responses with invalid QIDs is reached. However,
this also opens the door for a DoS attack...
>
> >> . configure anti-spoofing rules on the firewall or border router;
> >>
> >> . considering the network topology, set up the DNS server into a DMZ
> >> (demilitarized zone).
> >
> >Maybe I am missing something but how will this prevent cache poisoning
> >of the DNS server in the DMZ? (assuming it does recursion)
> >Inbound DNS replies (with spoofed source IP address) to
> >DNS requests forwarded to Internet servers will look perfectly valid to
> the
> >border router or firewall.
>
> This way (DNS in the DMZ), you can to dropp packets sent to your DNS that
> are using spoofed source IP address of your local network. This is the
Yes but you dont need to spoof internal victim's addresses to
force the DNS to send queries.
Also, this is specific to the attack you described, if what you
spoof are the DNS responses as if they were coming from the
real DNS servers that the victim queried, theres nothing the firewall
can do, unless it was a stateful DNS proxy that matches inbound QIDs
in the DNS responses to outbound QIDs of DNS requests.
> first step to implement attack. The attacker has to do the target DNS
> server to generate multiple simultaneous queries for the same rr. If you
> has configured this option in named.conf:
> allow-query{IP-internals;}; the attacker will try use IP-internal to
> generate the queries for the same rr.
>
Which is completly feasible.
Anti-spoofing at the border does not prevent the attacker from
forcing resolver queries fromthe victim to her DNS from perfectly
legitimate hosts at the victim's network, which in turn will have
the DNS recurse and go out to the Internet to find out about IP
addresses of unknown hosts.
> I can assure that I get to implement DNS Spoofing attacks with high
> probability of success with very facility in BIND 8.3.4 and 4.9.11
> (Released November 16th, 2002 by ISC)
I have not doubt whatsoever about that!
>
> Iván, thanks by observations.
>
>
> Regards,
>
> Vagner Sacramento
>
-ivan
---
Perscriptio in manibus tabellariorum est
Noli me vocare, ego te vocabo
Ivan Arce
CTO
CORE SECURITY TECHNOLOGIES
44 Wall Street - New York, NY 10005
Ph: (212) 461-2345
Fax: (212) 461-2346
http://www.corest.com
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A
--- for a personal reply use: =?iso-8859-1?Q?Iv=E1n_Arce?=
<iarce@core-sdi.com>
(85622) /Iván Arce <core.lists.bugtraq@core-sdi.com>/(Ombruten)