Hi,
I will focus on the second part of Dylan's post.
Dylan Loomis wrote:
> Question: at one of the sites I work at, we run NIS and NIS+ and I found that
> even though NIS and NIS+ servers use a high ephemeral port, upon reboot this
> port didn't change in some of the machines.
To recall a precedent post I did on bugtraq :
>in libc-5.3.12 code, we can see that the xid of an rpc message is not
>totally random :
>
>Mithrandir:/tmp/libsrc/libc/rpc# grep call_msg.rm_xid clnt* -n
>clnt_tcp.c:207: call_msg.rm_xid = getpid() ^ now.tv_sec ^ now.tv_usec;
>clnt_udp.c:176: call_msg.rm_xid = getpid() ^ now.tv_sec ^ now.tv_usec;
Theo de Raadt answer to that was :
> Yes, a second problem. This problem was also fixed almost two years
> ago in OpenBSD; and I've also told many people about it in the past
> (hi Oliver!) I think that an attack on this was very possible against
> /etc/rc-started services which have a known pid (of course in OpenBSD
> pid numbers are now random too). For instance, on a typically
> compiled SunOS box... ypbind is almost always around pid 666...
^-----------------------------------------^
I suppose that SunOS uses random pid numbers too for a long time.. but,
the point is to know since which version.
> In effect this means that I can write scripts to connect directly to the port
> and by-pass the portmapper. Why is this bad? Well because a lot of sites
> just block 111 (portmapper) and leave the rest open (ftp other stuff might
> need them).
Indeed, this is a thing which is not totally understood by everybody
(admins usually block port 111 and think that they are secure against
RPC attacks [rpc.mountd overflow for ex]). The portmapper pmap_getport()
returns the port number on which a rpc program is listening but it
doesn't prevent the attacker from directly connecting to this port.
Thus, even without asking the portmapper its pmap_list, an evil person
may remotely retrieve your whole pmap_list (by scanning low ports
[512-1024] and higher ports). As a very poor illustration, it's like if
an evil person knocks on the main entrance of your house [if this
entrance is a double secured door and contains a big lock then this
would represent a _really secure portmapper_] to ask you which of your
door/window you let opened. Indeed, nothing prevents this guy from
directly going behind your house and entering by the backdoor [in
comparison to rpc.rexd running on a higher port for example]. Security
talking, it's important to note that filtering port 111 has to be done
anyway as well as blocking higher ports superior to 32770 because (as
already explained on bugtraq) some old versions of rpcbind listens on a
port above this one.
> In addition, since it doesn't run from inetd, I am pretty sure
> you can't run tcpwrappers.
Yes, RPC programs don't rely on it because they aren't fired up by inetd
so you can't use a tcpwrapper (as you already pointed out). They are
independent of inetd.
> Since it bypasses the portmapper, a secure portmapper isn't much good either. So if I > can guess the high port, I can, in the case of NIS, get the hashed passwds quite easily.
Well, a secure portmapper won't fix this problem but it will protect you
anyway from a lot of well-known and old attacks (for example, a
pmap_proxy() call bypass nfsd/mountd protections so that it's possible
to steal the nfs handle of a directory). Actually, I don't know any new
portmapper which is vulnerable to this proxy() attack.
> Workarounds include checking what ephem port your server runs, and blocking it
> at the firewall. Just cutting off your NIS/NIS+ server from the outside world.
I really think it's not a good solution because these ports may change
on SunOS systems.. Roy Hooper points out to use /var/yp/securenets in
order to use a secure distributed name service (as stated in
www.sunworld.com/sunworldonline/common/security-faq.html) but this won't
allow an attacker to use other RPC unsecure programs such as rpc.rexd,
rpc.pcnfsd or rpc.uuid (etc) to break into your server. Thus, I do
believe that the best solution is to use the securelib library and link
the RPC programs against it (it supports an access list to allow only
registered hosts to connect to any RPC programs). However, as I don't
know the exact address of the securelib library, I am not able to give
it right now (do a ftp search and grab the latest version). Note that
this securelib won't prevent buffer overflow attacks (rpc.mountd &&
rpc.statd overflows for example) because an attacker may still spoof the
RPC packets (if AUTH_UNIX is used instead of AUTH_DES). I never used
securelib before but I definitively think that blocking the "common"
well-known rpc attacks is the best answer against crackers (I may be
wrong on this point though).
ga
ps : I'd also like to say that when I posted the message about
pmap_set/pmap_unset spoofing, I forgot to clearly explain that it was a
known and old attack (as Theo de Raadt pointed out). However, still some
OSes seem to be vulnerable to this attack so I tought that it was wise
to talk about this again. I should say that OpenBSD is the main leader
about security on unix but other unix systems don't follow the same path
so releasing working exploits helps to get a patch (well, sometimes...).
pouet.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:29:01 PDT