Security Attack Penetration
From Linux NFS
(Difference between revisions)
| Line 6: | Line 6: | ||
a) the level of expected risk, and | a) the level of expected risk, and | ||
b) the expected probability of finding problems. | b) the expected probability of finding problems. | ||
| - | |||
| - | |||
Bull plans to work on the following: | Bull plans to work on the following: | ||
| Line 16: | Line 14: | ||
In 1H2006: | In 1H2006: | ||
3) Modify Client side for attacking Server | 3) Modify Client side for attacking Server | ||
| - | |||
== 1) Analyze the source code == | == 1) Analyze the source code == | ||
| Line 56: | Line 53: | ||
In general, the length is passed on. | In general, the length is passed on. | ||
So memory overrun problems should not appear | So memory overrun problems should not appear | ||
| - | + | ||
Comment from Bruce Fields: | Comment from Bruce Fields: | ||
strcpy seems relatively rare in the kernel sources. (I just | strcpy seems relatively rare in the kernel sources. (I just | ||
| Line 64: | Line 61: | ||
making sure the length passed to it is always verified in | making sure the length passed to it is always verified in | ||
some way. | some way. | ||
| - | + | ||
VH e) Search for fixed-sized arrays filled with dynamic-sized data | VH e) Search for fixed-sized arrays filled with dynamic-sized data | ||
- buffer-overflow | - buffer-overflow | ||
| Line 102: | Line 99: | ||
- glibc, rpc-sec, kerberos : already analyzed | - glibc, rpc-sec, kerberos : already analyzed | ||
- focus on: idmap (ldap), libgssapi | - focus on: idmap (ldap), libgssapi | ||
| - | + | ||
Comment from Bruce Fields: | Comment from Bruce Fields: | ||
Most of the libraries we use (glibc, MIT kerberos) are | Most of the libraries we use (glibc, MIT kerberos) are | ||
| Line 126: | Line 123: | ||
== 2) Run dynamic tests == | == 2) Run dynamic tests == | ||
| - | + | ||
H a) User-land: Search for existing memory overflows with DUMA: | H a) User-land: Search for existing memory overflows with DUMA: | ||
| - | + | ||
H b) Kernel-land: Same, but with low-level tools (kdb, print, ...) | H b) Kernel-land: Same, but with low-level tools (kdb, print, ...) | ||
| - | + | ||
Comment from Bruce Fields: | Comment from Bruce Fields: | ||
For the kernel: one simple thing to do is to check | For the kernel: one simple thing to do is to check | ||
| Line 140: | Line 137: | ||
== 3) Modify Client side for attacking Server == | == 3) Modify Client side for attacking Server == | ||
| - | + | ||
a) Modify: NFSv4, RPC, TI-RPC, TCP/IP, gss source code | a) Modify: NFSv4, RPC, TI-RPC, TCP/IP, gss source code | ||
| - | + | ||
b) Use code of Python Client (rather than C client) | b) Use code of Python Client (rather than C client) | ||
| - | + | ||
Comment from Bruce Fields: | Comment from Bruce Fields: | ||
I've cc'd Fred Ismaan (iisaman@citi.umich.edu), who maintains | I've cc'd Fred Ismaan (iisaman@citi.umich.edu), who maintains | ||
| Line 174: | Line 171: | ||
a) It supposes the client can be routed to a NFSv4 pirate server | a) It supposes the client can be routed to a NFSv4 pirate server | ||
(fs_location or DNS attack) | (fs_location or DNS attack) | ||
| - | + | ||
b) Are there possibilities to crash the client machine or | b) Are there possibilities to crash the client machine or | ||
to corrupt system data ? | to corrupt system data ? | ||
Revision as of 14:51, 7 December 2005
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) 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.
