The BIND scandal

[Bob Keyes-2]

What's really sad is that bad attitudes from various OS security
organizations, such as some people at FreeBSD, has made some people less
willing to share vulnerabilities that they have discovered. I speak
specifically from my experience in the year 2000, regarding the NAPTHA
DoS. Mr. Robert Watson was quite uncivilized in his criticisms of me and
the disclosure, even though it had been handled in the most reasonable way
(through CERT).

You may not believe it, but I've known about this BIND problem for some
years, but kept it in my vest pocket. Why? Because I was tired of being
made to suffer for doing what was right.

I have an inkling about other problems which affect commonly used
open-source software, but I see no reason to do a thorough investigation
and disclose the results in a responsible way. Because of the bad
attitudes of a number of people in the security community, I've been very
quiet, not revealing any of my accidental discoveries nor pursuing fixes
for the problems I see.

Until reasonable and diplomatic people are installed as the security
contacts for organizations such as FreeBSD, I will only make patches
available to me and my close friends.

Perhaps I am wrong, and that people who flamed me for my disclosure have
grown up. I'd like to think so.

-R. Keyes
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Poul-Henning Kamp]

In message <Pine.LNX.4.64.0808021459580.23103@...>, Bob Keyes
writes:

>Until reasonable and diplomatic people are installed as the security
>contacts for organizations such as FreeBSD, I will only make patches
>available to me and my close friends.

I can warmly recommend you read the book "Blackmailing for dummies",
as I can see that you make several classical beginner mistakes in
this attempt.

Better luck next time.

Poul-Henning

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@...         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Bob Keyes-2]

On Sat, 2 Aug 2008, Poul-Henning Kamp wrote:

> In message <Pine.LNX.4.64.0808021459580.23103@...>, Bob Keyes
> writes:
>
>> Until reasonable and diplomatic people are installed as the security
>> contacts for organizations such as FreeBSD, I will only make patches
>> available to me and my close friends.
>
> I can warmly recommend you read the book "Blackmailing for dummies",
> as I can see that you make several classical beginner mistakes in
> this attempt.

I really don't care to blackmail anyone. That's what's really great about
the BSD license, I can keep my fixes to myself.

Of course, what I am wondering right now is, why did I even bother telling
you all this. But some of your are as well. Maybe there's some area for
agreement.
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Poul-Henning Kamp]

In message <Pine.LNX.4.64.0808022207080.12307@...>, Bob Keyes
writes:

>Of course, what I am wondering right now is, why did I even bother telling
>you all this. But some of your are as well.

No, I'm not wondering the least, it was pretty obvious that you behaved
like a spurned primadonna type and now you were going to tell us how
much we were missing out because we did not cater to your every whim
and fancy.

And since you had nothing concrete to bargain with, all you could do
was say "Ha!, then you can't play with my dolls!" and go home with your
nose in the sky, hoping that we would feel really miserable.

Well, we don't.

The FreeBSD project has been attempted blackmailed many times over
the year, and it havn't worked yet, and it won't ever, if I can
prevent it.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@...         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Adrian Penisoara]

Hi,

On Sun, Aug 3, 2008 at 9:05 AM, Poul-Henning Kamp <phk@...>wrote:

>
> The FreeBSD project has been attempted blackmailed many times over
> the year, and it havn't worked yet, and it won't ever, if I can
> prevent it.
>

  Sorry to suddenly stump into this, but can we get a bit more background on
what is being referred to here and also the initial mail ? Just point me to
relevant references if there are any, besides [1].

  Mind me, but I think this may not be the most professional way to deal
with such situations and I hate to see such (kiddish ?) arguments flow by on
a FreeBSD/security list...

[1] http://seclists.org/bugtraq/2000/Dec/0317.html

Thank you,
Adrian.
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Doug Barton]

Bob is quite obviously trolling for a fight here, and I'm definitely
not going to get sucked into that.

I would like to point out however that the _DNS_ vulnerability that is
currently in wide discussion is not in any way related to BIND, it's a
fundamental flaw in the protocol related to response forgery. All
major vendors of DNS systems and the IETF working groups on DNS are
trying to find a permanent solution for this problem. As a stop-gap
measure ISC has adopted the same solution for BIND that has proven
effective for other vendors, randomizing the query source port. You
can find more information about this issue here:

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447
  http://www.kb.cert.org/vuls/id/800113
  http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience


Hope this helps,

Doug

--

     This .signature sanitized for your protection

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Matt Dawson-2]

On Sunday 03 Aug 2008, Doug Barton wrote:
> Hope this helps,

What actually did help was your most rapid update of the BIND ports to -p2
yesterday. You managed all of them three hours before I got the SANS
handler's diary on the new releases from RSS!

