Re: Multiple firewalls ruleset bypass through FTP. Again. (CERT VU#328867)

["R. DuFresne" <dufresne () sysinfo com>]

On Tue, 8 Oct 2002, Paul D. Robertson wrote:

> On Tue, 8 Oct 2002, R. DuFresne wrote:
>
> > On Tue, 8 Oct 2002, Paul D. Robertson wrote:
> [snip]
>
> > In a better world I think many researchers would take a stance as Mikael,
> > or be willing to adopt the RFP policy in disclosure <it looks to have
> > been updated to a newer version recently?>.  Exploits prior to
> > warning/patches are certainly not a good thing<TM>.  Yet, one has too look
>
> They're worse than "not a good thing," they're mostly _very_bad_things.
> They turn innocent 3rd parties into victims.  If you're creating victims, 
> you're part of the problem.  Rarely do we see anyone espousing "full 
> disclosure" coding up patches, fixes, or anything other than attacks.

I've noticed change in this area.  Though not all researchers have bought
into the current state, and the bugtraq/security focus/symatec shift in
it's interpretation of 'full disclosure with at least a modicum of
responsibility', many of the more serious researchers are trying to work
with vendors prior to information release, and their advisories have been
following a degree of outlined compliance in such information being
included as vendor contact dates, vendors response <when available>, a CVE
variety of risk level of the potential vulnerability, as well as some
patches for open source coded products <the DCMA again here limits what
patches folks are willing to attempt to closed source code>, and work
arounds when patches are not included <though admittedly, these are
sometimes very strict and will make some systems/services unusable until a
fix from the vendors is released, and this is not entirely a bad
thing<TM>>.  I think we all have to admit there has been a change in focus
in more recent times, and those refusing to adapt are perhaps widening the
lines between  researchers, hackers, and 'cracker' hat crowds.[1: see
below]


> > at vendors outside those that only produce security products on which
> > their reputations hinge in looking at the full disclosure issue.  I know
> > it's been tackled here and elsewhere alot, and quite a bit recently in
> > various formats.  But, when a major OS/hardware vendor threatens to use
> > the DCMA to go after a security consulting/research site for disclosing
> > issues they <the major vendor> have held under their belts for years, if
> > not months, then we have a totally different situation then that was faced
>
> Well, part of that is how you approach the vendor[1], and part of it has 
> to do with the fact that DMCA is a *Bad Law*.  If you're not supporting 
> the current legislation to modify DMCA, you're part of the problem.  This 
> particular case took months- some of that was directly my fault.  Because 
> there wasn't a magic clock ticking, we were able to coordinate fixes, 
> testing, discussion... while taking time to get it right, ensure 
> everyone was included, etc.

[1]  And art of it is the vast amounts of code people use that is not
longer maintained, as well as the issues that a couple of folks at
mitre.org outlined two years ago:

<quote>
Title: An informal analysis of vendor acknowledgement of vulnerabilities
Authors: Steve Christey (coley () mitre org)
         Barbara Pease (bjp () mitre org)
Date: March 11, 2001

        [SNIP]

In anticipation of the Guardent/eWeek vulnerability summit in early
November 2000, we conducted an informal experiment in which we tried
to obtain the following information:

1) Whether the vendor publicly showed awareness of an announced
   vulnerability, and admitted that the problem was real ("vendor
   acknowledgement," also referred to as confirmation).

2) Whether the vendor provided contact information for security
   problems.


        [SNIP]

Basic Conclusions
-----------------

1) Without a standard location for security vulnerability information
   on vendor web sites, it is often extremely difficult to even find
   the appropriate page where vulnerability and patch information
   might be discussed.

2) Without a standard contact name for asking questions about
   vulnerabilities, it is difficult for a security analyst to find out
   which individuals or groups at a vendor web site have the
   information needed.  This problem also makes it difficult for the
   vulnerability researcher to reach the right people.

3) The customer-focused nature of vendor web sites often makes it
   difficult for security analysts to access vulnerability
   information, even if the site has that information.  Security
   analysts normally are not the vendor's customers.

4) Frequently, there is no apparent public acknowledgement of the
   vulnerability, or the web site is too difficult to navigate.

