1. Urgent need to audit NFSv4

1.1 A widely-used protocol

NFS has always been one of the most popular protocol for distributed file systems in Unix-like world. NFSv4 can also be used on other types of systems, for instance Windows and Mac OS.
On Linux, NFSv4 becomes more and more stable and starts being integrated in several distros (Red Hat and Novell). For instance, the latest version of NFS is used as default in SLES 10 (Suse Linux Enterprise Server). It is now time for lots of administrators to replace their old NFS by the version 4. And since Linux is widely distributed across the world, NFSv4 will eventually be installed and used on a huge number of boxes. Therefore, the protocol should be efficient, robust and secure.

1.2 New context for NFSv4

NFSv4 was designed to operate in WAN/Internet context and this introduces new security issues. NFS traffic has to go through non-trusted areas where the risk of being attacked is high.
And in LAN context, lots of administrator will also want to secure NFS exchanges thanks to the Kerberos 5 support. Indeed, most attacks come from inside the company's network and they are thus carried out by the employee themselves. Kerberos makes attacks harder since it authenticates the users and it protects the integrity and privacy of the data exchanged on the network.
Although Kerberos 5 specification is considered as secure by the hacking community, it was important to audit how the implemention was done in NFSv4.

1.3 State of the security analysis

When I joined NFSv4 project, little work had already been done on the security audit. Vincent Roqueta (from Bull) had already done an automated source code audit few months ago. The CITI had also requested a source code audit to Coverity in June, 2005.
Therefore, it was necessary to have someone working full-time on this project in order to initiate the security audit. When I met Tony Reix - my internship tutor - for the first time, he explained me their urgent need to work on NFSv4 security. I was not experienced with the security audit of network protocols nor with the NFSv4 protocol but I had a background in network and systems security. That's why I thought contributing to this project could be a rewarding experience.

2. Goals of the security audit

The goals of the security audit were :

• To explain how NFSv4 guarantees the security of the exchanges
• To draft a list of the threats specific to NFSv4 and to describe the attacking model
• To depict some possible attacks in details and to evaluate their complexity and their probability of success
• To propose some improvements and solutions for further development
• To write some recommendations for a secure usage of NFSv4 (for administrators)

3. Organization

I wrote a general work plan for the security audit including some tasks I will be able to do during the internship and some left to future contributors. I took the Security Wiki (on OSDL Website) as a starting point.
My own work was organized as following :
I wrote a general paper on NFSv4 security : I drafted a list of attacks, I provided countermeasures and I evaluated the risk in terms of complexity and probability of success.
I provided a theoretical analysis of RPCSEC_GSS, the software in charge of securing RPC requests/responses. Especially, I audited the cryptographic algorithms employed by the protocol and the context in which they are used. The goal was to compute the complexity of attacking those algorithms, to compare this complexity with the state-of-the-art in cryptography and to write some recommendations for future developments.
I audited some relevant parts of NFSv4 source code thanks to security analysis tool and my knowledge of C vulnerabilities.

4. Our papers about NFSv4 security

Here are the links to all of our papers about NFSv4 administration :

• Paper describing the security audit of NFSv4 (including the theoratical audit of RPCSEC_GSS) [PDF]
• Slides of the presentation at Bull in Aug. 24. [PDF]

4. Conclusions

4.1 What has been done

• Possible attacks against NFSv4 and the underlaying risks have enumerated and explained.
• A theoretical audit of RPCSEC_GSS has been completed. It has shown that the algorithms in use for authentication, integrity and privacy are not enough secure regarding today's computing power. A new version of RPCSEC_GSS is being developed by CITI.
• A small part of the source code has been audited and documented.
• A draft of a fuzzer to audit NFSv4 dynamically has been developed. It is based on SPIKE framework. The goal is to inject faulty requests into NFSv4 server and to observe the response in return. Hopefully, it will help to discover vulnerabilities but there are still a lot of work to complete this fuzzer.

4.2 Perspectives

The security audit is not completed and I hope someone will finish it. Work has to be done on the source code audit since the area of NFSv4-related source code is really large. It may take several months to audit seriously all the code. My prototype of a modified client to run a dynamic audit on NFSv4 server should also be completed to implement every NFSv4 operation.