#ooxml

Five computer researchers from Ruhr University Bochum in Germany – Simon Rohlmann, Vladislav Mladenov, Christian Mainka, Daniel Hirschberger, and Jörg Schwenk – describe this sorry state of affairs in a paper titled: “Every Signature is Broken: On the Insecurity of Microsoft Office’s OOXML Signatures.” They were able to identify five ways to attack vulnerable documents to alter their contents and forge signatures.

The paper is scheduled to be presented at the USENIX Security Symposium in August.

And with Microsoft Office for macOS, document signatures simply weren’t validated at all. The researchers found they could add an empty file named sig1.xml to an OOXML package – which consists of multiple zipped files – and the Office for Mac would show a security banner proclaiming that the document was protected by a signature.

“The attacks’ impact is alarming: attackers can arbitrarily manipulate the displayed content of a signed document, and victims are unable to detect the tampering,” the authors explain in their paper.

Microsoft, they claim, acknowledged the findings and awarded a bug bounty, but “has decided that the vulnerabilities do not require immediate attention.” And the researchers say they’ve not heard from OnlyOffice since October 2022.

New Post has been published on https://www.ozgurbilgi.net/ooxmle-itirazlar-reddedildi/

OOXML'e İtirazlar Reddedildi

Further, the letter claims that "ODF is closely tied to OpenOffice and related products" (bad!) while OOXML "reflects the rich set of capabilities in Office 2007" (good!). A more even-handed sentence might read: ODF is an XML-based dump of the internal data structures of OpenOffice, while OOXML is an XML-based dump of the internal data structures of Microsoft Office.

'전자문서 산업을 위한 학술 토론회' 관련 기사: http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140725153903 OOXML은 ISO/IEC 29500 표준으로 MS 오피스의 포맷이고 (docx, pptx 등), OWPML은 KS X 6101 표준으로 한컴오피스2014부터 hwpx라는 이름으로 (아직은 시험적인) 포함된 포맷이다. 이 학술 토론회에서는 업체 사람들이 서로 자기 업체의 포맷을 가지고 자기 포맷이 더 개방적이고 표준으로 바람직한 공공문서 포맷이라고 주장하고 있으나, 사실 OOXML이든 OWPML이든 공공 문서 포맷이 되기에는 마찬가지 문제를 가지고 있다.

OOXML

OOXML의 문제는 이미 과거 표준화 과정에서부터 충분히 알려진 바 있다. 마이크로소프트 측은 6000 페이지의 문서로 구성된 표준을 급행으로 검토할 시간도 주어지지 않은 채 진행하면서, 그 전에 기존에 표준 결정 기구에 가입하지 않은 개발도상국가에 입회비를 지원한 스캔들이 있었다. 이들 개발도상국가가 표준안에 찬성표를 던진 것은 물론이다. (대한민국은 최종적으로 반대에 투표했다.) http://www.zdnet.co.kr/column/column_view.asp?artice_id=00000039161482 기술적으로도 알려진 것만 해도 그렇다. OOXML은 기존의 바이너리 오피스 포맷을 가지고 XML을 컨테이너로 이용한 것 뿐이다. 이러면 XML 파서로 읽을 수 있을 뿐 기존 오피스 포맷과 다를 게 없다. 대표적인 예로 드는 useWord97LineBreaks attribute는 "Word97방식으로 렌더링하라"라고 지정되어 있고 그 Word97 방식이 무엇인지 설명하지 않는다. http://msdn.microsoft.com/en-us/library/documentformat.openxml.wordprocessing.useword97linebreakrules%28v=office.14%29.aspx

OOXML은 마이크로소프트 사의 역사적인 이진 형식을 주의 깊게, 하나도 빠뜨림 없이, 꼼꼼하게 XML 형식으로 복사한 결과물일 뿐이다. XML 은 새 문서 형식을 정의하는 강력하고 풍부한 도구지만, 프로젝트 범위를 잘못 정하는 실수까지 무마해 주는 만병통치약은 아니다. '참고할 문서가 없는 대형 독점 렌더링 라이브러리를 사용한다'는 플래그를 문서 형식에 넣는다면, 플래그를 문서 없는 이진 문자열 내 비트 하나로 명세하든 세 쪽짜리 <>으로 명세하든 상관이 없다. 이 명세는 어디까지나 독점이며, 단순히 XML로 감싸는 방법만으로는 렌더링이 불가능하다.