Just wanted to say thanks for that. Your work is appreciated.
--
Matt Dawson.

matt@...
MTD15-RIPE
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Doug Barton]

Matt Dawson wrote:
> On Sunday 03 Aug 2008, Doug Barton wrote:
>> Hope this helps,
>
> What actually did help was your most rapid update of the BIND ports to -p2
> yesterday. You managed all of them three hours before I got the SANS
> handler's diary on the new releases from RSS!
>
> Just wanted to say thanks for that. Your work is appreciated.

Thank you for the kind words. :)

Since this update is performance related rather than directly security
related I plan to give people a chance to update from ports and
provide feedback before I update the base in HEAD and [67]-stable. So
if you run a busy resolving name server, especially if you were having
problems with -P1, then please let me know how -P2 works for you.


Doug

--

     This .signature sanitized for your protection

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Len Conrad]

http://www.freshports.org/search.php?query=bind9&search=go&num=10&stype=name&method=match&deleted=excludedeleted&start=1&casesensitivity=caseinsensitive


... shows 9.5.0.2 but the PortsMon page shows Latest as 9.5.0.1

Len


_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Thomas Rasmussen-5]

> Thank you for the kind words. :)
>
> Since this update is performance related rather than directly security
> related I plan to give people a chance to update from ports and
> provide feedback before I update the base in HEAD and [67]-stable. So
> if you run a busy resolving name server, especially if you were having
> problems with -P1, then please let me know how -P2 works for you.
>
>
> Doug
>

Hello,

I'd also like to thank you for updating the port so fast, I was hoping
for sometime during the weekend, and was pleasantly surprised to see it
available so fast.

I've posted to the bind-users list to say this, but to confirm here: On
7-STABLE from a few weeks ago on a couple of busy recursive servers,
this patch made an extreme positive difference. I was having problems
with constant timeouts, very slow recursive lookups when they did work,
and frequent errors about too many open files or somesuch in messages
(regardless of kern.maxfiles and FD_SETSIZE settings), all of this
disappeared when I applied P2. Number of successful queries almost
doubled the minute I restarted with the -P2 patch applied, no more
slowness or timeouts.

This is the bind9.4 port by the way, 9.5 had even more weird errors and
behaviour. I've since seen various sources claiming that 9.5 isn't ready
for primetime on busy resolvers, so I'll wait for a while before moving
on to 9.5.

For the record, I have compiled dns/bind94 with

        make CFLAGS="-DFD_SETSIZE=65000" install clean

to avoid "too many open file descriptors" errors, but with this setting
(and increasing kern.maxfiles with sysctl) everything seems to be
running nicely. -P2 might have removed the need for increasing
FD_SETSIZE but this works, and for now I'll leave it at that.

These servers have peak loads at around 1000 queries per second. They
are both quad core 2-3ghz boxes with a couple of gigs of ram, and the
cpu is around 50% utilized when the servers are busy.

If you need more information please let me know.

Best regards and thank you for all your work.

Thomas Rasmussen
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Doug Barton]

Thomas Rasmussen wrote:
> I've posted to the bind-users list to say this, but to confirm here: On
> 7-STABLE from a few weeks ago on a couple of busy recursive servers,
> this patch made an extreme positive difference. I was having problems
> with constant timeouts, very slow recursive lookups when they did work,
> and frequent errors about too many open files or somesuch in messages
> (regardless of kern.maxfiles and FD_SETSIZE settings), all of this
> disappeared when I applied P2. Number of successful queries almost
> doubled the minute I restarted with the -P2 patch applied, no more
> slowness or timeouts.

That's good news even taking your change to fd_setsize into account.

> This is the bind9.4 port by the way, 9.5 had even more weird errors and
> behaviour. I've since seen various sources claiming that 9.5 isn't ready
> for primetime on busy resolvers, so I'll wait for a while before moving
> on to 9.5.

Yeah, if you don't have time to help debug the problems then sticking
with 9.4 is a good decision. OTOH they can use all the help they can
get. :)

> For the record, I have compiled dns/bind94 with
>
>        make CFLAGS="-DFD_SETSIZE=65000" install clean
>
> to avoid "too many open file descriptors" errors, but with this setting
> (and increasing kern.maxfiles with sysctl) everything seems to be
> running nicely. -P2 might have removed the need for increasing
> FD_SETSIZE but this works, and for now I'll leave it at that.

I can certainly understand not wanting to change something that's
working, but I would like to get at least a couple of users to confirm
that -P2 works out of the box before I import them. I don't mind
adding a "big fd_setsize" knob to the ports and the base, but I want
to be sure it's needed first.

Doug

--

     This .signature sanitized for your protection

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."