Newsgroups: alt.security
From: fitz@mml0.meche.rpi.edu (Brian Fitzgerald)
Subject: SUMMARY(pt 1/2): DO NOT depend on YP to hide passwd.adjunct
Message-ID: <7=ap=sb@rpi.edu>
Organization: Rensselaer Polytechnic Institute, Troy NY
Date: 14 Oct 91 19:17:31 GMT

In July I wrote:
>Why can I do this from my machine?

># ypmatch -d notmydomain someguy passwd.adjunct.byname
>someguy:nOtHiSrEaL.kY:::::

>I was under the impression that the adjunct passwd file was supposed to
>be "hidden" to prevent such an occurrence.

(Significance: Any root user on the local broadcast network can read
the encrypted passwords in any passwd.adjunct YP map, thus defeating
the main purpose of a shadow password file.)

Peter Lamb, of Switzerland, showed me that the shadow password map
exposure extends beyond the local network, and demonstrated directly to
me how it is possible for a root user anywhere on the internet to
obtain these encrypted strings from the passwd.adjunct map using remote
procedure calls in a locally written C program.

I am told that Sun originally intended to fix the bug by 5/17/90.  This
did not happen, but Sun recommends as a workaround:

---------------
This is a configuration issue until NIS 3.0 comes out. Configuration is
this:
1) do not run the YP server on your Internet gateway

2) do not do IP routing from your Internetgateway to the rest of your
machines.
This is simple to do in 4.1.1 Reference system and networking
administration
manual  page 704-705: ...
------

Comment:  I believe that (1) is "standard", but (2) is out of the
question for individual departments within a large organization.
Wouldn't doing that break just about every network program (rlogin,
telnet, ftp)?  Followup comments welcome.

Neither suggestion really gets to the root of the problem.  To say "do
not do IP routing ..." inappropriately shifts the burden for shadow
password security from the host to the gateway.  Additionally, it is
not possible or desirable for an individual sysadmin on a network
shared by many systems with varying network requirements and interests
to decide something like this.

Peter Lamb added some helpful ideas, the first of which, is admittedly
"security through obscurity":

- use a hard-to-guess domain name.  The C program mentioned above
relied on a domain name guessing routine.

- if you have Sun sources, patch ypserv yourself to accept only
requests from specific machines.  Otherwise, obtain a patched binary
>From somebody that has already done this.

Hope I've covered the essence of what workarounds have been suggested
so far.  Feel free to elaborate in a followup, or to post information
about how to obtain fixes for Sun OS 4.1.1 and earlier.

A few weeks ago somebody asked whether a Cisco router could help the YP
situation.  Here's what RFC-1244 has to say:

3.9.5.2  Router Packet Filtering

         Many commercially available gateway systems (more correctly
         called routers) provide the ability to filter packets based not
         only on sources or destinations, but also on source-destination
         combinations.  This mechanism can be used to deny access to a
         specific host, network, or subnet from any other host, network,
         or subnet.

         Gateway systems from some vendors (e.g., cisco Systems) support
         an even more complex scheme, allowing finer control over source
         and destination addresses.  Via the use of address masks, one
         can deny access to all but one host on a particular network.
         The cisco Systems also allow packet screening based on IP
         protocol type and TCP or UDP port numbers [14].

         This can also be circumvented by "source routing" packets
         destined for the "secret" network.  Source routed packets may
         be filtered out by gateways, but this may restrict other
         legitimate activities, such as diagnosing routing problems.

  [14] Mogul, J., "Simple and Flexible Datagram Access Controls for
       UNIX-based Gateways", Digital Western Research Laboratory
       Research Report 89/4, March 1989.

Hope this bit of information helps.  Pose additional questions about
routers to the newsgroup or the specific vendor.

Solely for brevity, I have not repeated most of the technical details
about the security hole, but these were covered recently in articles by
Peter Lamb, Jyrki Kuoppala, Adam Glass and others.  Thanks.

In conclusion, although Sun has not supplied a patch to OS 4.x which
closes this security hole, it has recommended some workarounds.

Brian

Disclaimer: I do not work for ITS or ECS.  These are my opinions.