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: RE: [office-comment] ODF security hazard? (ODF all versions)

I think banning <!DOCTYPE > is a little harsh and one might rather address
the specific problem (reliance on external entities).  Being able to define
character entities is actually very handy, and rather applicable in those
places where ODF tends to be HTML-ish.  There are many more
likely-to-succeed opportunities in an ODF document to introduce an IRI the
resolution of which can present a security hazard.  Unfortunately, I don't
think we are required to have a security-considerations section the way IETF
RFCs must.

I suppose having a secure ODF document profile might be useful, but it seems
awfully binary.  For example, OLE embeddings depend on a locally-registered
application for the embedding to have any active behavior, and that is an
interoperability and interchange problem more than a security one.  (Also,
an ODF processor needs to understand the MIME Type of the embedding before
it can even think about getting in trouble.)  At least OLE embeddings
contain a static rendition that is to be used when the application is
unavailable or the object is not updated.  

I'm wondering whether it is permissible for <!DOCTYPE>-included URIs to
relatively refer within the package itself, assuming that the prescription
in IS 26300 section 17.5 is considered to be applicable.  (Hmm, note to self
to check on that one.  I suppose that means the external DTD could be
included as part of the package.  Now that's a cool way to convey a custom
interoperability agreement's syntactic restriction of the XML document in
the package itself.  I wouldn't expect it to work though.)

The bigger issue seems to be the failure of ODF to profile its normative
dependence on XML 1.0 at all.  So, at the moment, all XML 1.0 edge/outlier
cases have to be tolerated (e.g., charsets, parameters, prolog omission,
MIME Type interaction, entity definitions, DTD occurrences, processing
instructions, and for all I know, byte-order marks).  I assume that the
various normative statements on XML processors apply as well, though I don't
know about any MAYs and SHOULDs (and whose definition of such conformance
language is being used, in contrast to the ISO usage in those ODF
specifications starting with IS 26300:2006).

I don't know how this lands as a practical matter.  Since the specification
is silent, we will have to find out what happens in actual practice and how
the edges fit together with other aspects of the ODF specification.  I'm not
sure we should even test for outlier cases, considering that this particular
generosity (or carelessness) with respect to XML 1.0 may not show up as
conformance and interoperability difficulties in practice. 

 - Dennis

PS: I don't know that anyone on the ODF TC has noticed that there is a
landmine in the latest XML 1.0 edition, having to do with the expanded
character set (well, code points) that must be tolerated in NCNames, IDs,
IDREFs, IDREFS[s] and that these are also submarined in by some clever
adjustment to URLs that are cross-referenced from the Namespace
specification and in some links in older editions of XML 1.0.  They apply to
xml:id too, of course.  Are you testing us about that in the comment at

-----Original Message-----
From: Alex Brown [mailto:alexb@griffinbrown.co.uk] 
Sent: Saturday, February 21, 2009 07:16
To: office-comment@lists.oasis-open.org
Subject: RE: [office-comment] ODF security hazard? (ODF all versions)

Rob hi

> But I do think this would be good to collect a set of security 
> considerations into an Appendix, as we have with Bidi techniques and 
> Accessibility guidelines.  If there is interest we could also explore 
> a "Secure ODF" profile that would forbid things like OLE embeddings, 
> scripts, etc.

That sounds like a sensible approach.

Since the DTD feature is not needed though, it is one attack vector
which could be easily blocked by forbidding DTDs ...

- Alex.

This publicly archived list offers a means to provide input to the
OASIS Open Document Format for Office Applications (OpenDocument) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: office-comment-subscribe@lists.oasis-open.org
Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
List help: office-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/office-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]