OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[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]