jc@minya.UUCP (John Chambers) (09/27/89)
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 ''
sayingchris@mimsy.UUCP (Chris Torek) (09/28/89)
In article <21@minya.UUCP> jc@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@mimsy.umd.edu Path: uunet!mimsy!chris
truesdel@sun217..nas.nasa.gov (David A. Truesdel) (09/28/89)
It should be noted that the mere presense of the debug mode IS NOT a security hole, the ability to address mail to an arbitrary shell (with the aid of "debug") IS. Before ragging on your unnamed vendor, you should check to see if the security hole really is present. -dave truesdell (truesdel@prandtl.nas.nasa.gov) "When in doubt, use brute force."
schwartz@psuvax1.cs.psu.edu (Scott Schwartz) (09/28/89)
In article <19837@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
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.
I don't understand. Isn't it the case that 90% of the hackers in
the universe have already heard about this bug? I mean, what exactly
are we keeping secret?
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. . . .
Last year Weemba-from-Berkeley loudly proclaimed that in a years time
everyone would be back to sleep on this issue. Guess what, looks like
he was right. I'm pretty well convinced that silence is futile.
--
Scott Schwartz <schwartz@shire.cs.psu.edu>
for h in `cat /etc/hosts`; do telnet $h smtp; done;
Now back to our regularly scheduled programming....pvo3366@sapphire.OCE.ORST.EDU (Paul O'Neill) (09/28/89)
In article <21@minya.UUCP> jc@minya.UUCP (John Chambers) writes: > >First, the ethical question. Should I tell anyone? ......... >..............................................We know from much >experience that most vendors have a history of not welcoming this >information. > ................... >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? > Of course tell someone -- the vendor. What "much experience"? Pure folklore. What follows is a true story and a picture-perfect example of how security holes should be handled. Can you say "mail to a pipe"? I thought so. Can you say "mail to a pipe without ``debug''"? Ah ha, choked on that one, didn't ya'? While working on a mail problem on a Sun 386i I discovered a bug in Sun's sendmail that allowed just this. Debug was turned off, yet mail to a pipe was possible. I told Sun about it. They figured out a fix *that night*. They had a tape with the fix on it at the next Berkeley Sun Local Users Group (SLUG) meeting within a week. They had the fix available for anonymous ftp on uunet.uu.net within a month. [Have you installed those things from ~ftp/sun-fixes yet? They're there for a reason, you know.] So -- now that the vendor has been told, the fix has been propogated and everyone has had time to install it, it's time to tell the security mailing list about it. To summarize: 1) tell the vendor 2) wait 3) tell the [resonably secure] world Discussion? Paul O'Neill pvo@oce.orst.edu Coastal Imaging Lab OSU--Oceanography Corvallis, OR 97331 503-754-3251
jc@minya.UUCP (John Chambers) (10/11/89)
> So -- now that the vendor has been told, the fix has been propogated and > everyone has had time to install it, it's time to tell the security > mailing list about it. Security mailing list? What security mailing list? I keep hearing rumors about such a thing, but when I inquire, I'm told that they won't even tell how to contact it, because I might be a malicious hacker intent on taking advantage of such vital knowledge. I suspect that this is a cover for the fact that there isn't a real security mailing list. I was in fact reinforced in this belief a couple of years back, when I did get on a security mailing list for a while. What a letdown. I didn't read a single article that told me something I didn't already know. At least half of the postings were concerning problems with setuid, from people who clearly didn't understand the difference between setuid and setuid-root. Is there a real security mailing list, that won't waste my time with such silliness, and will actually teach me something? Can I get on it? Even if I no longer have a job that requires a security clearance? -- #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
news@cpd.com (usenet news administrator) (10/23/89)
In article <32@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >Security mailing list? What security mailing list? I keep hearing rumors >about such a thing, but when I inquire, I'm told that they won't even tell >how to contact it, because I might be a malicious hacker intent on taking >advantage of such vital knowledge. I suspect that this is a cover for the >fact that there isn't a real security mailing list. Perhaps you should gain some experiance in using netnews before throwing ridiculous accusations around. I run the security list, as you can easily find out by reading news.lists, where Gene Spafford posts a list of publicly accessable mailing lists every month or so. Also, it seems that you haven't been reading this group very religously, since I end up posting a response about the security list here every 3 or 4 months. In fact, looking at the log of postings here, the latest response went out October 9. Who wouldn't tell you how to contact me? If it's your system administrator that feels you would be dangerous to include on the list, then I certainly won't allow you to join. >I was in fact reinforced in this belief a couple of years back, when I did >get on a security mailing list for a while. What a letdown. I didn't read >a single article that told me something I didn't already know. At least >half of the postings were concerning problems with setuid, from people who >clearly didn't understand the difference between setuid and setuid-root. There was a previous security list run by Andrew Burt on the system isis in Colorado, which became defunct a few years ago. I started the security list back up again about a year ago. I believe it has material of worth, but it is intended more as a system administrators security information source, than as a security theory discussion forum. This news group and misc.security seem to have some good discussions, but I wouldn't know, since I don't have the time to read netnews very often these days. I won't waste everyone's bandwidth putting out the entire security list blurb, but here are a few pertinant lines from it: The unix security mailing list exists for these reasons: 1. To notify system administrators and other appropriate people of serious security dangers BEFORE they become common knowledge. 2. Provide security enhancement information. Most unix security mailing list material has been explanations of, and fixes for, specific security "holes". >Is there a real security mailing list, that won't waste my time with such >silliness, and will actually teach me something? Can I get on it? Even >if I no longer have a job that requires a security clearance? You might be able to get on it, assuming 2 things happen: 1. A system administrator of a reasonably sized educational system or of a well-known commercial organization requests it, or you convince me that you have a good "need to know". This list is not for the "just curious". 2. I clear out the backlog of 637 security-request letters So send a request to security-request here and I'll get to it sometime this decade 8-). Actually, the new product development that has been occupying a ridiculous amount of my time will be done in a few weeks, and I'll be able to spend a bit more time than the perfunctory couple of hours a week that I have been spending on the security list. So please be patient, all you people whose mail has been stuck in my security mailbox. Neil Gorsuch INTERNET: neil@cpd.com president UUCP: uunet!zardoz!neil Uninet MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705 peripherals division of PHONE: +1 714 546 1100 Custom Product Design, Inc. FAX: +1 714 546 3726 AKA: root, security-request, uuasc-request, postmaster, usenet, news