On Fri, 2 Feb 2001, Bill Woodcock wrote:

On Fri, 2 Feb 2001, Patrick Greenwell wrote: > By the same token one might argue that atempting to hide vunerabilities > to those paying you for "early warnings" doesn't help at all.

Not at all... If you're trying to hide a vulnerability by lying about your version number, that presupposes generally-held knowledge of an association between a vulnerability and a version number.

"Early warning" is specifically a means of delaying the general availability of knowledge of that association.

Which leaves those that have not been informed of such vunerabilities acutely vunerable. Script kiddies may be stupid, but the people writing the program that they utilize generally aren't. Without rehashing the whole "open-disclosure" vs. "non-disclosure" arguments related to security issues in software, or the historically extreme inadequacies of CERT in offering timely notification of ANY security-related issues, it's very disappointing to see ISC resort to a fee-based, non-public-disclosure-at-the-time-of-discovery, NDA'd and "we'll update people via CERT" method of dealing with the community they have served for so long. I would have hoped by now that lists such as Bugtraq would have adequately exhibited the folly of such methodologies. Obviously that is not the case.

On Fri, 2 Feb 2001, Joe Rhett wrote:

...

Without rehashing the whole "open-disclosure" vs. "non-disclosure" arguments related to security issues in software, or the historically extreme inadequacies of CERT in offering timely notification of ANY security-related issues, it's very disappointing to see ISC resort to a fee-based, non-public-disclosure-at-the-time-of-discovery, NDA'd and "we'll update people via CERT" method of dealing with the community they have served for so long.

I would have hoped by now that lists such as Bugtraq would have adequately exhibited the folly of such methodologies.

The purpose of the list doesn't appear to circumvent Bugtraq -- you're comparing two different issues.

I suggest you re-read the pre-announcement, and also factor in other statements made by Paul that the community will now be notified via CERT when security problems occur. CERT has historically been worthless in this regard(IMO). By the time they release warnings, the problems have been well known among the security and dark-hat communities for weeks, months or in extreme cases years. In all fairness I believe this has been due to the vendors being unwilling to release the information, rather than due to any fault of CERT staff. In any case the result is the same: information is late in coming to anyone that relies on CERT for that information, exposing those individuals/organizations to a greater level of vunerability and risk than they would otherwise face. It's foolish to rely on CERT notifications as the most timely information one could acquire. Finally, I'm not sure what you'd call NDAs that would prevent disclosure of security problems, but I'd say that's about as opposite of Bugtraq as you can get. P.S. AboveNet is taking the latest BIND vunerability(ies) seriously enough that they are beginning wholescale scans of their address space. Draw your own conclusions related to masking version numbers.

On Fri, 2 Feb 2001, Patrick Greenwell wrote:

P.S. AboveNet is taking the latest BIND vunerability(ies) seriously enough that they are beginning wholescale scans of their address space. Draw your own conclusions related to masking version numbers.

The bulk of that announcement from Above.net is from 2 lines:

We will be checking every IP in our space on port 53 in order to find versions of BIND open to a root exploit.