IBM Developer Works, "OOXML 무엇이 그리 대단한가 " 중에서, http://moonistar.tistory.com/m/post/16

OWPML

이 글을 쓰기 시작한 이유가 바로 이 포맷 때문이다. 올해 초에 직접 KS X 6101 표준 문서를 구입해서 한컴오피스 2014 체험판의 HWPX 결과물과 같이 검토해 봤기 때문이다. 바이너리 MS 오피스 포맷을 XML로 옮긴 게 OOXML이라면, 바이너리 HWP 포맷을 XML로 옮긴 게 바로 OWPML이다. 이것 뿐이다. XML의 파일 하나하나는 HWP에 있던 Compound Document의 스트림 하나하나에 대응하고, XML 태그 하나하나는 HWP에 있던 레코드 정보에 대응하고, XML 속성(attribute)은 레코드의 바이너리 데이터에 해당한다. IP over XML 같은 만우절 장난이라면 몰라도, 이런 포맷을 만드는 게 무슨 의미가 있는 걸까? KS X 6101 역시 OOXML 포맷과 같은 오류를 저지르고 있다. 무엇무엇이 있다라는 설명만 하고 실제 어떻게 구현되는지 제대로 설명하지 않아 사실상 한글과컴퓨터의 구현만이 알 수 있게 되어 있다. 예를 들어 표준 7.1에 보면 XMLTemplate/ 이라는 폴더에 대해 언급했으면서 표준 문서 다른 어디에도 여기에 대한 설명이 없다. 또 한 가지 예를 들면 표준 문서 "8.2.4 호환성 정보"를 보면 "compatibleDocument" 태그가 있다.

...

이런 식으로 쓰면 붙이면 MS-Word 방식으로 렌더링한다. 앞의 OOXML에 있던 useWord97LineBreaks 속성이 생각나는 부분이다. 이 MS-Word 방식이 무엇인지는 알 길이 없다. 원래 HWP 포맷에도 마찬가지의 호환성 문서 정보가 있는데 이 정보까지 OWPML에 그대로 구현해 놓은 것이다. 한컴오피스에서 MS-Word 문서가 상당히 잘 변환되는 비밀이 여기 있다. HWP 포맷에 MS-Word 호환 모드가 있고 한컴오피스에 MS-Word와 비슷한 렌더링 방식을 구현해 놓은 것이다. 이런 것까지 표준에 포함하면 표준 구현은 한컴오피스가 한 것처럼 MS-Word 렌더링 방식까지 따라해야 한단 말인가? 이런 문제점을 지적해야 할 표준 심의 과정도 문제였다. KS X 6101:2011 문서의 해설에 기록되어 있는 표준 제정 과정의 7가지 심의 의견 중에서 문제를 지적한 의견이 6가지인데, (1) 표준 제목 수정 (2) 오타 수정 (3) HWP 약자 설명 추가 (4) ODF, OOXML 상호운용성 추가 (5) ODF, OOXML 인용 추가 (6) 수식, 화학식 누락. 이 중에서 (1)(2)(3)(5)은 단순 수정이고, (4)는 이 표준에서 해당하지 않는다고 조치했고, (6)에서 수식이 추가 된 게 그나마 유일하게 의미 있는 문제점 수정 사항이었다. 한글과컴퓨터에서도 최근 한컴오피스2014에서 처음 구현했으니 검증될 기회도 없었다. OOXML과 마찬가지로 똑같은 포맷을 XML로 감싼다고 해서 구현할 수 있는 건 아니다. 검토했던 결과를 다음 페이지에 기록해 놓았다. https://docs.google.com/spreadsheet/ccc?key=0AjxIVzS0OjQTdEc5V1dhLWJwenhSTEpPWGNMdy12NUE&usp=sharing 기록한 것과 같이 OWPML은 표준에도 오류가 있는데, 이 포맷을 최초로 구현한 한컴오피스 2014의 HWPX 포맷에서도 표준에 없거나 표준과 다르게 사용하고 있다.

ODF 뿐이다

