| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1197580341.21474.29.camel@prospero> Date: Thu, 13 Dec 2007 16:12:20 -0500 From: "webmaster@...workdefense.biz" <webmaster@...workdefense.biz> To: bugtraq <bugtraq@...urityfocus.com> Subject: Re: AW: MS Office 2007: Digital Signature does not protect Meta-Data Does this same issue appear in OpenOffice ODF format? Though it does not l= ook like a huge issue, of itself, it is similar to the way Microsoft ignore= s metadata in all files, which is a way to add executable code to applicati= ons with the names of known MS utilities, like notepad.exe. If the metadat= a file can be modified in the MS word properties dialog, it is also possibl= e to modify the file in a text editor, and probably get a MS document to ru= n arbitrary code when you open it. This is the impact that the original po= st does not make clear. Wolf Halton Halton Security Institute networkdefense.biz On Thu, 2007-12-13 at 17:42 +0100, Naujoks, Hans-Dietmar wrote: > Dear Mr. Poehls, >=20 > I think Microsoft does not consider metadata attached to a document as pa= rt of the document and so they decided not to include it in the content pro= tected by the certificate.=20 >=20 > This fits the way we use attaching metadata during the process of categor= ization to enable retrieval of a document by means and taxonomies of the re= cipient, not of the author. If instead, as you seem to propose, metadata wo= uld be treated as part of the document, attaching the metadata needed for r= etrieval purposes would invalidate the signature of the document.=20 >=20 > Therefore this time I would go with Microsoft for their solution fits our= needs and doesn't compromise the integrity protection of the document itse= lf in any serious way. Just think of it as a sticker placed on the outside = of a sealed envelope: You mustn't trust anything on the outside, just look = inside the envelope to find the information you can rely on. >=20 > Yours > H.-D. Naujoks > T=C3=9CV S=C3=9CD Informatik und Consulting Services GmbH >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: poehls@...ormatik.uni-hamburg.de [mailto:poehls@...ormatik.uni-hambu= rg.de]=20 > Gesendet: Mittwoch, 12. Dezember 2007 11:35 > An: bugtraq@...urityfocus.com > Betreff: MS Office 2007: Digital Signature does not protect Meta-Data >=20 >=20 > Affects: Microsoft Office 2007 (12.0.6015.5000)=20 >=20 > MSO (12.0.6017.5000)=20 >=20 > possibly older versions >=20 >=20 >=20 > I. Background >=20 >=20 > Microsoft Office is a suite containing several programs to >=20 > handle Office documents like text documents or spreadsheets.=20 >=20 > The latest version uses an XML based document format.=20 >=20 > Microsoft Office allows documents to be digitally signed by >=20 > authors using certified keys, allowing viewers to verify the=20 >=20 > integrity and the origin based on the author's public key.=20 >=20 > The author's public key certificate, which can come from a=20 >=20 > trusted third party, is embedded in the signed document.=20 >=20 > It is XML DSig based. >=20 >=20 >=20 > II. Problem Description >=20 >=20 > Microsoft Office documents carry meta data information=20 >=20 > according to the DublinCore metadata in the file=20 >=20 > docProps/core.xml . Among these meta data information=20 >=20 > are the fields "LastModifiedBy", "creator" together with=20 >=20 > several others that can be displayed/changed through the=20 >=20 > following menu "Office Button -> Prepare -> Properties". >=20 > These entries can be changed without invalidating the signature.=20 >=20 > At least under Windows Operating Systems these information are=20 >=20 > also shown in the Window's file systems properties. >=20 >=20 >=20 > III. Impact >=20 >=20 > The meta data of signed Microsoft Office documents can be=20 >=20 > changed. An attacker can change the values to spoof the origin=20 >=20 > of signed documents, hoping to induce trust or otherwise=20 >=20 > deceive the user. >=20 >=20 > III.1. Proof of Concept >=20 >=20 > Open the OOXML ZIP container of a signed document.=20 >=20 > Change the values in the docProps/core.xml file.=20 >=20 > For example set the value between "<dc:creator>*</dc:creator>"=20 >=20 > to "<dc:creator>FooBar</dc:creator>".=20 >=20 > The changes will be displayed in the document's properties=20 >=20 > dialog as described above. The signature will still be valid. >=20 >=20 >=20 > IV. Workaround >=20 >=20 > The meta data information of a signed OOXML document=20 >=20 > can be changed without invalidating the signature, thus=20 >=20 > information about the real author of a signed document can >=20 > only be retrieved from the certificate.=20 >=20 > The signed file's meta data can not be trusted as the=20 >=20 > meta data is not covered by the signature. >=20 > =20 >=20 >=20 > V. Solution >=20 >=20 > No possible solution. >=20 >=20 >=20 > VI. Correction details >=20 >=20 > A closer look into the references section of the XML signature=20 >=20 > used by Microsoft Office (stored in the File=20 >=20 > _xmlsignatures\sig1.xml) reveals that the file core.xml is=20 >=20 > not in the list of references. Thus it is not covered by the >=20 > signature.=20 >=20 >=20 > As a solution the scope of the signature needs to be extended=20 >=20 > to cover all the relevant information contained in the whole=20 >=20 > document, thus also the meta data in core.xml. >=20 >=20 > Include core.xml, and probably other files in the signature's=20 >=20 > list of references. >=20 >=20 > VII. Time line >=20 >=20 > 2007-10-24: Vendor contacted >=20 > 2007-10-25: Vendor acknowledged receipt >=20 > 2007-11-14: 1st Deadline reached >=20 > 2007-11-27: Reminder sent >=20 > 2007-12-12: No response received until today >=20 >=20 >=20 >=20 >=20 > Yours, >=20 > Henrich C. Poehls, Dong Tran, Finn Petersen, Frederic Pscheid >=20 > SVS - Dept. of Informatics - University of Hamburg --=-jXu/BmjXjlrX2SFAJDvD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.16.1"> </HEAD> <BODY> <PRE> Does this same issue appear in OpenOffice ODF format? Though it does not look like a huge issue, of itself, it is similar to the way Microsoft ignores metadata in all files, which is a way to add executable code to applications with the names of known MS utilities, like notepad.exe. If the metadata file can be modified in the MS word properties dialog, it is also possible to modify the file in a text editor, and probably get a MS document to run arbitrary code when you open it. This is the impact that the original post does not make clear. Wolf Halton Halton Security Institute networkdefense.biz On Thu, 2007-12-13 at 17:42 +0100, Naujoks, Hans-Dietmar wrote: </PRE> <BLOCKQUOTE TYPE=CITE> <PRE> <FONT COLOR="#000000">Dear Mr. Poehls,</FONT> <FONT COLOR="#000000">I think Microsoft does not consider metadata attached to a document as part of the document and so they decided not to include it in the content protected by the certificate. </FONT> <FONT COLOR="#000000">This fits the way we use attaching metadata during the process of categorization to enable retrieval of a document by means and taxonomies of the recipient, not of the author. If instead, as you seem to propose, metadata would be treated as part of the document, attaching the metadata needed for retrieval purposes would invalidate the signature of the document. </FONT> <FONT COLOR="#000000">Therefore this time I would go with Microsoft for their solution fits our needs and doesn't compromise the integrity protection of the document itself in any serious way. Just think of it as a sticker placed on the outside of a sealed envelope: You mustn't trust anything on the outside, just look inside the envelope to find the information you can rely on.</FONT> <FONT COLOR="#000000">Yours</FONT> <FONT COLOR="#000000">H.-D. Naujoks</FONT> <FONT COLOR="#000000">TÜV SÜD Informatik und Consulting Services GmbH</FONT> <FONT COLOR="#000000">-----Ursprüngliche Nachricht-----</FONT> <FONT COLOR="#000000">Von: <A HREF="mailto:poehls@...ormatik.uni-hamburg.de">poehls@...ormatik.uni-hamburg.de</A> [<A HREF="mailto:poehls@...ormatik.uni-hamburg.de">mailto:poehls@...ormatik.uni-hamburg.de</A>] </FONT> <FONT COLOR="#000000">Gesendet: Mittwoch, 12. Dezember 2007 11:35</FONT> <FONT COLOR="#000000">An: <A HREF="mailto:bugtraq@...urityfocus.com">bugtraq@...urityfocus.com</A></FONT> <FONT COLOR="#000000">Betreff: MS Office 2007: Digital Signature does not protect Meta-Data</FONT> <FONT COLOR="#000000">Affects: Microsoft Office 2007 (12.0.6015.5000) </FONT> <FONT COLOR="#000000"> MSO (12.0.6017.5000) </FONT> <FONT COLOR="#000000"> possibly older versions</FONT> <FONT COLOR="#000000">I. Background</FONT> <FONT COLOR="#000000">Microsoft Office is a suite containing several programs to</FONT> <FONT COLOR="#000000">handle Office documents like text documents or spreadsheets. </FONT> <FONT COLOR="#000000">The latest version uses an XML based document format. </FONT> <FONT COLOR="#000000">Microsoft Office allows documents to be digitally signed by</FONT> <FONT COLOR="#000000">authors using certified keys, allowing viewers to verify the </FONT> <FONT COLOR="#000000">integrity and the origin based on the author's public key. </FONT> <FONT COLOR="#000000">The author's public key certificate, which can come from a </FONT> <FONT COLOR="#000000">trusted third party, is embedded in the signed document. </FONT> <FONT COLOR="#000000">It is XML DSig based.</FONT> <FONT COLOR="#000000">II. Problem Description</FONT> <FONT COLOR="#000000">Microsoft Office documents carry meta data information </FONT> <FONT COLOR="#000000">according to the DublinCore metadata in the file </FONT> <FONT COLOR="#000000">docProps/core.xml . Among these meta data information </FONT> <FONT COLOR="#000000">are the fields "LastModifiedBy", "creator" together with </FONT> <FONT COLOR="#000000">several others that can be displayed/changed through the </FONT> <FONT COLOR="#000000">following menu "Office Button -> Prepare -> Properties".</FONT> <FONT COLOR="#000000">These entries can be changed without invalidating the signature. </FONT> <FONT COLOR="#000000">At least under Windows Operating Systems these information are </FONT> <FONT COLOR="#000000">also shown in the Window's file systems properties.</FONT> <FONT COLOR="#000000">III. Impact</FONT> <FONT COLOR="#000000">The meta data of signed Microsoft Office documents can be </FONT> <FONT COLOR="#000000">changed. An attacker can change the values to spoof the origin </FONT> <FONT COLOR="#000000">of signed documents, hoping to induce trust or otherwise </FONT> <FONT COLOR="#000000">deceive the user.</FONT> <FONT COLOR="#000000">III.1. Proof of Concept</FONT> <FONT COLOR="#000000">Open the OOXML ZIP container of a signed document. </FONT> <FONT COLOR="#000000">Change the values in the docProps/core.xml file. </FONT> <FONT COLOR="#000000">For example set the value between "<dc:creator>*</dc:creator>" </FONT> <FONT COLOR="#000000">to "<dc:creator>FooBar</dc:creator>". </FONT> <FONT COLOR="#000000">The changes will be displayed in the document's properties </FONT> <FONT COLOR="#000000">dialog as described above. The signature will still be valid.</FONT> <FONT COLOR="#000000">IV. Workaround</FONT> <FONT COLOR="#000000">The meta data information of a signed OOXML document </FONT> <FONT COLOR="#000000">can be changed without invalidating the signature, thus </FONT> <FONT COLOR="#000000">information about the real author of a signed document can</FONT> <FONT COLOR="#000000">only be retrieved from the certificate. </FONT> <FONT COLOR="#000000">The signed file's meta data can not be trusted as the </FONT> <FONT COLOR="#000000">meta data is not covered by the signature.</FONT> <FONT COLOR="#000000"> </FONT> <FONT COLOR="#000000">V. Solution</FONT> <FONT COLOR="#000000">No possible solution.</FONT> <FONT COLOR="#000000">VI. Correction details</FONT> <FONT COLOR="#000000">A closer look into the references section of the XML signature </FONT> <FONT COLOR="#000000">used by Microsoft Office (stored in the File </FONT> <FONT COLOR="#000000">_xmlsignatures\sig1.xml) reveals that the file core.xml is </FONT> <FONT COLOR="#000000">not in the list of references. Thus it is not covered by the</FONT> <FONT COLOR="#000000">signature. </FONT> <FONT COLOR="#000000">As a solution the scope of the signature needs to be extended </FONT> <FONT COLOR="#000000">to cover all the relevant information contained in the whole </FONT> <FONT COLOR="#000000">document, thus also the meta data in core.xml.</FONT> <FONT COLOR="#000000">Include core.xml, and probably other files in the signature's </FONT> <FONT COLOR="#000000">list of references.</FONT> <FONT COLOR="#000000">VII. Time line</FONT> <FONT COLOR="#000000">2007-10-24: Vendor contacted</FONT> <FONT COLOR="#000000">2007-10-25: Vendor acknowledged receipt</FONT> <FONT COLOR="#000000">2007-11-14: 1st Deadline reached</FONT> <FONT COLOR="#000000">2007-11-27: Reminder sent</FONT> <FONT COLOR="#000000">2007-12-12: No response received until today</FONT> <FONT COLOR="#000000">Yours,</FONT> <FONT COLOR="#000000">Henrich C. Poehls, Dong Tran, Finn Petersen, Frederic Pscheid</FONT> <FONT COLOR="#000000">SVS - Dept. of Informatics - University of Hamburg</FONT> </PRE> </BLOCKQUOTE> </BODY> </HTML> --=-jXu/BmjXjlrX2SFAJDvD--
Powered by blists - more mailing lists