COMMAND

    NIS+

SYSTEMS AFFECTED

    SunOS 5.5.1, 5.5.1_x86, 5.5, 5.5_x86, 5.4, 5.4_x86, 5.3

PROBLEM

    Bill Paul  came to  following vulnerability.   NIS+ clients  run a
    daemon called  nis_cachemgr which  is designed  to cache directory
    'objects' returned from NIS+ servers. The object is really an  XDR
    encoded     directory_obj     structure     (as     defined     in
    <rpcsvc/nis_object.x>).

    The tricky part  about nis_cachemgr is  that any local  process on
    the  system  is  allowed  to  send  it  requests to cache objects;
    nis_cachemgr  is  basically  just  an  RPC server, with a protocol
    defined in <rpcsvc/nis_cache.x>. Since NIS+ directory lookups are
    performed by library code in libnsl, they might be made by  anyone
    on  the  system;  hence  nis_cachemgr  must  be prepared to accept
    updates from privileged and unprivileged users alike.

    The  cache  (/var/nis/NIS_SHARED_DIRCACHE)  is  later  accessed by
    other   processes:if,   say,   user   'foo'   does   an    'niscat
    passwd.org_dir,' this will  cause the org_dir  object to be  saved
    in  /var/nis/NIS_SHARED_DIRCACHE.   Subsequently,  user  'bar' may
    issue the same command, but  rather than asking the remote  server
    to do a directory lookup  all over again, the client  NIS+ library
    reads the org_dir object from the cache.

    An obvious question is: what  happens if a malicious user  decides
    to  write  his  own  client  program  to  talk to nis_cachemgr and
    instructs  it  to  load  the  cache  with  bogus  objects? How can
    nis_cachemgr tell if the request  is legitimate or if the  user is
    just trying to be a wiseass?

    The answer  is supposed  to be  the 'signature'  contained in  the
    fd_result structure  returned by  the NIS+  server (rpc.nisd). The
    server  is  supposed  to  compute  an  MD5  digest  of the encoded
    directory object and encrypt it (with ecb_crypt()) using a  Secure
    RPC  conversation  key.  This  conversation  key  consists  of the
    server's secret key and the requester's public key.  (You can  get
    it from the keyserv daemon with the key_get_conv() function.)

    Since nis_cachemgr runs as root, its principal name is the same as
    the  'requester'  listed  in  the  finddirectory request, hence it
    will be able to  compute its own signature  and compare it to  the
    one  generated  by  the  server  (using  its  secret  key  and the
    server's public key).  Since only the server knows its RPC  secret
    key,  it  should  be  impossible  for  a user to forge a directory
    object because it can't create a proper signature.

    But here's the problem: rpc.nisd never signs its directory objects
    and  nis_cachemgr  never  checks  for  them.  This was tested with
    Solaris  2.5.1   on  a   couple  of   different  machines.     The
    nis_cachemgr  man  page  states  that  it  will  always attempt to
    authenticate the signature  unless you start  it with the  -i flag
    (to activate  insecure mode).  Test was  not started  nis_cachemgr
    with the -i flag, so  it should have been checking  for signatures
    and if rpc.nisd wasn't sending  them, it would never have  updated
    the cache.

    The insecureMode  flag in  nis_cachemgr starts  off initialized to
    0  but  is  forced  to  1   later  in  the  program  even   though
    nis_cachemgr  was  _NOT_   started  with  -i.   In  other   words,
    nis_cachemgr doesn't  really check  for signatures  at all,  which
    bore out my hunch that rpc.nisd was never sending them.

SOLUTION

    The  vulnerability   does  not   exist  in   Solaris  2.6.     The
    vulnerability in nis_cachemgr is fixed by the following patches:

    OS version          Patch ID
    __________          ________
    SunOS 5.5.1         103612-33
    SunOS 5.5.1_x86     103613-32
    SunOS 5.5           103187-29
    SunOS 5.5_x86       103188-29
    SunOS 5.4           101973-32
    SunOS 5.4_x86       101974-32
    SunOS 5.3           101318-89       (to be released)