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

Chris Torek chris at mimsy.UUCP
Thu Sep 28 03:18:54 AEST 1989


In article <21 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:
>...  The sendmail problem in particular was well documented
>for years before someone (rtm) gave us a demo, and nobody listened
>very carefully.

This is false.  The sendmail problem was NEVER (not ever, not once)
reported to Berkeley.  Several well-known `usenet personalties' have
asked those who asserted that the bug was `well known' whether they
knew it, and why they thought it was well known; every time the answer
has been the `a friend of a friend told me it was well known' sort.

>... Can someone explain exactly how to tell whether
>a given sendmail daemon has this particular problem?
>... The industry has had more than six months to fix the problems.

I am tempted to avoid flames by not saying anything at all, but I agree
with the assertion (perhaps implicit, I forget whether it was in the
text I deleted) that vendors should have fixed it by now.  I know,
though, that some have not, and so I am not going to post the trick
right now.

There is a simple way to fix it, though: get sendmail version 5.61 from
Berkeley---it is available via anonymous FTP from ucbarpa.berkeley.edu
(looks like it is in `4.3/sendmail.tar.Z') and probably also via uucp
from uunet (those with uunet UUCP service can ask uunet: this is what
you are paying for).  Throw out your vendor's version of sendmail (and
ftpd and rlogind and rdist and login and some others) and install the
latest from Berkeley.  Better yet, beat on your vendor to do it for you
(this is what you are paying for!).

>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.

There is a bootstrap problem here: until there is pressure to fix things,
things will not get fixed; until things get fixed, there is pressure not
to disclose the bugs. . . .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris



More information about the Comp.unix.wizards mailing list