5) In some cases, the vendor may or may not have acknowledged the
   vulnerability, but the vendor's information is too vague to be
   certain.

6) When the researcher's original report did not include detailed
   vendor and product information (such as URLs and version numbers),
   it made it more difficult for the security analyst to find the
   proper vendor web page to examine for acknowledgement.

</quote>

These remain real world issue to date.  Much less so in the security
products available, but, are still issues researchers have to wade through
in dealing with issues they discover.  The security focus lists are ripe
with requests from people asking others for input for points of contact in
some attempts to be more responsible in disclosure mechanics they are
involved in.  Thus, while, and let me reiterate, I'm not promoting blanket
"full disclosure" and certainly not promoting the open release of sploits
for each and every 0day found, I can understand the degrees of frustration
others feel in trying to adapt to a more responsible disclosure policy.

As for 'bad laws' we all know that getting a law reversed once it's become
something of real relevance to the legal beagle crowd is alot tougher then
trying to rid a home of roaches.


> > here.  It seems folks that produce security products and code might well
> > understand the consequences of not acknowledging potential risks to their
> > name and ventures when exploitable issues are found with their offerings,
> > and are willing to work with researchers in addressing those issues then
> > some of the larger vendors in the OS/hardware realms often are.  Getting
>
> I think this is for the most part not true.  I see quite a bit of stuff 
> that goes to OS vendors outside of public mailing lists, and I have yet to 
> see anything that hasn't gotten addressed eventually.  I'm not saying that 
> there aren't cases where vendors haven't fixed things, I'm just saying 
> they're rare in the space of software I've seen reports for, even outside 
> of the security product community.

Agreed, this is getting better, there are still crack in the system such
as the recent vendors espousing the DCMA legislation to threaten a group
of researchers as mentioned before.


> > vendors to work with researchers in such instances would be a grand
> > thing<TM> as opposed to reckless threats of legal retribution after they
> > have been advised of the issues by the researcher<s> who discovered the
>
> How many threats of legal retribution have there been versus attempts at 
> extortion or threats at compromise?  While I'm certainly not a vendor 
> spokesperson (I tend to prefer Open Source solutions myself) there are two 
> sides to each and every coin.  One side is getting a bunch of attention 
> these days, and the other side isn't.  "You have 14 days to explain to me 
> how you're going to fix this and to produce a fix or I'll unleash the 
> world against your customers" isn't productive to positive dialog.

The responsible disclosures policies I've seen, including the couple that
have been up and down for RFC consideration as well as RFP's revisions put
forth more a premise that the researcher be kept in the informational
loop.  And I don't see that as a bad thing<TM> at all.  Keeping the
researcher in the loop was the responsible thing ICSA labs did ere with
Mikeal.  And of course, I'll put forth that the researcher also has to
keep themselves in the loop here, to work with the vendors in trying to
mitigate the issue to resolution.  Which includes sharing all their
information collected on the issue and if they have developed a working
sploit, to provide it to the vendor to help them understand the degree of
the problem they <the vendor> are trying to resolve.  The point I make
her, is that it's a two way street.  Vendors needs to make themselves
available to researchers finding issues with their code and appliances, and
the researchers needs to also make themselves available to the vendors.
And if the vendors would give the researchers credit when they then
together with or without orgs like CERT, release the information to the
public, give the researchers their hard earned credit for that
cyber-slap-on-the-back, and something to stuff in a resume to sweeten
their glamour to hiring reps, we'd perhaps see far less of the
irresponsible disclosure that has permeated the industry over the years.

> > issues.  While times have changed in this realm with a number of vendors,
> > it has well been slow work with some in the industry.  Afterall, bugtraq
> > was founded with good reason, no mater their shifts of disclosure policies
> > as they have been grown and been acquired in the recent economic
>
> Yes, let's look at Bugtraq- care to guess how many companies have been 
> "saved" versus how many exploited victims there are for the history of the 
> list back when it was more open?  I know where my bet would go.

