Mailing List Archive

On Thu, Jul 11, 2002 at 01:42:16PM +0200, Simon Richter wrote:

Simon,

You may wish to subscribe to the list so that you and others may debate this
issue. The list is configured so that non-members may not post.

> To me, the term "full disclosure" does not mean "make it available as fast
> as possible", but rather "here is the information, expect it to leak in
> the next two weeks, so go out and fix the bug". The current bugtraq scheme
> enforces that, and I believe they are doing a great job.

We are placing the responsibility with the individual, not with an
organisation here. What we do not believe in is having a situation where
a select few are aware of a problem, but 99% of the internet populace are
powerless to defend against it. We are not saying that the vendor should not
be informed, we are saying, inform the people and the vendor simultaneously.

> By creating a forum in which vulnerability spotters can get "instant
> fame", you are forcing software vendors to monitor the forum 24/7, as a
> new vulnerability in their software could be disclosed anytime, and at the
> moment it is disclosed, script kiddies are hacking it into their scanners
> while it could be 4 am in the vendor's timezone. If we are lucky enough
> that the vulnerability is spotted by a whitehat, we should not jeopardize
> the time advantage we have by announcing it publically.

This situation already occurs. If a researcher leaks information to a few
'allies', if a technique is discovered 'in the wild', or if a vendor silently
fixes unknown problems, then there are those who possess the knowledge and
those that don't. We are simply providing a forum for those who wish to try
and balance out this situation.

> In short, I think this is a bad idea because it adds confusion for the
> vulnerability spotters, risks early disclosure before fixes are available
> and thus harms the users.

Early disclosure is important, IMO, as was proved with the recent Apache flaw.
I believe there were reports of Gobbles' exploit being active in the wild long
before the patched packages were available, and being alerted to the problem
even if there was no fix would have at least given admins a 'heads-up' and
allowed people to make informed business decisions. Of course, this is our
personal opinion, but we hope that others concur and wish to share in our
resource.

- John

Simon Richter wrote:
> To me, the term "full disclosure" does not mean "make it available as fast
> as possible", but rather "here is the information, expect it to leak in
> the next two weeks, so go out and fix the bug". The current bugtraq scheme
> enforces that, and I believe they are doing a great job.

There is no Bugtraq "scheme". The Bugtraq moderator does not hold any
posts. The poster gets to decide when his informatino is released. The
people who post to Bugtraq as just as able to blindside a vendor as on any
other mailing list.

The closest thing to what you describe that is offered by SecurityFocus is
the vulnhelp service. This is a way for someone who finds a bug to
voluntarily dump the hassle of dealing with notifying the vendor and
waiting onto the SecurityFOcus staff. Someone who uses vulnhelp still
wants to give the vendor advanced notice, they just don't want to do it
themselves. If they don't want the vendor to have any warning, they just
post to Bugtraq.

BB

On Thursday 11 July 2002 09:57 am, you wrote:
>Early disclosure is important, IMO, as was proved with the recent Apache
> flaw. I believe there were reports of Gobbles' exploit being active in the
> wild long before the patched packages were available, and being alerted to
> the problem even if there was no fix would have at least given admins a
> 'heads-up' and allowed people to make informed business decisions. Of
> course, this is our personal opinion, but we hope that others concur and
> wish to share in our resource.

The choice is between helping those who work hard to stay on top of security
issues and those who don't. (Rest assure that the underground knows about
holes very early on, often before bugtrack reports it. Even if they don't on
any single issues, that policy is still too high of a risk to gamble on.)

It is clear that if you are at least aware of the situation you can decide
how or what you want to do about it. You can disable, modify or ignore it,
and even push the developer to do it, but at least it's your call.

Some animals in the wild use the defense of being one of many as their
defense from being targeted as dinner. However obscurity is only slightly
better than nothing.

The fact that most admins don't understand or have the time readily available
to spend on security is a flaw, a deviation from the ideal scene and cannot
be used as an excuse to put those who work hard to keep security in, at risk.

It is a sad reflection of society at large that we have to go through all
this pain just to operate a business, but it is also the world we live in so
get organized and do what you can to stay on top of it.
--

Steve Szmidt
V.P. Information Technology
Video Group Distributors, Inc.

On Thu, 11 Jul 2002, Blue Boar wrote:

