[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 <http://lists.oasis-open.org/archives/office-comment/200902/msg00009.html>? -----Original Message----- From: Alex Brown [mailto:alexb@griffinbrown.co.uk] http://lists.oasis-open.org/archives/office-comment/200902/msg00029.html 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 http://lists.oasis-open.org/archives/office-comment/200902/msg00028.html > 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]