Yes, and been bitten here too in this regard.  I recall a number of years
back seeing an exploit released that affected linux systems tcp/ip stacks
at about 3am central time <we were Midwestern back then, not of the
'eastern' persuasion>.  Saved the sploit and patch info, and decided it
was far too early to worry about and slipped off to get some sleep.  Wake
at 6am to the sounds of some of my systems bouncing up and down, due to
the sploit already being perpetrated upon the Internet community.  We
went into fast fix mode and in less then 15 Minutes had the local systems
fixed, then flew out the door to take care of the production systems at
work.  This was my bad, I had the information and decided I had some
leeway time to mitigate the issue on my end, when in fact I hadn't.

Yet, I do recall in years past, on the eves of large holidays like x-mas
whence sploits were pushed one after another into the public streams like
bugtraq in irresponsible manners often resulting in no well deserved time
off for those responsible in their work.  This is indeed not in compliance
with responsibility in any sense of the term, you'll get no argument from
me.

> > understimulas.  I certainly feel that many researchers would take a more
> > reasonable approach to disclosure issues if they did not find vendors
> > constantly ignoring matters that have been disclosed to them with their
> > offerings, and when sitting for periods doing nothing to fix the issue,
> > then making threats to sue or otherwise damage the researchers for finally
> > disclosing the problems for others to mitigate on their own or pressure
> > their offending vendors to deal with the problems with their products.
>
> Part of it has to do with how it's approached, and part of it certainly 
> has to do with the market.  In our case, we have NDAs with all the 
> vendors, so working with them all at once without worrying about someone 
> trying to gain a competative advantage for a short time is relatively 
> easy.  
>
> > Do not get me wrong here, I'm not a proponent of 0day code being released
> > hither and tither, but, I'm also wary of not knowing what my adversaries
> > might know, and feel that if at least one or more researchers know, as
> > well as the vendor, there are great chances that others might well know
> > what I've not had time to find on my own.  I know many here, as I myself
> > have observed, changes in disclosure policies of various researchers and
> > mailing lists over the years.  And I've seen alot of information hit those
>
> But let's look at my favorite posterchild of full disclosure, RDS.  RDS 
> was fixed by MS- yet it was the #1 attack vector for IIS servers for 
> years after it was fixed (RFP's exploit came out after the shipping at 
> the time version of IIS didn't have the problem.)  People who'd already 
> upgraded their servers OR configured them conservatively weren't 
> vulnerable.  Producing the exploit didn't "force MS to fix the problem" 
> it created victims.

The same might be made for the cases of Nimda and the code reds, or even
the M$sql worms still wrecking havoc on bandwidth and systems though.
Part of the responsibility here lies again with the vendors making sure
their customers know the issues at hand and how to correct them, and
finally with the customers and admins of those sploitable systems still in
service, long after fixes have been available.  we are even seeing the
results of slacking administration, be they home users or those in public
venues in a production realm, on opensource, folks are not patching their
ssl aware apache systems from the recent worm variants slithering through
the wires as I write.  Granted the code writers have a large part of
responsibility to take for releasing such into the public domain, but, the
edge of the responsible sword cuts back at those with unpatched systems
months and years after patches and fixes have been widely available.


> > venues of information sharing without the older tendency to *require* a
> > 0day sploit to prove the point of the information disclosure.  Granted
> > there is not total compliance in this, there's alot of mistrust and lack of
> > patience and cooperation still permeating the IT world at large.  Afterall
> > the little guys all know the bigger fish are out to get em.  And we
>
> First, do no harm.

Cool, we have our own hypocratic<SP?> oath! <grin>  and perhaps it should be
forced to be sworn to in the various security certification schemas out
there!

Agreed, and makes the point that if my cohorts in the industry have
systems infested with viri and worm code, that is affecting the bandwidth
of my clients to connect to my production systems, or filling my logs with
malicious attempts of exploit, I'm more apt though to vent my frustration
at and end of the means, towards their irresponsible policies of not
dealing with the issues at hand.  I'm going to get more results this way
then some search for the writers or the malicious code or venting at the
person that disclosed the issue that propagated this worm at this point.

I hope I have made the points I intended, that responsibility is not
a finger one points at all others without first cleaning the glass in ones
own house.  Responsibility, like security, is an issue that everyone has
to do their part in, vendors, researchers, and ends users/admins.

Thanks,

Ron DuFresne
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior security consultant:  sysinfo.com
                        http://sysinfo.com

"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!





_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards