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 dotslashat_private 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 / ghandiat_private / www.dopesquad.net "Bein' Crazy is the least of my worries." - Jack Kerouac C439 2B06 D8D2 A2D8 1ABB 0A55 A61D 9057 63F5 9B1F
This archive was generated by hypermail 2b30 : Sat Oct 20 2001 - 08:12:55 PDT