[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Add security considerations
It's considered good (and normal) practice to include information on security considerations in the normative part of a specification. Currently, the Office specification doesn't include such information. It's not clear it belongs anywhere else, so I guess it'd be a whole new chapter ("Security Considerations"), or an "Other issues" chapter with a "Security Considerations" subsections. Here's some proposed text for "Security Considerations": The purpose of this format is to allow the free interchange of common office data. Recipients are expected to receive such data from a variety of sources, such as email and web sites. However, some of this data may be from an attacker. This is true even if the sender is "trusted"; the "from" address of an email might be forged, a user's system might be subverted to send malicious email, or a website might be compromised to send malicious data. Thus, any program that processes data in this format process it in a way that protects users from potentially malicious senders. An implementation MUST NOT be vulnerable to buffer overflows that can be caused by this format (including both processing and display of the data). Depending on the language used, scripts can cause significant damage. Thus, scripts with unlimited capabilities MUST NOT be executed when a data file is loaded. Startup scripts MUST be limited so that they cannot cause damage, even if an attacker writes the script, unless there is some reason to be certain that the file is not malicious. For example, a startup script SHOULD NOT be able to request external programs to run, SHOULD NOT be able to write to storage (or can only write to a specially-limited subdirectory), and and SHOULD NOT be able to send information elsewhere (e.g., by sending email or supporting an Internet connection). Even stricter limitations are encouraged. Startup scripts SHOULD NOT simply ask the user if they want to run the start-up script, because naive users tend to answer "yes" no matter what the risk. Implementations SHOULD be prepared to handle files not in the correct format. If they cannot be repaired, then implementations should be prepared to reject the data, instead of crashing. Implementations SHOULD also attempt to limit the damage of denial-of-service attacks. For example, it is possible to create small zip files that, when uncompressed, produce massive files (e.g., 2^33 control-As). Thus, implementations SHOULD save modified files in some space before loading another file, so that if something goes wrong during loading, the modifications will not be lost. Implementations SHOULD also check the zip files before loading for files that are obviously intended to decompress into overlarge files. Also, add to section 2.5 (Scripts): Note that data in this format may be sent by an attacker, thus, scripts must be limited. See the "Security considerations" section for more information. --- David A. Wheeler
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]