Security Attack Penetration

From Linux NFS

You do not have permission to edit this page, for the following reason:

You can view and copy the source of this page:

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 == 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.

Return to Security Attack Penetration.