That's what I thought. I have no idea why Legato continues to use portmapper
at all. They've been telling me they're going to stop using it since at
least 1999.
I actually came up with a workaround that I think might expose a potential
issue in rpcinfo.
Since I couldn't get nsrexecd to automatically register with the portmapper,
I tried to register it manually using rpcinfo -s. An entry was added, but it
made the protocol number 2 instead of tcp (6), which is what I need.
# rpcinfo -s 390113 1 7937
# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
390113 1 2 7937
# rpcinfo -t localhost 390113
rpcinfo: RPC: Program not registered
program 390113 is not available
I looked and couldn't find any way to set the protocol to TCP (6). Looking
at the source for rpcinfo, I found the following:
if ((pmap_set(prog_num, version_num, PF_INET,
(u_short)port_num)) == 0) {
fprintf(stderr, "rpcinfo: Could not set registration "
"for prog %s version %s port %s\n",
argv[0], argv[1], argv[2]);
exit(1);
}
Seems like rpcinfo will always set the protocol to the constant PF_INET,
which is actually AF_INET, which is actually 2.
In order to work around this, I created the following short program:
#include <rpc/rpc.h>
main()
{
pmap_set(390113, 1, 6, 7937);
}
Notice the 6 in the 3rd argument to pmap_set, rather than the constant
PF_INET (2).
After deleting the previous portmapper entry and running my little kludge, I
get the following:
# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
390113 1 tcp 7937
# rpcinfo -t localhost 390113
program 390113 version 1 ready and waiting
Which brings me to ask: Should an additional argument be added to rpcinfo -s
to specify a protocol, rather than forcing the constant PF_INET?
-----Original Message-----
From: Theo de Raadt [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 22, 2005 1:02 PM
To: Michael Favinsky
Cc: '[email protected]'
Subject: Re: Portmap non-local set / unset attempt
> I'm receiving the following messages from portmap when starting Legato
> Networker's nsrexecd. The nsrexecd I'm running is the Linux version
> under
> emulation:
>
> portmap[16083]: non-local unset attempt (might be from 127.0.0.1)
> portmap[16083]: non-local set attempt (might be from 127.0.0.1)
>
> The program (number 390113) does not successfully register with the
> portmapper:
>
> # rpcinfo -p localhost
> program vers proto port
> 100000 2 tcp 111 portmapper
> 100000 2 udp 111 portmapper
>
> Is this a security "feature?"
Yes, most definately.
Changes made years ago slightly changed the communications API between
libc/rpc and the portmap daemon, to make it much harder to generate spoofed
RPC mappings. An attacker would make such mappings point one RPC service at
another RPC service, and with the right forwarding games you can get
mis-interpretation by an end point reulting in some risks.
Therefore our portmap sets up special 127.0.0.1 local bound sockets, and
only accepts set/unset operations on those sockets. The *:111 sockets can
still be used to make other requests, but not deal with binding
establishment.
The program you are using is linked against a RPC library that is using your
external address to change the mappings, ie. perhaps your external IP
address. That is the old legacy way that the Sun code used to do it, and it
was a bug, and it is full of risk.
It's astounding that other people have not fixed this yet, considering that
I did the work on that nearly 10 years ago.
revision 1.3
date: 1996/06/29 19:03:50; author: deraadt; state: Exp; lines: +135 -64
multiple receivers, port checking. testing help from bitblt
People keep yammering this bullshit about "Security is a process".
Bullshit! Lies! It's about paying attention to the frigging details when
they are right in front of your face. And it is very clear other vendors do
not pay attention to the details, considering the work I did here was talked
about all over BUGTRAQ back in that month. No wonder these vendors and
their blogboys have to have this "Security is a process" mantra to protect
themselves from looking bad.
> Is there a way to get nrsexecd to register with the portmapper?
You cannot get a Linux binary to talk to our portmap, without modifying our
portmap code to not have this security check. And that would be a shame.
Sorry...
This message may contain information that is privileged, confidential and
exempt from disclosure under applicable law. If you are not the intended
recipient of this message you may not store, disclose, copy, forward,
distribute or use this message or its contents for any purpose. If you have
received this communication in error, please notify us immediately by return
e-mail and delete the original message and any attachments from your e-mail
system. Thank you.
