Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!bloom-beacon!spdcc!ima!minya!jc From: jc@minya.UUCP (John Chambers) Newsgroups: comp.unix.wizards Subject: sendmail/ftpd security-holes raise their ugly heads again... Message-ID: <21@minya.UUCP> Date: 26 Sep 89 21:03:49 GMT Organization: home Lines: 84 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