From: brossard@sic.epfl.ch (Alain Brossard EPFL-SIC/SII) Newsgroups: alt.sys.sun,alt.security Subject: ypserv, unsecure Message-ID: <2196@sicsun.epfl.ch> Date: 19 Dec 91 12:02:21 GMT In a prior message on alt.security, there was mention of a vulnerability of ypserv. Since enough people now know about this security hole, I guess it is time to post a solution! I won't go into the details of exactly what this hole his, but it is fairly trivial to get any NIS maps as long as you can be root on the internet. Since this NIS map can be the password file... One way to improve the situation is to use a random NIS domain name for your domain, this will make it that much harder to get your maps, another solution is to cut all RPC packets >From coming in your domain. In article , prl@iis.ethz.ch (Peter Lamb) writes: |> 2) The Lamb Party Line. If you communicate to the outside world through a |> smart router, filter out packets coming from external connections |> addressed to destination ports sunrpc/udp&tcp (port 111) and ports |> 600-1023, tcp&udp. This will prevent access to *all* sunrpc services |> from outside the router. It will also block access to the Kerberos |> protocols (probably also not a bad idea given the info. in Steve |> Bellovin's paper about Kerberos security problems), and will |> probably block the BSD `r' (rcp,rlogin, etc) commands, but don't |> count on it doing so. If you and your router are smart enough, you |> may be able to make the `r' commands work. Eg, for rlogin, allow |> the packets through iff their source is 513/tcp (this opens up a hole |> for a sufficiently clever cracker, though). Blocking port 111 alone |> is insufficient but will block the most obvious attacks (including |> those I've been told have already actually occurred). |> A better solution which solves the problem with ypserv and ypxfrd has been developed in cooperation with quite a few people. It also solves the following two problems: 1- There was still the problem that a DNS in bad hands could spoof anybody (Sun's fix to BSD bind for this still had one hole, BSD's bind is highly vulnerable) (The fix for this came from Tho Deraadt) 2- The annoying erroneous warning nres_gethostbyaddr: ... != ... has been fixed (this was suggested by Vince Giambalvo) and Tho Deraadt provided the impetus. Once again due to copyright restrictions, sources are not available. However for those who want the source patches, send me the last 3 lines of ypserv.c and I'll e-mail them ... as long as it's in before Thursday night local time :-). For those who want to rebuild their libc.so, I have included gethostnamadr.o which has been fixed (see 3- above). For my local managers, I also included the full libc.so which is why the main patch is big (800KBytes+). My libc.so included uses the DNS directly which is why it needed to be patched. If you use DNS via the ypserver, it has been patched already, no need for the libc.so. The patch is available, for now, on litsun.epfl.ch in the directory pub. Since the cost of transfering my local patch with the libc's might be too high across continents, I also made a second file without the libc's. I've been told that I shouldn't use litsun in the future, so the patches won't stay there too long... -rw-r--r-- 1 brossard 819190 Dec 17 14:15 nis.patch-01.tar.Z -rw-r--r-- 1 root 117771 Dec 17 15:05 nis.patch.no.libc-01.tar.Z litsun# sum *.Z 11058 800 nis.patch-01.tar.Z 36615 116 nis.patch.no.libc-01.tar.Z To use the new ypserv, read the included man page on ypserv and hosts.nis. Thanks to all who contributed, you know who you are. Alain PS: I've had request for patches for other vendors, since we don't have any sources I can't provide them. But we do have HP and SG's machines so I would be glad to be a central repository for binaries/ patches for other vendors. -- Alain Brossard, Ecole Polytechnique Federale de Lausanne, SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse, +41 21 693-2211 brossard@sic.epfl.ch