Re: OSX remote root *more info*

[ghandi <ghandi () dopesquad net>]

I researched this a while back and found that it had mostly been addressed
years ago in NeXTSTEP.  The vulnerability arises when network (non-local)
NetInfo domains are created without setting trusted_networks properly.
This is analogous to YP/NIS domains not using the 'securenets' file.
The problem and how to set trusted_networks are detailed in the CIAC and
CERT advisories from around 1991-92.

http://www.ciac.org/ciac/bulletins/c-13.shtml
http://www.cert.org/advisories/CA-1992-01.html

NetInfo is an RPC service and is similar in basic architecture to YP/NIS
(although it adds multi-level hierarchy, etc).  To register with a binding
("bind to a domain" in NIS terminology), a client calls NIBIND_REGISTER on
the node serving the binding.  The client passes in the tag (ala NIS
domainname) and the server returns the TCP and UDP ports on which the
binding is served.  The netinfobind protocol is described in
/usr/include/nibind_prot.x.  'netinfobind' (served by nibindd) is
registered with the portmapper, the netinfo instances (served by netinfod)
serving different bindings are not (this is why their port numbers are
returned by netinfobind).

After registering with the binding, the client may contact the specific
netinfo instance to perform lookups via the netinfo protocol (NI_READ,
NI_LOOKUP, etc).  The netinfo protocol is described in
/usr/include/netinfo/ni_prot.x.  This is where the password maps may be
read, etc.

Because UDP RPC requests are easily spoofable, the netinfo daemons throw
away any UDP requests for lookups, updates, etc.  IIRC, NI_PING may be the
only procedure available over UDP RPC.  I do not know when this was
secured, but it was at least before NeXTSTEP 3.3.

On MacOS X 10.0.x, there is a default netinfo domain 'local' for local
machine configuration.  Although the portmapper, netinfobind, and netinfo
RPC services are available, only TCP RPC requests from 127.0.0.1 are
allowed for the meaningful procedures (lookup, etc).  Under MacOS X 10.1,
there has been a definite move towards fewer listening ports and a tighter
NetInfo configuration.  Out of the box, portmap and nibindd are not
running, and netinfod is only accessible by local TCP RPC requests.

Under both 10.0.x and 10.1, if you create a network NetInfo domain without
configuring trusted_networks, it will be accessible to the world
(including all your ciphertext passwords, etc).  If the tools to create a
network domain do not make you set trusted_networks (or choose not to set
it), I believe that to be the vulnerability.

So, it is not a remote root hole unless the administrator of the machine
sets up a network domain, leaves trusted_networks unconfigured, has
crackable passwords for any admin users, and has SSH ("Remote Login")
enabled.

-ghandi

On Wed, 17 Oct 2001 dotslash () snosoft com wrote:

> did a little more research ... it appears nidump makes a query to
> portmap to look for netinfobind if either of these are not listening
> the use of a remote tag with nidump or nireport may fail. A vulnerable
> machine should have the following open.
>      program vers proto   port
>      100000    2   tcp    111  portmapper
>      100000    2   udp    111  portmapper
>      200100001    1   udp    796  netinfobind
>      200100001    1   tcp    799  netinfobind
>
> -KF

--
           ghandi / ghandi () mindless com / www.dopesquad.net
       "Bein' Crazy is the least of my worries." - Jack Kerouac
          C439 2B06 D8D2 A2D8 1ABB  0A55 A61D 9057 63F5 9B1F