[247] in bugtraq

home help back first fref pref prev next nref lref last post

Full vs. Partial Dsiclosure

daemon@ATHENA.MIT.EDU (Nathan Lawson)
Tue Nov 29 01:44:49 1994

From: nlawson@statler.csc.calpoly.edu (Nathan Lawson)
To: spaf@cs.purdue.edu (Gene Spafford)
Date: Mon, 28 Nov 1994 20:30:52 -0800 (PST)
Cc: bugtraq@fc.net
In-Reply-To:  

> My key concern is that people on the net, and on these lists in
> particular, spout opinion as proven fact.  This perpetuates folklore,
> just as knocking on wood or avoiding black cats.  We have no general
> evidence to prove in any real way that full disclosre helps/hurts more
> people than it hurts/helps.  We have no evidence that full disclosure
> hastens/delays release of a fix.  And we have no evidence that the
> majority of "black hats" know and use all of these flaws before they
> are publicly announced (although there is some partial evidence to the
> countrary). 

The reason that this debate keeps coming up lies in its nature.  Some admins 
that argue against full disclosure have never experienced a breakin done by
a serious cracker who uses little-known bugs to exploit his/her system.  I
think that most of us should agree that there is a definite stratification
in the exposure to privileged security information.  For instance, a member
of CERT gets a lot more bugs cc'd to them than the wanna-be AOL cracker.
This is the way it will always be in a free-enterprise society.  Information
begs to be hoarded and traded to those who have other information.  Full-
disclosure or not, the Scott Chasins and Gene Spaffords of the world will
always have the knowlege of at least one more bug than the average ".edu"
sysadmin.  They are the ones who depend on their manufacturer for the bug fix
promptly because they lack the ability and/or desire to patch it themselves.

Thus, the one who discovers a bug must ask themselves what "layer" they wish
to cater to.  Do I send it to CERT, and let them take their time?  Do I send
it to bugtraq and have it get to some admins and approximately half the
crackers?  Or do I keep it secret and fix it on my site and maybe tell one
or two admin friends?  These are questions everyone has to ask themselves.

From my experience, on most systems I have been on, a release like 8lgm's
latest few -- "There is a bug in at(1), fix it" -- will allow a few crackers
and the aforementioned group of admins to write exploits and/or fix it.
That level of release does not allow many people to figure out how to fix it
in a small amount of time.  For myself, if I spent a week or so looking over
the closest PD source I could find, and trace(1)ing the binary, I probably 
could find a fix.  Do I have the time to do so?  That is another question
everyone must decide for themselves.

The second level has a crippled exploit, such as the nfsbug program.  These
do nothing but report problems.  They make it much easier to tell if you have
a hole, but don't do much about letting you fix it.  Still, they allow a few
more admins, and a few more crackers exploit it.  It takes a little less
intelligence to modify something like nfsbug to exploit a file handle, but
I would say a good amount of admins and crackers can do so.

The lowest level is best typified by the 8lgm releases of last year.  A full
exploit runnable by the dumbest Unix user and an explicit fix, "type this:",
make this the most barbaric of the releases.  In this case, the amount of
time to fix and exploit it are both reduced.  Now it becomes a race to see
who can read comp.security.unix first (an admin I know had the passwdrace
hole fixed within 3 minutes of the news post hitting our server).

So, after looking at all the types of disclosure, I look at them from a typical
admin's view.  The rodents who use an exploit outright make up about 75% of
the crackers and average person will see.  These are the ones who get caught
easily by doing a "ps uaxww | egrep 'rsh localhost|root' or looking on console
for messages like "SU: juser".  Full disclosure allows these people to make
your life hell because they have no idea what they are doing.  On the other
hand, if you get the fix first, then you have won.  From my view, it's always
a toss of the dice who gets the release first.  I don't like gambling for my
system, so this is not a good thing for me.

A large hint at a hole "binmail relies on tempfiles that are created unsafely"
allows the average admin the best chance of fixing the hole before the
average cracker gets to it.  As long as a specific fix is noted, this is the
best way.  Unfortunately, this scenario is not very common.

What usually happens is a subtle threat is released --"install procmail because
the Sun patch leaves other holes open" -- and an exploit script circles around
the most "3l337" admins and crackers; the mentality is the same.  I know this
is a fact because I have talked with several admins and crackers that had the
8lgm tmpfile/lockfile exploit script that they are refusing to post.  The gripe
I have with this is that those same people are the ones advocating 
no-disclosure.  How did they get it?  They relied on someone else to provide
them with it, hence "partial disclosure".

My plea to all you "elites" out there:  have some pity on all the lamerz, and
throw a tidbit their way every once in a while (said sarcastically).  No, the
best way is to get the fix out as fast as possible, leaving the exploit as
long as possible.  In fact, don't write an exploit (said hypocritically).
Posting an exploit does nothing except rush people who don't want to be rushed.
If it serves your purpose to upset the status quo, do something really daring
and give your elite nfo to comp.security.unix, instead of cc'ing it to CERT
and Spaf.

> If we are going to improve the way we handle security, we have to
> start by examining what we really know and not what we have
> experienced locally. 

Every person that read this should look at the level of cracker they have 
seen and determine which level of release is most right for you.  Then,
cast your vote (not on this list please :-] ) with your manufacturer or 8lgm
or whoever you think it will matter.  That's the best way I believe to decide
the right approach for you.  As for me, I don't foresee anyone making any
big changes, but that's up to them to decide.  I see a future much like the
present, where the "elites" keep the best bugs (kernel and the like), but 
very few average admins experience a breakin because of it.  What you can
expect to see is a lot of lame attempts, along with a few surprisingly smarter
ones, but don't expect a breakin from some "name brand" hacker with his
kernel bug exploit scripts.  He'll be targetting the big name admins' machines
and succeeding half the time.

Don't sweat it too much.  Just deal with the crackers on your level and watch
what goes on at the lower and higher levels.  Don't worry about some big hacker
coming down to your level to hack your machine, but take some time to help
out the lamer admins you see struggling with the lamer hackers.  They'll
thank you for it.

Thanks for reading this rambling missive (maybe!),
Nate



home help back first fref pref prev next nref lref last post