> Simon Richter wrote:
> > To me, the term "full disclosure" does not mean "make it available as fast
> > as possible", but rather "here is the information, expect it to leak in
> > the next two weeks, so go out and fix the bug". The current bugtraq scheme
> > enforces that, and I believe they are doing a great job.
>
> There is no Bugtraq "scheme". The Bugtraq moderator does not hold any
> posts. The poster gets to decide when his informatino is released. The
> people who post to Bugtraq as just as able to blindside a vendor as on any
> other mailing list.

Speaking from personal experience, the current bugtraq moderator
does, and the previous moderator also did, "hold" certain posts.
The cases I have seen fall into one of two categories:

1. having doubts about the authenticity of the information in the post
2. seeing if the poster would like to voluntarily withhold it temporarily
and work with vendors.

Certainly, if the authenticity of the information is not in question and
if the poster insists on posting it, then I have no indication that it
would be withheld. I also don't have any reason to think this happens
frequently. But there is an extra layer there that, in some cases, does
result in submitted posts being delayed, normally with the consent of the
poster.

I'm not really sure of the need for a "full-disclosure" list, but time
will tell.

BTW, spewing "[full-disclosure]" into the subject line is a very annoying
thing for a list to do.

On Thu, Jul 11, 2002 at 09:04:21AM -0700, Blue Boar wrote:
> There is no Bugtraq "scheme". The Bugtraq moderator does not hold any
> posts. The poster gets to decide when his informatino is released. The
> people who post to Bugtraq as just as able to blindside a vendor as on any
> other mailing list.
>
> The closest thing to what you describe that is offered by SecurityFocus is
> the vulnhelp service. This is a way for someone who finds a bug to
> voluntarily dump the hassle of dealing with notifying the vendor and
> waiting onto the SecurityFOcus staff. Someone who uses vulnhelp still
> wants to give the vendor advanced notice, they just don't want to do it
> themselves. If they don't want the vendor to have any warning, they just
> post to Bugtraq.
>
> BB

I disagree, I think my DOCSIS vulnerability posting is a good example of
something that should have gone out immediately, but was /never/ posted.
( I ended up taking it to another list)

It was valid, the vendors knew, but it was withheld because you deemed it
'malicious'.

--
Matthew S. Hallacy FUBAR, LART, BOFH Certified
http://www.poptix.net GPG public key 0x01938203

On Thu, 11 Jul 2002, Marc Slemko wrote:


[SNIP]

>
> BTW, spewing "[full-disclosure]" into the subject line is a very annoying
> thing for a list to do.
>

Actually, it makes it quite easy for procmail recipies and certain mail
readers to filter and categorize the messages. What gets annoying is when
there's a ton of html crap preceeding messages, or those folks spewing
vactions into the lists. Not to mention those danged content filters that
are set to prevent folks from being offended by words like damn...

Thanks,



Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D. Just don't touch anything.

Hi,

>> To me, the term "full disclosure" does not mean "make it available as
>> fast
>> as possible", but rather "here is the information, expect it to leak in
>> the next two weeks, so go out and fix the bug". The current bugtraq
>> scheme
>> enforces that, and I believe they are doing a great job.

> We are placing the responsibility with the individual, not with an
> organisation here.

IMHO an organisation has a greater chance of doing things right than a
number of individuals. For example, I do not have a complete list of
Linux/BSD/Unix distributors' security contacts, and I believe many
others out there haven't either, however such a list is vital for vendor
notification.

> What we do not believe in is having a situation where
> a select few are aware of a problem, but 99% of the internet populace
> are
> powerless to defend against it. We are not saying that the vendor
> should not
> be informed, we are saying, inform the people and the vendor
> simultaneously.

What do you gain by informing the people? Many people running servers
are unable to disallow mail relaying on their boxes, why do you expect
them to understand how to recompile and reinstall a webserver? Even the
few competent admins who could understand an advisory and fix things by
themselves might like an official update from a distributor, packaged
and ready to install.

>> If we are lucky enough
>> that the vulnerability is spotted by a whitehat, we should not
>> jeopardize
>> the time advantage we have by announcing it publically.

> This situation already occurs. If a researcher leaks information to a
> few
> 'allies', if a technique is discovered 'in the wild', or if a vendor
> silently
> fixes unknown problems, then there are those who possess the knowledge
> and
> those that don't. We are simply providing a forum for those who wish to
> try
> and balance out this situation.