I'm not sure my agreement with Above.net allows them to scan my network, though it is admittedly their IP space. I'll go check the paperwork on Monday. (Honestly I expect to find it does, though I must have been smoking something when I signed it. Above.net is usually on stable legal ground.) That aside, I am concerned that the announcement makes no mention of who they would disclose this information to. Presumably the registered contacts for the offending customer, but above.net has not said they'll tell anyone. Needless to say, I am not happy with this. I can't imagine anyone would be happy with their provider scanning their network. (Also leaving aside the fact that this scan will be pretty much useless, given cases where named is run as a different user, chroot'd, instructed to lie about its version number, etc.) Matthew Devney

...

Needless to say, I am not happy with this. I can't imagine anyone would be happy with their provider scanning their network.

Especially considering above.net:s adament stand on ORBS and their scanning.

I don't believe it's ever been claimed that ORBS is not free to scan their own address space.

Massive irony?

Grasping at straws? Stephen

Mikael Abrahamsson wrote:

Especially considering above.net:s adament stand on ORBS and their scanning.

Massive irony?

Nah, I don't think so. RoadRunner's security czar has said repeatedly said that RR scans its customers for security holes. I don't see a problem with that either. Scanning the networks you are responsible for is one thing. Scanning an outside network, and not stopping when asked to stop on top of that, is another thing altogether. -- Steve Sobol, BOFH, President 888.480.4NET 866.DSL.EXPRESS 216.619.2NET North Shore Technologies Corporation http://NorthShoreTechnologies.net JustTheNet/JustTheNet EXPRESS DSL (ISP Services) http://JustThe.net mailto:sjsobol@NorthShoreTechnologies.net Proud resident of Cleveland, Ohio

On Sat, Feb 03, 2001 at 09:44:54AM +0100, Mikael Abrahamsson wrote:

Especially considering above.net:s adament stand on ORBS and their scanning.

Massive irony?

<DISCLAIMER> I am a former abovenet employee </DISCLAIMER> It's self defense. Do you know how big of a pain in the ass it is when 100 customers get owned and script kiddies start launching <insert name of 'sploit here> from abovenet colos? AboveNet has seen this happen too many times and they don't want to see it again. I am sure only the proper tech contacts for the customer will be notified. Some how I doubt AboveNet will scan the entire IP range, generate a list of customers that are running systems with security problems, and then post that list to NANOG. Please go hassle UUNET for not filtering port 25 on their dial pools or something! -- Steve Rubin / KG6DFV / Phone: (408)270-3258 Fax: (408)270-3273 Email: ser@tch.org / N57DL / http://www.tch.org/~ser/

On Mon, 5 Feb 2001, Stephen J. Wilcox wrote:

.. no good deed goes unpunished on nanog .. heh

a tad sad and petty tho that a few people have moaned about abovenet doing this and no one has thanked them for looking out for them

I'm not saying that Above.net is doing a bad thing when they're scanning their customers for vulnerable named version, I'm saying they're doing something wrong when filtering ORBS.

imho a great deal of customers are not on the right cert lists and not up to speed enough to realise they have a problem

Amen, dito with the open relay/spam problem. No need to continue this thread, I think everybody knows where everybody stands on the ORBS issue. -- Mikael Abrahamsson email: swmike@swm.pp.se

On Sat, Feb 03, 2001 at 12:35:32AM -0800, mdevney@teamsphere.com wrote:

On Fri, 2 Feb 2001, Patrick Greenwell wrote:

...

P.S. AboveNet is taking the latest BIND vunerability(ies) seriously enough that they are beginning wholescale scans of their address space. Draw your own conclusions related to masking version numbers.

The bulk of that announcement from Above.net is from 2 lines:

...

We will be checking every IP in our space on port 53 in order to find versions of BIND open to a root exploit.

I'm not sure my agreement with Above.net allows them to scan my network, though it is admittedly their IP space. I'll go check the paperwork on Monday. (Honestly I expect to find it does, though I must have been smoking something when I signed it. Above.net is usually on stable legal ground.)

That aside, I am concerned that the announcement makes no mention of who they would disclose this information to. Presumably the registered contacts for the offending customer, but above.net has not said they'll tell anyone.

Needless to say, I am not happy with this. I can't imagine anyone would be happy with their provider scanning their network.

(Also leaving aside the fact that this scan will be pretty much useless, given cases where named is run as a different user, chroot'd, instructed to lie about its version number, etc.)

most providers can nullroute ip space due to AUP violations. This includes open relays and other "security" risks. I'd not want to be abovenet security team responding to queries about why all my customers had rooted machines and were attacking <big-e-business-name-here>. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | Manager of IP networks built within my own home

...

The purpose of the list doesn't appear to circumvent Bugtraq -- you're comparing two different issues.

I suggest you re-read the pre-announcement, and also factor in other statements made by Paul that the community will now be notified via CERT when security problems occur. CERT has historically been worthless in this regard(IMO). By the time they release warnings, the problems have been well known among the security and dark-hat communities for weeks, months or in extreme cases years. In all fairness I believe this has been due to the vendors being unwilling to release the information, rather than due to any fault of CERT staff.

I'm no fan of CERT. Neither is Paul to my memory, but he can hardly advocate Bugtraq to some of the communities in which he must play ball.

In any case the result is the same: information is late in coming to anyone that relies on CERT for that information, exposing those individuals/organizations to a greater level of vunerability and risk than they would otherwise face. It's foolish to rely on CERT notifications as the most timely information one could acquire.

What exactly does Paul's list have to do with this? You're still confusing a software update channel with a response center. He's not creating a response center, and neither would I in his circumstances. He's creating something that doesn't exist at this point, not taking anything away from anyone. All of us knew about severe bugs in BIND months, sometimes years before CERT reported an exploit. Paul's list may get the right information into the right hands sooner. Your complaint seems to boil down to the fact that he's not building an organization to replace CERT. As another small business owner, I can guess that he's got enough on his hands. If you feel this burning need for this, do it yourself! Stop confusing a support channel with a response center.

Finally, I'm not sure what you'd call NDAs that would prevent disclosure of security problems, but I'd say that's about as opposite of Bugtraq as you can get.

echo "Stop confusing a support channel with a response center." If I was paying a software vendor for support, and they released information to the public before they gave me a chance to upgrade my vulnerable systems, I would hand them a lawsuit with a number you'd have trouble imagining. Thus, my software vendors better damn well have a closed-circuit channel to get me information on vulnerabilities with enough time to upgrade my software. HP, Sun, IBM and everyone else has contracts with the government and private institutions that require immediate access to this information. If Paul were to simply report a vulnerability to the world with giving these vendors a chance to produce patches for their customers, they would be forced to find another vendor for BIND. You're applying an old rant about open access to vulnerability information in the wrong place. Vulnerabilities _do_ need to be published, but not _before_ software vendors have a reasonable chance to update their software and produce patches! Note: I'm not replying to anything else on this topic. People clearly aren't thinking properly about this, and I'm not going to waste my time arguing with illformed, biased 'religion' that has no place in the real world. -- Joe Rhett Chief Technology Officer JRhett@ISite.Net ISite Services, Inc. PGP keys and contact information: http://www.noc.isite.net/Staff/