Security Attack Penetration

From Linux NFS

This document summarizes a study of the "Attack and Penetration" risks within NFSv4. A list of tasks is given, with priorities.

Priority (Very High, High, Medium, Low, Future) of each item is based on: a) the level of expected risk, and b) the expected probability of finding problems.

Bull plans to work on the following:

In end 2005:
  1) d) Search for dangerous functions, in NFS, RPC, TI-RPC, gss, idmap.
  2) a) Search for Memory Overflows in user-land code with DUMA
  2) b) Search for Memory Overflows in kernel-land code (kdb, print)
In 1H2006:
  3) Modify Client side for attacking Server

Contents 1 1) Analyze the source code 2 2) Run dynamic tests 3 3) Modify Client side for attacking Server 4 4) Modify Server-side for attacking Client

1) Analyze the source code

H  a) In NFSv4, RPC, TI-RPC, IPv6
      - Aurélien will focus on TI-RPC analysis
      - Chuck should be the right person to do the IPv6 review

   b) On server and client sides

   c) In user and kernel lands.

Comment from Bruce Fields:

 We were asked to suggest a few places to start looking. In the server
 kernel code, the data received from the client goes into rqstp->rq_res,
 so we're particularly interested in what happens to data taken from
 there.  The server does the first simple parsing of the rpc header in
 net/sunrpc/svc.c:svc_process(), which then it calls svc_authenticate,
 which does further parsing of the rpc headers.  Then it calls
 vs_dispatch to process the request body.  In our case vs_dispatch is
 fs/nfsd/svc.c:nfsd_dispatch(), and the function it will usually call
 to parse an NFSv4 request is
       fs/nfsd/nfs4xdr.c:nfs4svc_decode_compoundargs().
 In the process of doing the decoding, various bits of information
 (filenames, usernames, etc.) will be preserved for later use by
 fs/nfsd/nfs4proc.c:nfsd4_proc_compound(), and it will be useful to
 examine carefully how that information is treated.

H  d) Search for dangerous functions
         - User-land: strcpy, ...
         - Kernel-land: memset, memcopy, ..

     A candidate list (from some paper about improving security):
       gets scanf sprintf strcat strcpy mktemp system vsprintf
     Also, when appearing in a loop:
       getc fgetc getchar

       Focus on data coming from the userland (memcopy ...).
       In general, the length is passed on.
       So memory overrun problems should not appear

Comment from Bruce Fields:

 strcpy seems relatively rare in the kernel sources. (I just
       checked and only found one use in fs/nfsd, 4 in fs/nfs,
       and 4 in net/sunrpc.
 memcpy is more common, and it may also be worth searching for, and
       making sure the length passed to it is always verified in
       some way.

VH e) Search for fixed-sized arrays filled with dynamic-sized data
         - buffer-overflow
         - Kernel: page overflow
       Pages: the system dynamicaly allocates 4k buffers
       Problems of memory corruption have the highest priority.

H  f) Check that lengths are always passed when passing data
            from user-land to kernel-land.

H  g) Search for possibly (too) large names of files
         - Check symbolic links (paths)
       Example of string that can be sources of problems: symlinks.

M  h) Search for problems related to ACLs (more than 35 rules ?)
         - Why this 35 limit ?
         - In user-land on client-side, check the client cannot
              corrupt ACL data.
       We have to make sure that the ACL supplies have good format, so
               verify that we do not have any corrupted data.

Comment from Bruce Fields:

       Trond has pointed out that attribute parsing in general is
       pretty complicated in NFSv4, so getattr, setattr, verify,
       nverify, etc., may be worth a careful look.

F  i) Search for problems related to Named Attributes
         - large or/and numerous Named Attributes

M  j) Check all return codes are handled
         - WRONG_SEC: (error that could be generated if client
               and server have different security flavors.)
           Not really dealing with security problems.

H  k) List and analyze libraries used by NFS, RPC
         - User-land:
              - glibc, rpc-sec, kerberos : already analyzed
              - focus on: idmap (ldap), libgssapi

Comment from Bruce Fields:

       Most of the libraries we use (glibc, MIT kerberos) are
       widely used and (hopefully) have already been subject to a
       lot of scrutiny.  But it might be worth examining the libraries
       we've written or modified:
               libnfsidmap, libacl, libgssapi, and librpcsecgss. 
       Some of those are more mature than others.
       Before that you probably want to look at the code for the
       userland daemons in nfs-utils.

Comment from Kevin Coffman:

       I agree with Bruce.
       librpcsecgss (and libacl) should be moved/added to the list to focus on.

H  l) Analyze daemons
         - Focus on gssd and idmapd

Comment from Kevin Coffman:

       Note that there is a gssd and a svcgssd.
       They share a lot of code, but should both be looked at.

M  m) Run the SPARSE tool on code (already done for whole kernel ?)
         - Done on a regular basis by Trond

2) Run dynamic tests

H  a) User-land: Search for existing memory overflows with DUMA:

H  b) Kernel-land: Same, but with low-level tools (kdb, print, ...)

Comment from Bruce Fields:

       For the kernel: one simple thing to do is to check
               /proc/slabinfo, /proc/meminfo while running other
       tests.  Also make sure all the "kernel hacking" debugging
       options are turned on in the kernel configuration
       when running tests.  (Except when testing performance--the slab
       debugging in particular can have a big effect on performance.)

3) Modify Client side for attacking Server

   a) Modify: NFSv4, RPC, TI-RPC, TCP/IP, gss source code

   b) Use code of Python Client (rather than C client)

Comment from Bruce Fields:

       I've cc'd Fred Ismaan (iisaman@citi.umich.edu), who maintains
       pynfs. He's done some of this work and may have some ideas
       about what further could be done.

M  c) Randomly fill structures passed to server with:
         - large data
         - wrong
      and see what happens.
         - (Structures belong to: NFSv4, RPC, TI-RPC or TCP/IP)
         - Add new tests in newpynfs and Work with Fred Isaman

L  e) Focus on suspected but not-proved weaknesses in server

M  f) Hijack the NFSv4 protocol by sending not-logical or
              not-expected operations to server
         - pynfs already does tests like that. Contact F. Isaman.
         - Test with large compounds
         - ToBeCompleted

Comment from Bruce Fields:

       I'll try to think of some suggestions here.

4) Modify Server-side for attacking Client

Low Priority !

   a) It supposes the client can be routed to a NFSv4 pirate server
               (fs_location or DNS attack)

   b) Are there possibilities to crash the client machine or
               to corrupt system data ?
         - gss should protect against this kind of attack

Comment from Bruce Fields:

   One have to systematicaly use a stronger security flavor if he
       does not trust the server.