If some bug is being exploited "in the wild" there is no sense in
holding back information; I believe the bugtraq moderators understand
that (at least they approved postings stating that something was being
exploited already within a few minutes.

>> In short, I think this is a bad idea because it adds confusion for the
>> vulnerability spotters, risks early disclosure before fixes are
>> available
>> and thus harms the users.

> Early disclosure is important, IMO, as was proved with the recent
> Apache flaw.
> I believe there were reports of Gobbles' exploit being active in the
> wild long
> before the patched packages were available,

Well, I believe this case was a matter of Gobbles' attitude -- they
simply didn't follow the rules by sharing their exploit with other
people before the official release date. There will always be people
like this (=> "instant fame"), and giving them a forum in which they can
publicize their exploits to an even wider audience will not make the
problem go away.

If that happens it is the same thing as with every other exploit being
actively used -- notify everyone instantly, as there is no point in
still holding back information. I believe the bugtraq moderators
understand this, and approve such postings right away.

Simon

Perhaps someone can setup full-disclosure-discuss? I thought this list was
for announcements, not the tired/boring/painfully stale "am not" "are so"
arguments. Plus the anologies will start coming out and those really suck.
And then someone will get compared to Hitler and the thread will be closed,
so why not head it off at the pass instead?


Kurt Seifried, kurt@seifried.org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/


----- Original Message -----
From: "Simon Richter" <Simon.Richter@phobos.fachschaften.tu-muenchen.de>
To: "John Cartwright" <johnc@grok.org.uk>
Cc: <len@netsys.com>; <full-disclosure@lists.netsys.com>
Sent: Thursday, July 11, 2002 2:01 PM
Subject: [Full-Disclosure] Re: Announcing new security mailing list


> Hi,
>
> >> To me, the term "full disclosure" does not mean "make it available as
> >> fast
> >> as possible", but rather "here is the information, expect it to leak in
> >> the next two weeks, so go out and fix the bug". The current bugtraq
> >> scheme
> >> enforces that, and I believe they are doing a great job.
>
> > We are placing the responsibility with the individual, not with an
> > organisation here.
>
> IMHO an organisation has a greater chance of doing things right than a
> number of individuals. For example, I do not have a complete list of
> Linux/BSD/Unix distributors' security contacts, and I believe many
> others out there haven't either, however such a list is vital for vendor
> notification.
>
> > What we do not believe in is having a situation where
> > a select few are aware of a problem, but 99% of the internet populace
> > are
> > powerless to defend against it. We are not saying that the vendor
> > should not
> > be informed, we are saying, inform the people and the vendor
> > simultaneously.
>
> What do you gain by informing the people? Many people running servers
> are unable to disallow mail relaying on their boxes, why do you expect
> them to understand how to recompile and reinstall a webserver? Even the
> few competent admins who could understand an advisory and fix things by
> themselves might like an official update from a distributor, packaged
> and ready to install.
>
> >> If we are lucky enough
> >> that the vulnerability is spotted by a whitehat, we should not
> >> jeopardize
> >> the time advantage we have by announcing it publically.
>
> > This situation already occurs. If a researcher leaks information to a
> > few
> > 'allies', if a technique is discovered 'in the wild', or if a vendor
> > silently
> > fixes unknown problems, then there are those who possess the knowledge
> > and
> > those that don't. We are simply providing a forum for those who wish to
> > try
> > and balance out this situation.
>
> If some bug is being exploited "in the wild" there is no sense in
> holding back information; I believe the bugtraq moderators understand
> that (at least they approved postings stating that something was being
> exploited already within a few minutes.
>
> >> In short, I think this is a bad idea because it adds confusion for the
> >> vulnerability spotters, risks early disclosure before fixes are
> >> available
> >> and thus harms the users.
>
> > Early disclosure is important, IMO, as was proved with the recent
> > Apache flaw.
> > I believe there were reports of Gobbles' exploit being active in the
> > wild long
> > before the patched packages were available,
>
> Well, I believe this case was a matter of Gobbles' attitude -- they
> simply didn't follow the rules by sharing their exploit with other
> people before the official release date. There will always be people
> like this (=> "instant fame"), and giving them a forum in which they can
> publicize their exploits to an even wider audience will not make the
> problem go away.
>
> If that happens it is the same thing as with every other exploit being
> actively used -- notify everyone instantly, as there is no point in
> still holding back information. I believe the bugtraq moderators
> understand this, and approve such postings right away.
>
> Simon
>
> _______________________________________________
> Full-Disclosure mailing list
> Full-Disclosure@lists.netsys.com
> http://lists.netsys.com/mailman/listinfo/full-disclosure
>

Dang! I always liked the Hitler comparisons...

...practically live on analogies...


Thanks,

Ron DuFresne

On Thu, 11 Jul 2002, Kurt Seifried wrote:

> Perhaps someone can setup full-disclosure-discuss? I thought this list was
> for announcements, not the tired/boring/painfully stale "am not" "are so"
> arguments. Plus the anologies will start coming out and those really suck.
> And then someone will get compared to Hitler and the thread will be closed,
> so why not head it off at the pass instead?
>
>
> Kurt Seifried, kurt@seifried.org
> A15B BEE5 B391 B9AD B0EF
> AEB0 AD63 0B4E AD56 E574
> http://seifried.org/security/
>
>
> ----- Original Message -----
> From: "Simon Richter" <Simon.Richter@phobos.fachschaften.tu-muenchen.de>
> To: "John Cartwright" <johnc@grok.org.uk>
> Cc: <len@netsys.com>; <full-disclosure@lists.netsys.com>
> Sent: Thursday, July 11, 2002 2:01 PM
> Subject: [Full-Disclosure] Re: Announcing new security mailing list
>
>
> > Hi,
> >
> > >> To me, the term "full disclosure" does not mean "make it available as
> > >> fast
> > >> as possible", but rather "here is the information, expect it to leak in
> > >> the next two weeks, so go out and fix the bug". The current bugtraq
> > >> scheme
> > >> enforces that, and I believe they are doing a great job.
> >
> > > We are placing the responsibility with the individual, not with an
> > > organisation here.
> >
> > IMHO an organisation has a greater chance of doing things right than a
> > number of individuals. For example, I do not have a complete list of
> > Linux/BSD/Unix distributors' security contacts, and I believe many
> > others out there haven't either, however such a list is vital for vendor
> > notification.
> >
> > > What we do not believe in is having a situation where
> > > a select few are aware of a problem, but 99% of the internet populace
> > > are
> > > powerless to defend against it. We are not saying that the vendor
> > > should not
> > > be informed, we are saying, inform the people and the vendor
> > > simultaneously.
> >
> > What do you gain by informing the people? Many people running servers
> > are unable to disallow mail relaying on their boxes, why do you expect
> > them to understand how to recompile and reinstall a webserver? Even the
> > few competent admins who could understand an advisory and fix things by
> > themselves might like an official update from a distributor, packaged
> > and ready to install.
> >
> > >> If we are lucky enough
> > >> that the vulnerability is spotted by a whitehat, we should not
> > >> jeopardize
> > >> the time advantage we have by announcing it publically.
> >
> > > This situation already occurs. If a researcher leaks information to a
> > > few
> > > 'allies', if a technique is discovered 'in the wild', or if a vendor
> > > silently
> > > fixes unknown problems, then there are those who possess the knowledge
> > > and
> > > those that don't. We are simply providing a forum for those who wish to
> > > try
> > > and balance out this situation.
> >
> > If some bug is being exploited "in the wild" there is no sense in
> > holding back information; I believe the bugtraq moderators understand
> > that (at least they approved postings stating that something was being
> > exploited already within a few minutes.
> >
> > >> In short, I think this is a bad idea because it adds confusion for the
> > >> vulnerability spotters, risks early disclosure before fixes are
> > >> available
> > >> and thus harms the users.
> >
> > > Early disclosure is important, IMO, as was proved with the recent
> > > Apache flaw.
> > > I believe there were reports of Gobbles' exploit being active in the
> > > wild long
> > > before the patched packages were available,
> >
> > Well, I believe this case was a matter of Gobbles' attitude -- they
> > simply didn't follow the rules by sharing their exploit with other
> > people before the official release date. There will always be people
> > like this (=> "instant fame"), and giving them a forum in which they can
> > publicize their exploits to an even wider audience will not make the
> > problem go away.
> >
> > If that happens it is the same thing as with every other exploit being
> > actively used -- notify everyone instantly, as there is no point in
> > still holding back information. I believe the bugtraq moderators
> > understand this, and approve such postings right away.
> >
> > Simon
> >
> > _______________________________________________
> > Full-Disclosure mailing list
> > Full-Disclosure@lists.netsys.com
> > http://lists.netsys.com/mailman/listinfo/full-disclosure
> >
>
> _______________________________________________
> Full-Disclosure mailing list
> Full-Disclosure@lists.netsys.com
> http://lists.netsys.com/mailman/listinfo/full-disclosure
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D. Just don't touch anything.

Matthew S. Hallacy wrote:
> I disagree, I think my DOCSIS vulnerability posting is a good example of
> something that should have gone out immediately, but was /never/ posted.
> ( I ended up taking it to another list)
>
> It was valid, the vendors knew, but it was withheld because you deemed it
> 'malicious'.

"You", meaning who? Not I.. it went to my list:
http://online.securityfocus.com/archive/82/261280

I have my own set of (often harsher) standards for what posts I allow on
vuln-dev... but that has nothing to do with Bugtraq.

I assume you mean Dave, whose reply is here:
http://online.securityfocus.com/archive/82/261454

I suppose you can accuse him of not stating his standards well enough up
front for what kinds of messages he considers fraud instructions.

I might not have approved the original message either. For messages like
that, I'm often torn between my policy of not allowing posts that tell that
a particular site is vulnerable to a hole only they can fix, and allowing
the poster to implicate themself for the poking around they've done. It
kinda depends if I feel like I've been made an accessory. If so, I'll
usually approve it for the world to see. Or, maybe forward to the FBI. I
haven't had occasion to do the latter yet.

The point being, that has nothing to do with the Bugtraq moderator holding
posts so he can warn a vendor to make a fix.

In your case, if I'm reading the headers correctly, there were only about 6
hours between when you sent the note to Bugtraq, and decided it wasn't
going to be posted?

BB

> I suppose
> you can accuse him of not stating his
> standards well enough up
> front for what kinds of messages he considers fraud instructions.

Typically Dave (the Bugtraq moderator) will return the rejected post
with comments as to why it was rejected. I can't speak for Dave or
Security Focus but in my experience I have seen comments come back as to
why a message is being rejected come back from Dave.


> I might not have approved the original message either. For
> messages like
> that, I'm often torn between my policy of not allowing posts
> that tell that
> a particular site is vulnerable to a hole only they can fix,
> and allowing
> the poster to implicate themself for the poking around
> they've done. It
> kinda depends if I feel like I've been made an accessory. If
> so, I'll
> usually approve it for the world to see. Or, maybe forward
> to the FBI. I
> haven't had occasion to do the latter yet.

I think in the case when you have a post that is clearly something
illegal - ie: "I just hacked XXX Corp and here is how" then of course
you aren't going to post it -- you will probably forward it on to the
proper authorities and hope you don't get implicated. But in the case
of the DOCSIS post -- it was nothing illegal so why the questions? Of
course this is just my observation from outside the whole issue.

This reminds me of when I started Win2KSecAdvice - I had some assclown
email me saying that he just "0wn3d Microsoft using RFP's RDS exploit"
which I obviously thought was a false claim and post but I forwarded it
off to the proper people and never let it hit the list.


> In your case, if I'm reading the headers correctly, there
> were only about 6
> hours between when you sent the note to Bugtraq, and decided
> it wasn't
> going to be posted?

Six hours isn't to out of the question as an expectation but what the
poster needs to understand that the larger the mailing list, the longer
it is going to take mail to be processed. Also, there is refference in
Mathew's post about his post not being accepted or rejected by Bugtraq
-- just deleted. Bugtraq runs on the same mailing list software as
VulnWatch and there is no way in only six hours that a poster would know
that his post was simply ignored. The options to a moderator are,
ACCEPT, DENY, or ignore. If you ignore, the message must time out
before the poster is notified that it was not acted upon (and in some
cases this notification is never sent).

I am not saying that I agree with this post not being sent to Bugtraq I
am simply trying to give a moderators perspective on how some of the
common mailing list apps work.

Just my .02$ on a subject that is probably getting beaten to death.

Regards;


Steve Manzuik
Founder & Technical Lead
Entrench Technologies
www.entrenchtech.com

Moderator - VulnWatch
www.vulnwatch.org

-=-=-=-=-=-=-=-=-=-=-=- www.csicon.net -=-=-=-=-=-=-=-=-=-=-=-

On Thu, Jul 11, 2002 at 06:00:25PM -0700, Blue Boar wrote:

> "You", meaning who? Not I.. it went to my list:
> http://online.securityfocus.com/archive/82/261280
>
> I have my own set of (often harsher) standards for what posts I allow on
> vuln-dev... but that has nothing to do with Bugtraq.
>
> I assume you mean Dave, whose reply is here:
> http://online.securityfocus.com/archive/82/261454

Sorry, it was Dave, I kind of see securityfocus as one large group..

>
> I suppose you can accuse him of not stating his standards well enough up
> front for what kinds of messages he considers fraud instructions.

How is it any different from someone writing an exploit and posting it to
the list? I didn't even include any scripts for it, I merely explained
the process (I did have people, such as 3Com (who still claim there is
no problem) say that it was not an issue with their product(s)).

>
> I might not have approved the original message either. For messages like
> that, I'm often torn between my policy of not allowing posts that tell that
> a particular site is vulnerable to a hole only they can fix, and allowing
> the poster to implicate themself for the poking around they've done. It
> kinda depends if I feel like I've been made an accessory. If so, I'll
> usually approve it for the world to see. Or, maybe forward to the FBI. I
> haven't had occasion to do the latter yet.

I didn't view it as illegal, I had been repeatedly informed by AT&T that
any speed limitations were due to hardware limitations, and that I should
feel free to download all the 'tweaks' available online, etc etc. Never
would they admit to having capped the service (I have the emails to/from
the AT&T tech support rep stating this)

>
> The point being, that has nothing to do with the Bugtraq moderator holding
> posts so he can warn a vendor to make a fix.

It's about censoring valid content based on a single persons feelings.

>
> In your case, if I'm reading the headers correctly, there were only about 6
> hours between when you sent the note to Bugtraq, and decided it wasn't
> going to be posted?

Actually I had posted it that Friday, I waited until Monday ~2pm and
re-sent it (thus the 'lets try this again' comment), only at that point
did I recieve a message back from the moderator that he was not going
to allow it through, with no explanation. 6 hours later I posted it to
vuln-dev


> BB

--
Matthew S. Hallacy FUBAR, LART, BOFH Certified
http://www.poptix.net GPG public key 0x01938203

On Thursday, 2002-07-11 at 13:10:29 -0500, Ron DuFresne wrote:
> On Thu, 11 Jul 2002, Marc Slemko wrote:

> > BTW, spewing "[full-disclosure]" into the subject line is a very annoying
> > thing for a list to do.

> Actually, it makes it quite easy for procmail recipies and certain mail
> readers to filter and categorize the messages. What gets annoying is when
> there's a ton of html crap preceeding messages, or those folks spewing
> vactions into the lists. Not to mention those danged content filters that
> are set to prevent folks from being offended by words like damn...

My procmail recipe, which does not use the Subject: line:

:0:
* ^List-Id: .* <full-disclosure.lists.netsys.com>
/home/lupe/Incoming/full-disclosure

I prefer to use List-Id because the list might change the insertion
of the list tag in the SUbject: line, but List-Id: is generated by
the list software which normally changes very infrequently.

Lupe Christoph

PS: Since I file each mailing list in a separate file, I find the
list name tag in the Subject: line redundant.
--
| lupe@lupe-christoph.de | http://www.lupe-christoph.de/ |
| I have challenged the entire ISO-9000 quality assurance team to a |
| Bat-Leth contest on the holodeck. They will not concern us again. |
| http://public.logica.com/~stepneys/joke/klingon.htm |

On Thu, 11 Jul 2002, Steve wrote:

> > I suppose
> > you can accuse him of not stating his
> > standards well enough up
> > front for what kinds of messages he considers fraud instructions.
>
> Typically Dave (the Bugtraq moderator) will return the rejected post
> with comments as to why it was rejected. I can't speak for Dave or
> Security Focus but in my experience I have seen comments come back as to
> why a message is being rejected come back from Dave.
>

With the new mailman SW the poster gets a standard rejection/denied form
e-mail back <ezim is ones friend when avoiding real contact>. It is then
up to the original poster to try and contact the list admin as to the
reason<s> behind the denial of their post. Sometimes, depending upon the
list and list administrator in question they will get something with meat
in the form of a reason back, sometimes they are silently ignored
<smile>. What has been interesting on this end has been the vapid
increase in rejections of postings due to the fact the list
maintainer thought the posting in question would generate "too much"
discussion and they had not the time to deal with the increased posting
flow through their list. We've found this an interesting *rationale*, on
the stifeling side as pertains open discussion and the learning process

[SNIP]


Thanks,


Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D. Just don't touch anything.

also sprach Ron DuFresne <dufresne@winternet.com> [2002.07.11.2010 +0200]:
> > BTW, spewing "[full-disclosure]" into the subject line is a very annoying
> > thing for a list to do.
> >
>
> Actually, it makes it quite easy for procmail recipies and certain mail
> readers to filter and categorize the messages.

there are many other headers one may use. e.g., i use:

* ^List-Id:.*full-disclosure\.lists\.netsys\.com

i do consider [Full-Disclosure] in the subject line rather annoying
because it wastes valuable subject space. good mailing lists have
subject lines that allow the pre-elimination of anything that doesn't
concern one. especially if it's high traffic, this is something more
than necessary. i vote to take the subject prefix off.

it would also be nice to have received headers cut off when the
listprocessor starts its job on such a public mailing list.

--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck

wind catches lily,
scattering petals to the ground.
segmentation fault.

This list is run by mailman. I have made procmail filters for several
list managers, see http://volker.orcon.net.nz/soft/procmail/

Use like:

# file away all mailman passwords
LISTFOLDER=mailmanpass-List
INCLUDERC=$PROCDIR/lm_mailman-member.rc

LISTNAME="full-disclosure"
LISTSERVERDOMAIN="lists.netsys.com"
LISTFOLDER=full-disclosure-List
INCLUDERC=$PROCDIR/lm_mailman.rc

> i do consider [Full-Disclosure] in the subject line rather annoying

Dito, but I don't know whether mailman can do otherwise.

> it would also be nice to have received headers cut off when the
> listprocessor starts its job on such a public mailing list.

ABSOLUTELY. The "full-disclosure" does not refer to all the posters'
details as well, or?

Volker

This is not a disclosure, just another attempt to stop these nonsense flares on this new list. Please delete if you are not interested with my apologies for bothering you.

1) I feel that if you have a problem with stuff like '[Full-disclosure]' being added to the email's topic, that this is your personal problem: deal with it yourself and stop whining to people who really don't care. By subscribing to this list, I assume you have basic knowledge of computer programming: write a small program or script that filters your email and removes this from the subject line. I personally am all in favor of these additions to the subject line.

2) Could everybody who doesn't have any information or disclosure to post, please not post at all ? Just to take a random example, I quote martin f krafft:

--------------------------------------------------------------------------------

also sprach Nomen Nescio <nobody@dizum.com> [2002.07.12.0350 +0200]:
> Bugtraq moderator will not post your message if you are GOBBLES or not liked.

because GOBBLES is ridiculous!

> death to anti.security.ls
> death to project mayhem
> Security Focus wants to be to security what Microsoft is to desktop
> Does not ISS own this title

you apparently have no clue. just shut up, please.

--------------------------------------------------------------------------------

True: If you have no clue, please shut up, that goes for anybody that doesn't have any usefull information to post which includes you martin.
(And because I feel I have to post this message, even though it doesn't include any vulnerability or exploit, me too. Sorry about that folks !)

So, everybody who feels publicly humiliated by this email or who wants to rant on any other non full-disclosure subject: I can be contacted at skylined@edup.tudelft.nl, If you feel I've wronged you: write ME; if you can convince me that you are right, I'll personally apologise on full-disclosure and reinstate your h4x0r status for you ;)

Also, I you agree with me on this subject, please do not post to full-disclosure just to tell everybody you do: nobody cares. I propose that everybody who's subscribed to this list SPAMS anybody who posts another useless flare. I personally intend to.

Berend-Jan Wever aka SkyLined
http://sppor12.edup.tudelft.nl

also sprach V K <list0570@paradise.net.nz> [2002.07.14.0006 +0200]:
> Use like:
>
> # file away all mailman passwords
> LISTFOLDER=mailmanpass-List
> INCLUDERC=$PROCDIR/lm_mailman-member.rc
>
> LISTNAME="full-disclosure"
> LISTSERVERDOMAIN="lists.netsys.com"
> LISTFOLDER=full-disclosure-List
> INCLUDERC=$PROCDIR/lm_mailman.rc

Nice.

> > i do consider [Full-Disclosure] in the subject line rather annoying
>
> Dito, but I don't know whether mailman can do otherwise.

List admin interface -> General options ->
"Prefix for subject line of list postings"

> _______________________________________________
> Full-Disclosure - We believe in it.

Can someone define "believe" please? Is this our mission statement?

--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck

humpty was pushed.

On Sun, Jul 14, 2002 at 02:17:23AM +0200, martin f krafft wrote:
> > _______________________________________________
> > Full-Disclosure - We believe in it.
>
> Can someone define "believe" please? Is this our mission statement?

Following a strong emotion, that can't be backed up by facts?

// Ulf

"Berend-Jan Wever" <SkyLined@edup.tudelft.nl> wrote:

Nothing personal dude, but ...

Coming from someone who posts with:

> X-Mailer: Microsoft Outlook Express 6.00.2600.0000

and is too clueless to even configure it to prevent its obvious and
usual crap such as:

> ------=_NextPart_000_002F_01C22AD2.F27DBAA0
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
<<snip>>

this:

<<snippity, snip>>
> ... I'll personally apologise on full-disclosure and reinstate
> your h4x0r status for you ;)
<<snip>>

