--- 1/draft-ietf-nfsv4-rfc1832bis-05.txt 2006-02-05 00:48:36.000000000 +0100 +++ 2/draft-ietf-nfsv4-rfc1832bis-06.txt 2006-02-05 00:48:36.000000000 +0100 @@ -1,15 +1,14 @@ - Network Working Group M. Eisler Internet-Draft Editor -Document: draft-ietf-nfsv4-rfc1832bis-05.txt Network Appliance, Inc. - February 2005 +Document: draft-ietf-nfsv4-rfc1832bis-06.txt Network Appliance, Inc. + May 2005 XDR: External Data Representation Standard Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. @@ -61,35 +60,36 @@ 4.19. Optional-data . . . . . . . . . . . . . . . . . . . . . . 14 4.20. Areas for Future Enhancement . . . . . . . . . . . . . . 15 5. DISCUSSION . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. THE XDR LANGUAGE SPECIFICATION . . . . . . . . . . . . . . . 17 6.1. Notational Conventions . . . . . . . . . . . . . . . . . . 17 6.2. Lexical Notes . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Syntax Information . . . . . . . . . . . . . . . . . . . . 18 6.4. Syntax Notes . . . . . . . . . . . . . . . . . . . . . . . 20 7. AN EXAMPLE OF AN XDR DATA DESCRIPTION . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . 21 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 - 10. TRADEMARKS AND OWNERS . . . . . . . . . . . . . . . . . . . 22 - 11. ANSI/IEEE Standard 754-1985 . . . . . . . . . . . . . . . . 22 - 12. NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . 24 - 13. INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . 24 - 14. Editor's Address . . . . . . . . . . . . . . . . . . . . . 24 - 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 24 - 16. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 25 - 17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 25 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 + 10. TRADEMARKS AND OWNERS . . . . . . . . . . . . . . . . . . . 23 + 11. ANSI/IEEE Standard 754-1985 . . . . . . . . . . . . . . . . 23 + 12. NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . 25 + 13. INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . 25 + 14. Editor's Address . . . . . . . . . . . . . . . . . . . . . 25 + 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 25 + 16. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 26 + 17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 26 1. Changes from RFC1832 This document makes no technical changes to RFC1832 and is published - for the purpose of noting IANA considerations and distinguishing - normative from informative references. + for the purpose of noting IANA considerations, augmenting security + considerations, and distinguishing normative from informative + references. 2. INTRODUCTION XDR is a standard for the description and encoding of data. It is useful for transferring data between different computer architectures, and has been used to communicate data between such diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*. XDR fits into the ISO presentation layer, and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference between these two is that XDR uses implicit typing, while X.409 uses @@ -984,31 +984,84 @@ 20 00 00 00 04 .... -- length of interpretor = 4 24 6c 69 73 70 lisp -- interpretor characters 28 00 00 00 04 .... -- length of owner = 4 32 6a 6f 68 6e john -- owner characters 36 00 00 00 06 .... -- length of file data = 6 40 28 71 75 69 (qui -- file data bytes ... 44 74 29 00 00 t).. -- ... and 2 zero-bytes of fill 8. Security Considerations - Security issues are not discussed in this memo. + XDR is a data description language, not a protocol, and hence it does + not inherently give rise to any particular security considerations. + Protocols that carry XDR-formatted data, such as NFSv4, are + responsible for providing any necessary security services to secure + the data they transport. + + Care must be take to properly encode and decode data to avoid + attacks. Known and avoidable risks include: + + * Buffer overflow attacks. Where feasible, protocols should be + defined with explicit limits (via the "<" [ value ] ">" notation + instead of "<" ">") on elements with variable length data types. + Regardless of the feasibility of an explicit limit on the + variable length of an element of a given protocol, decoders need + to ensure the incoming size does not exceed the length of any + provisioned receiver buffers. + + * Nul octets embedded in an encoded value of type string. If the + decoder's native string format uses nul terminated strings, then + the apparent size of the decoded object will be less than the + amount of memory allocated for the string. Some memory + deallocation interfaces take a size argument. The caller of the + deallocation interface would likely determine the size of the + string by counting to the location of the nul octet, and adding + one. This discrepancy can cause memory leakage (because less + memory is actually returned to the free pool than allocated), + leading to system failure and a denial of service attack. + + * Decoding of characters in strings that are legal ASCII + characters but nonetheless are illegal for the intended + application. For example some operating systems treat the '/' + character as a component separator in path names. For a protocol + that encodes a string in the argument to a file creation + operation, the decoder needs to ensure sure '/' is not inside + the component name. Otherwise, a file with an illegal '/' in + its name will be created, making it difficult to remove, and is + therefore a denial of service attack. + + * Denial of service caused by recursive decoder or encoder + subroutines. A recursive decoder or encoder might process data + that has a structured type with a member of type optional data + that directly or indirectly refers to the structured type (i.e. + a linked list). For example, + + struct m { + int x; + struct m *next; + }; + + An encoder or decoder subroutine might be written to recursively + call itself each time another element of type "struct m" is + found. An attacker could construct a long linked list of "struct + m" elements in the request or response which then causes a stack + overflow on the decoder or encoder. Decoders and encoders + should be written non-recursively, or impose a limit on list + length. 9. IANA Considerations - It is possible, if not likely, that new data types will - be added to XDR in the future. The process for adding - new types is via a standards track RFC and not - registration of new types with IANA. Standards track RFCs - that update or replace this document should be - documented as such in the RFC Editor's database of - RFCs. + It is possible, if not likely, that new data types will be added to + XDR in the future. The process for adding new types is via a + standards track RFC and not registration of new types with IANA. + Standards track RFCs that update or replace this document should be + documented as such in the RFC Editor's database of RFCs. 10. TRADEMARKS AND OWNERS SUN WORKSTATION Sun Microsystems, Inc. VAX Hewlett-Packard Company IBM-PC International Business Machines Corporation Cray Cray Inc. NFS Sun Microsystems, Inc. Ethernet Xerox Corporation. Motorola 68000 Motorola, Inc. @@ -1109,35 +1162,35 @@ [HPRE] "HP Precision Architecture Handbook", June 1987, 5954-9906. 14. Editor's Address Mike Eisler 5765 Chase Point Circle Colorado Springs, CO 80919 USA Phone: 719-599-9026 - EMail: mike@eisler.com + EMail: mike.ietf.xdr@eisler.com Please address comments to: nfsv4@ietf.org 15. Acknowledgements Bob Lyon was Sun's visible force behind ONC RPC in the 1980s. Sun Microsystems, Inc. is listed as the author of RFC1014, which RFC1832 was heavily derived from. Raj Srinivasan in turn edited RFC1014 into RFC1832. Raj and the rest of the old ONC RPC working group produced RFC1832 from which this document is derived. Mike Eisler and Bill Janssen submitted the implementation reports for this standard. Kevin - Coffman and Benny Halevy reviewed this document and gave feedback. - Peter Astrand and Bryan Olson pointed out several errors in RFC1832 - which are corrected in this document. + Coffman, Benny Halevy, and Jon Peterson reviewed this document and + gave feedback. Peter Astrand and Bryan Olson pointed out several + errors in RFC1832 which are corrected in this document. 16. IPR Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and