From: CSBVAX::CSBVAX::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 12-NOV-1988 21:23 To: MRGATE::"ARISIA::EVERHART" Subj: RE: Viruses and VMS - TWG fingerd claims of immunity are exagerated Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Sat, 12 NOV 88 10:49:23 PDT Received: from Venus.YCC.Yale.Edu by KL.SRI.COM with TCP; Sat, 12 Nov 88 10:28:36 PST Date: Sat, 12 Nov 88 13:25 EST From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: RE: Viruses and VMS - TWG fingerd claims of immunity are exagerated To: jerry@TWG.COM, ajt@mace.cc.purdue.edu, INFO-VAX@KL.SRI.COM X-VMS-To: IN%"jerry@TWG.COM",IN%"ajt@mace.cc.purdue.edu",INFOVAX [Jerry Scott writes:] Andrew Thomas mentions that the Wollongong VMS product has the bug in fingerd. I strongly disagree. The bug in fingerd was caused in part because the BSD finger server "execs" /usr/ucb/finger. Through the ability to overrun the stack, a user was able to overwrite the exec of /usr/ucb/finger with an exec of /bin/sh. The Wollongong finger server is self-contained. It performs no exec. Since /bin/sh is not part of a standard VMS system, even the ability to overwrite the stack in this way would have had no effect. Also, before outputting any data the privileges of the process are reduced to TMPMBX and NETMBX. Someone may be able to overrun the stack in Wollongong's fingerd, but it will do them no good. This is an excellent explanation of why the exact attack that has been used against BSD fingerd's will not work against TWG's. However, THAT MISSES THE POINT. What you have to prevent is the NEXT attack, not the last one. We have thought about some security issues in this area before. We have disabled the functionality in fingerd that allowed remote sites to "finger" a given individual. We felt that this feature helped malicious remote users determine various accounts on a machine to target for break-in. Yes, the fingerd will except an argument, but will then ignore it. Typical of TWG's approach, I'm afraid: Eliminate useful functionality because it might somehow be abused.* However, don't bother to fix the underlying problem. Thanks, Andrew, for checking into the possible security holes of the product (even though Wollongong didn't hear from you directly on your assumptions), but in this case you are dead wrong. Sorry, Jerry, but YOU are the one who is dead wrong, or at least your expla- nation is. If TWG's finger demon can indeed be caused to overwrite the stack with input data, whether because it uses gets() into a local (stack) variable or for any other reason, then a sufficiently clever programmer can take over the process running the demon and do whatever he likes. Period. Whether the process has privileges, whether it does any exec's - all are irrelevant - though it's obviously much worse if the process has privileges. (I won't go into any details here; the clever hackers can figure it out for themselves whatever I do, and I see no reason to help out the less talented.) FIX THE DAMNED UNDERLYING BUG!!!!! There is NO excuse for gets() to be used in ANY program provided to the general computing community. It is an accident waiting to happen. (If it's not a gets() that is causing the stack trashing, it's something else equally stupid.) Consider yourself put on notice. If someone DOES break in through such a hole, and sues TWG for negligence in not removing a clear hazard, I will be glad to testify that I warned you - and that fixing things would have been quick, cheap and easy. (Just remove gets() from your library - as has apparently been done on the in-house research Unix systems at AT&T - and rebuild your software. Anything that won't rebuild shouldn't be going out the door. Then use fgets() calls with the correct buffer size.) -- The Original Jerry * Damned if I know what ..."this feature helped malicious remote users determine various accounts on a machine to target for break-in" is supposed to mean: finger for ALL users on the system lets you determine a list of valid account names. If finger for a particular user is thought to return too much information about that user, the obvious fix is to remove the sensitive information from the single-user display, rather than turning the whole thing off. One useful feature of finger is that you can tell if someone is logged on. Having to read through the list of 200 people logged on to an 8800 isn't helpful. The other example of this bizarre approach to security is the FTP server's inability to read from anything but its login directory - not even from subdirectories of the login directory.