is the best laugh on this list yet.


(If you don't understand my point, just disable the entirely
unnecessary bandwidth wasting HTML-ized copy of the messages you
post to this list. And those contemplating posting HTML-only
messages -- just don't do it.)


And yes, I know I'm posting to the list, but unlike most of the rest
so far bitching about the crappy, off-topic posts, thi is on-topic.

When you signed up, you got a confirmation request message. In part,
it said:

... Send questions to full-disclosure-admin@lists.netsys.com.

If you don't like the "[Full-Disclosure]" Subject: prefix, mail the
list admin and ask for it to be changed. If you don't like the
noise-to-signal ratio, mail the list admin. If you fail to get
satisfaction from those approaches, consider unsubscribing as, while
it remains an unmoderated list, some of the things people are so busy
complaining about will remain facts of life.

This is not rocket science but "Mailing lists 101"...



Regards,

Nick FitzGerald

On Sun, 14 Jul 2002 16:41:03 +1200, Nick FitzGerald wrote:
> "Berend-Jan Wever" <SkyLined@edup.tudelft.nl> wrote:
>
> Nothing personal dude, but ...
>
Nonetheless, I felt he raised some valid points, even if I don't
entirely agree with all of them. Simply because this is an
unmoderated list does not mean that normal rules of list etiquette do
not apply.

Among them, as you pointed out, is the one about HTML e-mail.

Having participated in a few flame wars myself, I'd hate to simply say
that it's rude to flame. If we didn't care, we wouldn't get mad.

And security is something to care about.

So I'll say this about flaming instead: When you flame, at least say
something substantial. Simply saying that something sucks really
doesn't cut it. Explain why it sucks, so we at least have something
to argue about.

The posting about the anonymizing web sites is a classic example. He
just said it's broken, with hardly any explanation of why it's broken.
He didn't explain his testing procedure, nor did he explain what
results he's looking for, contrasting them with the ones he actually
got. Finally, he didn't explain how these results undermine their
utility in anonymizing web access.

Next, don't bother with old news. Old news is old news. It's dead.
Just because you can't bury it doesn't mean you should drag the rotten
corpse around and force the rest of us to take a whiff.

The postings about the Bugtraq lists are old news. Those lists have
been around for years. There's nothing new about how they're being
administered so we really don't need to hear your general complaints
about them here.

Notice I said general complaints. If they're doing currently doing
something specifically wrong with a specific issue, that's fair game,
as long as you explain yourself.

Next, keep personal attacks to a minimum. If somebody is being
stupid (as opposed to ill-informed), it's reasonable to whack them
with a clue stick. But remember, we're here to exchange information,
so explain yourself.

Simply saying someone is a stupid dumbfsck is not nearly so impressive
an argument as explaining point by point why everything they said is
simply wrong.

There's an underlying theme here. Explain your position. You might
be right, you might be wrong. Either, really, is okay, because even
when you're wrong, we can show where you're wrong. Or maybe we're
wrong in thinking you're wrong, in which case, you can argue back.

We learn that way.

The idea is that there always needs to be substance. As fellow
humans, we might care about your emotions, but as administrators and
programmers, we need information we can act on. Your anger is not
something we can do a lot about.

My last point on flames would have to do with frequently asked
questions which are documented. Remember that just because you know
where to find the answer to that question doesn't mean I do. And
sometimes I can't figure out what search terms to use to get
reasonable results from Google. Also, some documentation, including a
lot of man pages, seems to presume you already know the answer.

Good technical documentation is hard to come by, partly because most
technical writers are hacks working for marketing departments.
Documentation written by programmers, on the other hand, often suffers
for a variety of reasons.

So RTFM is often not an adequate response -- make allowance for that
possibility.

When flaming, it is important to do it well. Otherwise you may look
like the bigger fool. And if done well, flames still contain valuable
information that can be useful in ferreting out the greater truth
surrounding any particular issue.

And that is why we're here.

--
David Benfell, LCP
benfell@parts-unknown.org
---
Resume available at http://www.parts-unknown.org/resume.html