sendmail/ftpd security-holes raise their ugly heads again...

[John Chambers]

Here I am again, with a minor ethical question to fan the flames
a bit, and also a practical question.

The readers of this group probably all have fond memories of the
events last winter concerning the security holes involving sendmail's
debug command and ftpd's quote command.  Much has been written on
the subject, and it seems that rtm is being prosecuted.  So.

A couple weeks back, while doing some testing of other software on
a commercial workstation which I will carefully refrain from naming, 
I decided just for the fun of it to test for these problems.  Sure
enough, they seemed to be there.  It seems that not all vendors have
heard the news, or they don't consider it their problem to plug the
holes.

First, the ethical question.  Should I tell anyone?  (Well, OK, I'm
tell y'all right now; that's not what I mean.)  We know from much
experience that most vendors have a history of not welcoming this
information.  The sendmail problem in particular was well documented
for years before someone (rtm) gave us a demo, and nobody listened
very carefully.  Then when someone gave the demo, rather than thanking
him for it, the world calls for prosecution.  So the obvious conclusion
is that I should be very quiet about it.

Am I right?  If not, why not?

Second, the technical question.  I didn't actually do anything to the
systems in question that actually violated their security.  For example,
I just tested for the existence of sendmail's debug command.  It has
been pointed out that this in itself is not really a security hole, it
is just a symptom.  Disabling the debug command (by using adb to replace
the 'D' with a null, for instance) plugs the hole.  But the real problem
was that there was some way to use this feature to get a remote shell
running with root permissions.  It is entirely possible that some clever
vendor has supplied a sendmail with a debug command, but which won't let
you start up a remote shell.  UUCP does this sort of thing quite well, 
and there's no reason that sendmail couldn't do it, too (other than the
usual NIH syndrome :-).

So it occurs to me that another reason I don't want to openly point an
accusing finger at this vendor is that they might not actually have this
bug.  Not having access to sendmail source, I don't quite know how to
determine the answer.  Can someone explain exactly how to tell whether
a given sendmail daemon has this particular problem?

Before someone posts the obvious flame, I will point out that, yes, I
do know what I'm asking for.  I'm asking that someone tell me (or even
better, post it; it's been nearly a year) exactly how to exploit this
particular pair of security holes.  All the things I've seen published
on the subject have carefully avoided saying just how to do it, with
the usual argument that they don't want to tell everyone how to break
into others' machines.  After this much time, this has become somewhat
of a specious argument.  The industry has had more than six months to  
fix the problems.

What I'd like to do (and what I think is the ethically correct path)
is to test this workstation (and others in the future) quietly, and 
if they fail the test, send in a bug report explaining to the support 
people what is wrong.  But to do that, I have to be able to document 
the problem exactly.  It's not good enough to say "I think you have
a problem."  I want to be able to fill in the part of the form that
says how to elicit the problem.  If I can't show them how to get the
remote su shell, I haven't documented the bug.

It'd also help if I could email them a set of patches, and not have to 
worry about violating someone's licenses.  This is not a trivial point.
I've already had several cases of reporting Sys/V bugs, and received the
response that they can't be fixed, because to do so would make the system
fail the SVID test suite, and the ATT license doesn't allow that.  

It seems to me that there should be a reasonable time, and 6 months seems
reasonable to me, after which problems like these should be posted and
archived, and handed out to all interested parties.  Otherwise, as with
the sendmail and ftpd holes (and the ancient vi problem), they'll keep
coming back to haunt us.

Is this all a hopeless dream, or are we stuck with knowing there are problems
but that if we're smart, we'll keep quiet about them?

-- 
#echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:'
echo '	John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)'
echo ''
saying