아무리 OOXML과 OWPML이 표준으로 인정받았더라도, 의도적이든 아니든 사실상 특정 업체 독점적이 될 수밖에 없도록 기술된 포맷은 공공문서의 포맷이 되면 안 된다. 현재 나와 있는 해법은 ODF 뿐이다. ODF는 다들 좋아하는 그 표준을 국제/국내 모두 오래전에 획득했다. 물론 같은 학술 대회에서 다음과 같이 한컴 측이 주장한 것과 같이 ODF도 구현별로 차이가 나는 것도 사실이다.

또 국제표준이 만능이 아니라고 반박했다. 그는 “MS 오피스도 환경에 따라 레이아웃이 깨지는 경우가 많고, ODF도 오픈오피스, 심포니, MS 오피스 등 구현회사마다 조금씩 차이가 있다”고 말했다.

http://www.ddaily.co.kr/news/article.html?no=120789

SharePoint 2013 – Creating a Word document with OOXML

This solution is based on the SharePoint-hosted app template provided by Visual Studio 2012. The solution enumerates through each document library in the host website, and adds the library to a drop-down list.

  When the user selects a library and clicks a tile, the app creates a sample Word 2013 document by using OOXML in the selected library.

Prerequisites

This sample requires the following:

Перевод статьи, опубликованной на сайте Альянса ODF в октябре этого года. С оригиналом на английском языке [«Implementation of Office Open XML (OOXML): What Governments Need to Know»][src] можно познакомиться на официальном сайте Альянса: www.odfalliance.org. Перевод несколько утрачивает свою значимость в связи с тем, что несколько дней назад ODF 1.0 принят в России в качестве национального стандарта ([ГОСТ Р ИСО/МЭК 26300-2010 «Информационная технология. Формат Open Document для офисных приложений (OpenDocument) v1.0»][gost]). С другой стороны, статья может стать хорошим дополнением к этой новости, предъявляя очередные аргументы в пользу того, почему стоит следовать стандарту ODF. [src]: http://www.odfalliance.org/resources/OOXML_GovsNeedKnow_Oct2010.pdf "Implementation of Office Open XML (OOXML): What Governments Need to Know" [gost]: http://webportalsrv.gost.ru/portal/UVED_2007st.nsf/438c8c3c9e06dc87c32573a100549873/c4b660ff237e33ea432578020033edf5?OpenDocument "ГОСТ Р ИСО/МЭК 26300-2010 «Информационная технология. Формат Open Document для офисных приложений (OpenDocument) v1.0»" Государственные учреждения по всему миру всё больше осознают важность открытых стандартов в области ИКТ, поскольку последние способствуют реализации права на выбор и возможности взаимозамены использующих их систем, влияют на снижение расходов и двигают вперёд инновации. Сама идея того, что для государственного документооборота должен использоваться открытый формат, стала уже сама собой разумеющейся, а использование открытых стандартов рассматривается как неотъемлемая часть стратегий создания систем электронного правительства. Хотя данная тенденция нашла отражение в создании *открытого формата документов* (Open Document Format, ODF), который получает всё большее признание и постепенно начинает использоваться всё большим числом госучреждений11 «Состояние стандарта ODF и взгляд в 2010 год», публикация Альянса ODF — [“The State of ODF & Outlook for 2010”][1], ODF Alliance, в то же время продолжается неразбериха с реализацией стандартов, претендующих на статус альтернатив для ODF. Речь идет о формате, инициированном фирмой Microsoft — Office Open XML (OOXML). В целях информирования госучреждений по этому вопросу данная статья описывает текущее состояние реализации стандарта OOXML. В числе прочего даётся историческая справка по его разработке и стандартизации, а также освещается возникновение нынешней ситуации, при которой в наличии имеется нескольких разных форматов OOXML. [1]: http://www.odfalliance.org/resources/Adoptions-ODF-2010-Feb.pdf "The State of ODF & Outlook for 2010" Нынешняя путаница с OOXML берёт своё начало в создании нескольких версий стандарта в рамках ИСО/МЭК -------------------------------------------------------------------------------------------------------------------------- Понимание того, какие неприятные обстоятельства поспособствовали разработке OOXML, помогает объяснить сегодняшнюю неразбериху, связанную с данным форматом. В первую очередь необходимо понимать, что, когда речь идёт о стандартах, успешность измеряется в том, какие проблемы стандарт позволяет решить и какие он предоставляет возможности для инноваций. Чаще всего среди причин создания и введения открытых стандартов в области ИКТ называют потребность в интероперабельности, обеспечение возможности выбора и гибкости. В противоположность этому, формат OOXML возник как реакция Microsoft на проблему отсутствия *у них* подходящего стандарта, осознанную в середине 2005 года, когда госучреждения начали требовать открытых стандартов, Евросоюз призывал к открытию форматов документов и всеми были действительно осознаны риски зависимости от одного поставщика. Без наличия в офисном ПО поддержки формата документов, соответствующего некоторому *открытому* стандарту, использование Microsoft Office в госучреждениях в разных странах могло встать под угрозу, в особенности в связи с тем, что открытым стандартам стали давать предпочтение. Раздел описания целей стандарта OOXML затрагивает данную конфликтную ситуацию, пытаясь охватить как цели «точного представления ранее сформированного корпуса электронных документов, таблиц и презентаций, созданных с помощью приложений Microsoft Office» начиная с версии Office 97, так и цели «упрощения расширяемости и интероперабельности (совместимости)...»22 ИСО/МЭК 29500 «Форматы файлов Office Open XML», Часть 1, Раздел 1 «Цели» — ISO/IEC 29500 “Office Open XML File Formats”, Part 1, Section 1 “Scope” При такой поспешности и довольно нелепых попытках переработать существующий проприетарный стандарт под требуемые цели, OOXML был создан без достаточных усилий к достижению отраслевого консенсуса, без попытки вместе с конкурирующими сторонами выработать приемлемый для всех индустриальный стандарт. На первом голосовании в ИСО, OOXML не смог получить достаточного числа голосов33 «ISO не принял Microsoft OOXML в качестве стандарта» // PC World, 04.11.2007. — [“ISO Rejects Microsoft's OOXML as Standard”, PC World, September 4th, 2007][3]. Возникло множество замечаний, указывающих на то, в каких аспектах OOXML зависит от операционной системы Windows. И только после целого ряда изменений, внесённых Microsoft в спецификацию, ISO согласилась признать его допустимым. Первой из таких уступок было введение «Строгого» (Strict) и «Переходного» (Transitional) классов соответствия. [3]: http://www.pcworld.com/article/136711/iso_rejects_microsofts_ooxml_as_standard.html "“ISO Rejects Microsoft's OOXML as Standard”, PC World, September 4th, 2007" По сути, для того чтобы добиться принятия спецификации в качестве международного стандарта ISO, Microsoft согласилась вынести части OOXML, которые были зависимыми от ОС Windows и могли бы успешно быть реализованы только самим Microsoft, в «Переходную» часть стандарта, использование которой должно было быть ограничено исключительно переводом старых документов Microsoft Office в новые. Было недвусмысленно заявлено, что эта «Переходная» часть спецификации не должна использоваться для создания новых документов. Прежде чем члены ISO могли быть в достаточной степени удовлетворены, «Строгий» класс соответствия должен был включить десятки улучшений. Учитывая те поправки и улучшения, которые были внесены вместе с возникновением «Строгого» класса соответствия, при втором голосовании OOXML был принят. Конечным результатом стало утверждение спецификации OOXML в марте 2008 года в качестве стандарта ИСО/МЭК (ISO/IEC 29500) и признание двух его разновидностей — «Строгой» и «Переходной». Брайан Джонс, менеджер проекта Office в Микрософт, прокомментировал значимость «Строгой» и «Переходной» версий следующим образом: > Наличие классов соответствия... используемых в связи с новой многочастной структурой стандарта, означает, что пользователи и документы, регламентирующие политику закупок, теперь могут явным образом обозначать требование того, чтобы программное обеспечение сохраняло документы с использованием «Строгого» класса соответсвия. Или же, другой пример, библиотечные учреждения, имеющие потребность в создании архивов, могут закупать программное обеспечение, поддерживающее как строгий, так и переходный классы44 «Протокол заседания собрания по разрешению конфликтов голосования ISO/IEC DIS-29500», Брайан Джонс, 16.03.2008 — [“Narrative of the ISO/IEC DIS-29500 BRM Meeting”][4], Brian Jones, 16 March 2008. [4]: http://blogs.msdn.com/b/brian_jones/archive/2008/03/15/narrative-of-the-iso-iec-dis-29500-brm-meeting.aspx В противоположность этому, движущей силой при создании ODF было желание достичь совместимости (интероперабельности) офисного ПО и предоставить пользователям право выбора программного обеспечения. > Данный стандарт определяет характеристики основанного на XML независимого от прикладного ПО и операционной системы файлового формата цифровых документов, а также характеристики того ПО, которое будет читать, создавать и обрабатывать такие документы.55 Спецификация OASIS ODF 1.2, Проект 05, Раздел 1.1 «Цели» — OASIS ODF 1.2, CD 05, Section 1.1 “Scope” Результаты соответствующим образом подтверждают значимость открытых стандартов, поскольку сегодня все основные приложения для создания документов пользователей\*\* В противоположность программному обеспечению для создания типографских макетов — *прим. перевод.* поддерживают стандарт ODF. Текущее состояние по реализации стандарта OOXML: неразбериха с разными версиями ------------------------------------------------------------------------------------------------------------------------------------ После нескольких лет с того момента, как OOXML был одобрен ИСО в качестве международного стандарта, формат всё ещё продолжает существовать в нескольких редакциях, ни одна из которых в точности не соответствует тому, что использует Microsoft в своих офисных программных продуктах. Рассмотрим данные варианты OOXML: * Версия OOXML, утверждённая ECMA (ECMA 376). Данная версия была отвергнута ISO. Она некоторым образом соответствует тому, что выдаёт на выходе Office 2007, однако не содержит определений скриптов, макросов, DRM, привязок к SharePoint и т.д. Данная версия содержит также множество зависимостей от платформы Windows. Использование ECMA-376, по существу, приковывает пользователей к продукту Microsoft Office. * «Строгая» (Strict) версия ISO/IEC 29500. Именно данная версия выдвигалась ISO для целей создания новых документов. Однако ни Office 2007, ни Office 2010 не могут записывать документы в «строгом» формате OOXML. Microsoft не давала никаких публичных обязательств относительно того, когда OOXML “Strict” будет полностью реализован. * «Переходная» (Transitional) версия ISO/IEC 29500. Вариант стандарта, который, по заявлениям ISO, не должен использоваться для новых документов. Ни Office 2007, ни Office 2010 не реализуют данную версию в точности. Более того, Office 2010 пишет документы с использованием нестандартной формы OOXML “Transitional”, которая включает много проприетарных расширений. Стандарт ISO не был дополнен данными расширеньями с использованием обычной процедуры стандартизации. Тот факт, что Microsoft, не реализуя «Строгую» версию стандарта, частным образом расширяет «Переходную» версию, означает, что те улучшения, которые позволили OOXML пройти стадию утверждения в ISO, на данный момент игнорируются. Данное расхождение стандарта ISO и реализации Microsoft вылилось в недавнее заявление Председателя собрания по разрешению конфликтов голосования (ballot resolution meeting) о том, что «Весь проект OOXML теперь несомненно движется к краху».66 Алекс Браун, «Microsoft не прошёл испытание на соответствие стандартам», 2010 — Alex Brown, [“Microsoft Fails the Standards Test”][6] (2010) [6]: http://www.adjb.net/post/Microsoft-Fails-the-Standards-Test.aspx Что из этого следует для госучреждений? --------------------------------------------------------------- Хотя не все организации, использующие открытые стандарты, одинаковы, в целом они стараются избегать зависимости от конкретного поставщика, снижать затраты, повышать совместимость (интероперабельность), расширять доступ общественности к официальным документам и обеспечивать их долговременное хранение. Некоторые, но не все, также явно озвучивают цель способстования развитию конкуренции и даже способствования использованию открытых стандартов. Не зависимо от того, к первой или второй области относятся цели того или иного госучреждения, до тех пор, пока со стороны Microsoft и других поставщиков ПО не будет полной поддержки «Строгой» версии OOXML (ISO/IEC 29500), госучреждения, полагающиеся на любые версии OOXML, могут расчитывать лишь на зависимость от конкретного проприетарного решения, которое не будет соответствовать их основным целям и запросам.