[234] in bugtraq
Re: [8lgm]-Advisory-14.UNIX.SCO-prwarn.12-Nov-1994
daemon@ATHENA.MIT.EDU (Pat Myrto)
Mon Nov 28 18:41:45 1994
From: rwing!pat@ole.cdac.com (Pat Myrto)
To: bugtraq@fc.net
Date: Mon, 28 Nov 94 8:45:29 PST
In-Reply-To: <199411280720.CAA01328@uther.cs.purdue.edu>; from "Gene Spafford" at Nov 28, 94 2:20 am
"In the previous message, Gene Spafford said..."
>
>
> > I think that the biggest pro of full disclosure, is that it get's people
> > off their butts and gets a good solution or patch that much faster.
>
> I have yet to see evidence of this. Based on my conversations with personnel
> at various computer companies, the only thing full disclosure seems to do is
> (sometimes) encourage them to release bug fixes without quite as much testing.
> This sometimes leads to patches that don't completely fix the problem. That
> is not a "good solution."
>
> If anyone can provide me with verifiable evidence that full disclosure results
> in faster production of patches of good quality, I would be very interested in
> seeing it. Otherwise, it's just wishful thinking.
This has been beat to death, and the consensus was very apparant.
Obviously we have a group of people who think They Know Best(tm) and
have taken measures to *ignore* the consensus and ensure this sharing of
info does NOT happen for personal or egotistical reasons. Pretending
the consensus does not favor free flow does not make it so. Spaf, you
have been very helpful in the past, and only one funky/out-of-line thing
I can think of is attributed to you, but this is not one of those helpful
times. Lets see some verifiable evidence that your obscurity postion is
such a Great Thing. Anyway, here we go again:
Yes, this could be called a flame, delete and go to next message now if
you don't care about this isue.
------------------------
The DENIAL of crucial security related information is what needs verifiable
justification - not the free flow. At least in a free society (or is
it only free when it fits a personal agenda?) Hell, you Obscurity folks
won't even share it with admins at NIC registered sites (you sure as
hell have not with me), so protection of sites (other than those run by
folks in the 'inner circle') is not the prime motive, as I see it, rather
one has to suspect, at least in some cases, the obscurity game is one
of stroking egos. And "patches of good quality" is a subjective thing
- if it closes the hole, or even makes it harder to exploit than before,
its "good quality", EVEN IF IT DOES NOT COME FROM THE VENDOR, cuz its
better than NOTHING or being fed a bunch of patronizing platitudes.
One failed patch does not justify trashing the whole system - thats like
banning the sale of gasoline cuz an arsonist used it, or banning pickup
trucks cuz one manufacturer didn't do his gas tank layout very well
(well, mebbie in the eyes of those who think government should be a wet
nurse it might).
So, how about YOU or the security thru obscurity crowd providing
*verifiable* evidence that security through obscurity makes the net
safer and all our sites more secure and safe in not only the short, but
long term? Show us how the idea of limiting the information to a 'chosen
few' at CERT, Purdue, and now apparantly 8lgm, who will invariably sit
on it indefinitely (and of course, the crackers who by definition have
the info, since they usually are the ones that make the holes painfully
apparant), making sure the user.population is as dependent as possible
on the favors and good graces of the elite, is going to have all these
wonderful results (other than for the chosen few, of course)? I have
not seen such evidence, nor has anybody else that I know of. I have only
seen assertions that obscurity is a Good Thing because someone SAYS so.
The sitting on of information *might* be viable IFF the information were
eventually released. Experience shows it almost NEVER is (again CERT
is a case in point), instead we are supposed to depend on 'blind faith'
patches, and get paternalistic 'We Know Best What is Good For You'
responses from the likes of CERT, Zardoz, etc when the 'blind faith'
patch does not do so well and the site is nailed anyway. Assuming the
patch is ever made, instead of the usual "We'll fix it in the next
release, sometime next year...", of course.
As to a verifiable incident (and a super-glaring one at that), I can
recall the u-struct bug in SysVr3, where any process could write to the
ruid, rgid, euid, egid elements, and become root? I recaall that bug
was known for at LEAST a couple of YEARS, and was not acted upon until
full disclosure forced the issue. It doesn't take a rocket scientist
to figure out there were other holes not quite so blatent that were
never fixed. How long has the V7 bin/mail been around? How long has
the BSD mail system been around? What about rdist? What about arp?
What about /bin/passwd? What about comsat? What about finger? What
about LD_LIBRARY_PATH or LD_PRELOAD? Ad nauseum. Are we to believe
these are ALL only RECENT holes? I betcha the holes affecting these
and other parts of the system have been known to 'inner circles' for
ages, some for years at least, and have only become known to the 'common
folk' THROUGH the full disclosure you wish to curtail and are only NOW
being fixed because of that disclosure. Till then, people could only
scratch heads and do full restores after a breach that most folks would
not have any idea how they were accomplished (and get paternalistic
platitudes from the likes of CERT and others favoring obscurity). Most
folks cannot even INSPECT for possible holes, not with source code so
prohibitively priced, even for source to stuff highly probable to be
subject to holes (all stuff running as root via SUID or stuff that
controls entry into the site). But once a hole and attack is KNOWN,
one can work to port BSD source to their OS and at least be empowered
to TRY to do somehting about it. And it usually works, since there are
usually many talented folks also working on the same problem. This
cannot happen with your approach, Spafford.
And those holes that wern't known, but only recently discovered, are we to
believe the continued blissful ignoance of the hole is beieficial?!
The crackers are not so charitable. They will happily exploit a hole
while all the nay-sayers pontificate and spew platitudes.
Now, granted, Sun is more proactive in chasing down holes and getting
SOMETHING out than most, but some (too many) vendors will deny such a
thing as a bug exists in THEIR code until their face gets rubbed in it.
And that scares me when I have to use another vendor or a different OS
that has not been hammered on as thoroughly as SunOS. We all know there
are cracker types that have nothing better to do than try to find holes,
and there are some that do manage to get source to aid their endavors.
Full disclosure is one of the things that levels the field a bit. All
the resons I can come up with for not supporting discosure are not very
nice.
If a workaround exists (turning off SUID bits, turning off the serivece
in question if possible), there is no reason on earth for this obscurity
game, save for some egos and power/turf trips. Things like urestore,
suid_exec, and such are NOT critical services (and suid_exec is hardly
new, either). Most of that stuff is mainly convenience, and the holes
have been around for some time, but forcing a person to blindly turn
them ALL off or be vulnerable is unreasonable.
What is the excuse for the obscurity game regarding suid_exec? Don't
tell me that its a brand new hole, I ain't buying - I heard of it (CERT
style tell you nothing reference) years ago. Still dunno how to TEST
how it works, thanks to the paternalistic crowd (I disable it anyway,
as I don't like the idea of SUID scripts).
Something like mail, a needed service, MIGHT warrant a more careful
disclosure procedure, to ensure a fix of some kind (like mail_local.c
that has been fixed up and posted) is easily availalble, IFF no workaround
exists (like populating the mail spool with mailboxes and not deleting
them, especially system accounts). But what I hear is the policcy of
NEVER disclosing all the details, instead forcing the hapless site
operators to be totally dependent on the 'privileged few' or on a 'blind
faith' black box. Somehow I suspect you, Spafford, would not go for
that idea for one second if you were not one of the few who is privy to
the full details. Playing the "I got a secret and you don't" game only
ensures that site operators are unable to verify the status of their
sites, or check a fix they devise, often using publically available
sources. Or even verify if a 'blind faith' patch really works as
advertised. And what is wrong with full disclosure, at least enough
info so one can test his site, if a fix is included, and also has preceeded
it by, say, a week?
The /bin/mail bug is a case in point of bugs that would still be there
had they not been well-disclosed. Ditto the rdist hole.
An advisory that says "A vulnerability exists in foo", OS Type <some
vague generallity or reference to all versions here> not only denies
operators the info needed to make AND POST a fix, even if its specific
for their platform, but it also denies the ability of the user community
to determine WHAT os's and versions are actually affected (does it affect
MY site?). Such advisories are almost a taunt.
Are we to believe this 8lgm bunch has the means to test all the platforms
out there themselves? Somehow, I doubt it when their list of OS types
in their now useless-as-CERT advisories is as vague as it is. Unless one
has been nailed, asking the vendor is going to get a "No, its not a problem",
or "we dunno".
I wonder who 'got to them'? I wonder if it was the same person who
tried to shut down an anonymous mailer in Finland? And what was offered
in return for them playing the cloak-and-dagger game? Or did some
net.personalities who felt they might be losing their lock on the
information threaten them somehow? Like using influence to get their
feeds cut off or some such thing? Or did 8lgm get included in the
'inner crowd' on condition they no longer inform the user community?
That thought makes me nervous, as the 8lgm bunch's previous background
was not so sterling as I understand it.
Spaf, you aint lived till you get nailed and are met with a stonewall
of self-righteous and paternalistic folks denying you information that
could have either PREVENTED the breakin or minimized its impact. I
suspect if you have had to endure that frustration, your position would
be considerably different. The net.equivilant of "take 2 aspirin and
call again tomorrow" (set good perms, do lots of backups and pray) just
does not cut it. When someone cracks root, good perms mean diddly-squat.
And good backups do not restore the work lost since the last backup,
nor do they restore the lost time in cleaning up the mess, not to mention
the resultant denial of service. All it takes is some bozo to 'cat
/dev/zero >/dev/rsd0c' or do a 'yes >/dev/rsd0c' to ruin your whole day.
Perms or restrictive mounts (like readonly, nosuid) don't help here.
The sites that don't get the word don't get it due to their own choosing,
not because someone is playing God and denying the info: Assuming they
are connected to the net (which is the main exposure of risk), there is
nothing preventing them from watching the security newsgroups or lacking
news, subscribing to the mailing lists. Net.access is not needed for
the latter - only an e-mail feed.
The idea that the bulk of the net.population should be denied useful info
regarding problems so they are able to see if their site is affected is
reprehensable. If I went by the info in all those posts that don't even
give a good idea as to WHAT is affected, one would have to disconnect their
sites to cover all the listed problems.
8lgm was a breath of fresh air until SOMEONE got to them. I think they
or someone who knows should inform the community as to who got to them,
and how. I don't expect this to be revealed, because I suspect it is
in the form of a threat of some kind - loss of feed, SOMETHING.
I do know one thing: When myself and co-workers find time to go over
a new OS and platform we are getting trying to find vulnerablilities
and close them, with the current state of affairs, CERT, the Zardos
crowd, and now 8lgm will be the LAST people informed. Our procedure
will be to first notify the vendor, post a partial (warning level)
description suggesting a workaround or fix if possible, then followed
a week later by sufficient info to verify the problem on one;s own site.
Folks like CERT, 8lgm, et al will get their info like everyone else.
I see no reason to make an effort to send information to a black hole.
The only way I would sit on info is if someone supplied it to me, and
made witholding it a condition. Given the current state of affairs,
(the push to tell nobody nuthin') the chance of that happening is virtually
zero.
All this makes me think of the elitist "Trust Us - We Know Best" mentality
I have noticed is so prevalant in the Clinton Administration and their
supporters. Ranging from banning this, banning that, controlling this,
controlling that, denial of information to the public, granting Big Brother
snoop powers to agencies, the whole nine yards. Its the MINDSET.
> --spaf
--
pat@rwing [If all fails, try: rwing!pat@eskimo.com] Pat Myrto - Seattle WA
"No one has the right to destroy another person's belief by demanding
empirical evidence." -- Ann Landers, nationally syndicated advice columnist
and Director at Handgun Control Inc.
