Журнал о системах электронного документооборота (СЭД)
Основы электронного документооборота

Бомба формата doc

  14 комментариев Добавить в закладки

Вам уже приходилось подписывать электронные документы? И как, не заметили ничего странного? Заметили? Именно об этом сейчас и пойдет речь!

Начнем немного издалека. Что мы подписываем, когда мы подписываем бумажный документ? Вопрос звучит странно, согласен, но ответ кажется довольно простым. Мы ставим подпись, как знак нашего согласия с содержанием документа. «Я такой-то такой-то, прошу предоставить мне отпуск с <Дата1> по <Дата2>». Все просто и понятно.

А что закрепляет наша подпись в электронном документе, кроме нашего желания отдохнуть с <Дата1> по <Дата2>? Ставя подпись под электронным документом, созданным, скажем, в популярном текстовом процессоре, мы своей подписью закрепляем, что <Дата2> записана шрифтом Courier New высотой 11 кеглей. This makes no sense, как сказали бы наши английские друзья, ибо будь эта дата написана шрифтом Times New Roman высотой 14 кеглей, отдыхать мы больше не станем. Иными словами, подписывая электронный документ, мы, желая того или нет, своей подписью закрепляем еще и его форму. Но это сущие пустяки, по сравнению с тем, о чем я поведаю дальше…

Не секрет, что большинство современных электронных документов имеют в своем арсенале не только элементы оформления, но и могут содержать некий код на достаточно мощном языке программирования, скажем, Visual Basic for Applications. Так вот, своими руками, имея под этими самыми руками только кажущийся таким безобидным Visual Basic, можно создать самодельную бомбу. Нет, офис она, конечно, не разнесет, а вот шуму наделать может немало. Как? Попытаюсь пояснить на маленьком примере.

Например, написали вы заявление на отпуск и отправили его своему непосредственному начальнику на утверждение. А заявление не простое, а в виде doc-файла, да не просто, а с макросом на Visual Basic. Желая понежиться подольше в лучах теплого летнего солнышка, вы полагаете, что отдохнуть с 10 июля по 10 августа, будет как раз то, что нужно. Доходит заявление до вашего босса, макрос определяет имя его машины, немного меняет текст заявления, и ваш начальник видит, что вы хотите отдохнуть с 10 по 15 июля, ибо больше вам совесть не позволяет. Шеф, радуясь, что под его началом трудится такой ответственный сотрудник, подписывает это заявление и посылает дальше по инстанции. Следующая инстанция получает документ уже с «реальным» сроком отпуска, протяженностью в один месяц, но, видя подпись вашего начальника, скорее всего,  не будет вникать в суть вопроса. Так оно дойдет и до бухгалтерии, где вас одарят щедрыми отпускными.

Скажете, такое невозможно? Меняя документ, макрос изменит и значение hash-функции, делая недействительной цифровую подпись. А если документ не будет сохраняться, просто макрос будет менять текст при открытии? Если ЭЦП не встроена в тело документа, а помещена в один контейнер с документом? Согласен, что в заявлении макрос вызовет подозрение, а как быть в случае с электронной формой, которая изначально содержит макросы, проверяющие корректность введенных данных? В любом случае это всего лишь умозрительный пример, показывающий, что электронный документ, это не только содержащаяся в нем «реальная» информация, но и служебная «электронная» информация (стили оформления, макросы и т.п.). Эта информация не несет для подписанта «экономического» смысла, но, тем не менее, также закрепляется его подписью. Получается, что, подписав электронный документ, мы берем на себя ответственность за все содержащиеся в нем макросы, а также за все их действия в настоящем и будущем? А оно … нам надо?

 

Ещё материалы автора
Похожие записи
Комментарии (14)
Наталья Храмцовская 18 июля 2007 г. 00:34  
Полезная статья. Об этой уязвимости при использовании ЭЦП известно уже несколько лет, но она упорно замалчивается - наверное, чтобы не пострадал миф о неуязвимости ЭЦП. Существуют и другие способы, позволяющие даже неопытному пользователю "обмануть" ЭЦП. В ряде европейских стран законодательство об ЭЦП уже предусматривает меры, направленные на защиту от этой угрозы.
Михаил Данилов 18 июля 2007 г. 08:14  
Насколько я понимаю, данный метод пройдет не с каждым - а только с тем, у кого установлен Низкий уровень безопасности в Word. И если у руководителя стоит хотябы Средний уровень, то ему выдадут предупреждение - запускать макрос или нет. У продвинутого руководителя, знающего что такое VBA, это как минимум вызовет подозрение. А если человека уличат в попытке жульничества, то ему придется не сладко...
Сергей Бушмелев 18 июля 2007 г. 08:30  

Согласен с Вами, Михаил. Данный пример скорее карикатура, чем пособие по надувателству своего босса. Я привел этот пример, чтоб показать, что современный электронный документ может обладать определенным поведением. Ставя ЭЦП под таким документом, трудно быть уверенным до конца в том, что:

1. Мы видим "настоящее" содержимое документа.

2. Следующий пользователь увидит то же самое, что и мы.

3. Документ в будущем не "выкинет какой-либо фокус".

Наталья Храмцовская 18 июля 2007 г. 08:38  
    Уважаемый Сергей, из Вашего комментария следует, что Вы даже сами не до конца понимаете, какой важный вопрос затронули. Поверьте, этот метот обмана прекрасно работает, и не только для форматов Microsoft Office, но и для PDF. Жаль, что Вы не обратили внимание упомянутые мной законодательные защитные меры - люди уже нарвались, и начали относиться к вопросу серьёзно.
    Уважаемый Михаил, о "продвинутом руководителе, знающем, что такое VBA" - это вы что, серьёзно?
Сергей Бушмелев 18 июля 2007 г. 08:48  

Да, Наталья, "ликбез" в области правового регулирования ЭЦП мне не помешает. Буду благодарен, если Вы укажете, законодательство каких стран уже содержит данные меры.

Наталья Храмцовская 18 июля 2007 г. 09:29  
В законодательстве Италии есть явный запрет на использование макросов и скрытого кода в документах. подписываемых ЭЦП. В некоторых других странах, таких, как Австрия, устанавливается, что с помощью ЭЦП могут подписываться только документы в форматах, одобренных  соответствующим УЦ.  Требование об отстуствии макросов и скрытого кода включено в европейский предстандарт CWA 14170 "Security requirements for signature creation applications".
Сергей Бушмелев 18 июля 2007 г. 09:34  

Наталья, огромное спасибо! Просто потрясен глубиной и широтой Ваших знаний!

Наталья Храмцовская 18 июля 2007 г. 09:59  
Владеющим английским языком рекомендую также посмотреть статью Audun Josang "What You See is Not Always What You Sign" http://sky.fit.qut.edu.au/~josang/papers/JPH2002-AUUG.pdf  - в первую очередь раздел 4.
Сергей Данилов 18 июля 2007 г. 11:09  
Эта проблема достаточно хорошо рассматривается в статье "Настал ли час электронной цифровой подписи?". В статье также рассматриваются способы решения проблемы.
Вкратце - вводятся понятия машиночитаемого и человекочитаемого представления документа. А как решение, например, предлагается создать и сертифицировать средства по переводу некоторых видов документов (форматов файлов) из машиночитаемого в человекочитаемый вид, которые в спорных ситуациях помогут установить правильную, юридически значимую трактовку документа.
Сергей Бушмелев 18 июля 2007 г. 12:41  

2 Сергей Данилов:

Думаю, что использование только сертифицированных программ оправдано в "специализированных" системах электронного документооборота, как в приведенном в статье примере с системами сдачи отчетности в электронном виде. Также данный подход применим к системам "банк-клиент", где клиенту передается ( и оплачивается им) специализированное ПО для обмена сообщениями с банком. Сертифицировать же "все и вся" кажется не только неразумным, но и технически неосуществимым.

Для "общих" целей, на мой взгляд, целесообразнее применять подход, упомянутый Натальей в ее топике о законодательных инициативах разных стран в этой области. Законодательно "спускается сверху" или устанавливается сторонами в договоре ограничение на использование определенных форматов и установка дополнительных требований к документам (отсутствие макросов и т.п.).

Сергей Данилов 19 июля 2007 г. 09:43  

Я несколько иное хотел сказать.

Документы по своей структуре, формату и правилам визуализации могут быть очень разными. Поэтому просто ограничить использование макросов и (расплывчатая формулировка) скрытого кода явно недостаточно. Взять, к примеру, способ подмены шрифтов из статьи указанной Натальей.

Нужны некоторые способы в спорных ситуациях определить "правильную" версию документа в человекочитаемом виде. Для этих целей предлагается создать ряд эталонных программ, которые всегда будут однозначно переводить текст из "машинного" в "человеческий" вид. Эти программы должны быть законодательно утверждены как эталонные и, как следствие, сертифицированы именно для этого. Программы в дальнейшем могут распространяться бесплатно.

О сертификации СЭД или обычных приложений-редакторов я не говорю.

В итоге, в большинстве случаев я работаю с привычными мне приложениями-редакторами, а в спорных случае или при работе с важными документами  использую программы-эталоны.

В качестве аналогии могу привести историю с БТИ (Бюро технической инвентаризации). Поступили жалобы на БТИ, что при измерении площадей земельных участков и жил. площадей полученные результаты сильно разнились с ожидаемыми результатами. Оказалось, что сотрудники БТИ бездумно использовали в своей работе купленную на рынке китайскую рулетку с очень большой погрешностью. В итоге, были повторены все замеры, но уже с хорошей рулеткой изготовленной по ГОСТу. Эту рулетка можно сравнить с эталонным приложением визуализации.

Сергей Бушмелев 19 июля 2007 г. 10:13  

Сергей, спасибо за приведенный пример!

Все же я вижу некоторые проблемы, которые могут встретиться при изготовлении "эталонных программ".

1. Формат, используемый "неэталонным" приложением, может быть закрытым.

2. В отличии от рулетки, программы постоянно обновляются, это зачастую приводит и к смене используемого формата.

3. Неизвестно, как к этой инициативе отнесутся производители ПО, если наряду с их "небесплатными" программами будут существовать еще и некие "эталонные" (считай, лучшие), да к тому же еще и бесплатные версии.

4. Возникает вопрос, на каком уровне сертифицировать такие "эталонные" программы - на национальном или международном, кто выступит в роли сертифицирующего органа?

5. Кто возьмется бесплатно изготовить такие "эталоны"?

6. The last but not the least: Такие программы будут бесполезны, если для обмана пользователей была изменена среда, а не сама программа отображения документа, как в случае со шрифтом из вышеупомянутой статьи.

Сергей Данилов 19 июля 2007 г. 12:37  
>1. Формат, используемый "неэталонным" приложением, может быть закрытым. Это не проблема для приложений созданных сторонними производителями и затем сертифицированных. Только в процессе сертификации очевидно придется приоткрыть формат. > 3. Неизвестно, как к этой инициативе отнесутся производители ПО, если наряду с их "небесплатными" программами будут существовать еще и некие "эталонные" (считай, лучшие), да к тому же еще и бесплатные версии. Производители будут стремиться сертифицировать свои продукты. Эталонные программы в любом случае будут более ограничены в функциональности, например, в них вряд ли будет реализовываться возможность редактирования документов >4. Возникает вопрос, на каком уровне сертифицировать такие "эталонные" программы - на национальном или международном, кто выступит в роли сертифицирующего органа? Для юридически значимого документооборота в России - на федеральном (национальном) >5. Кто возьмется бесплатно изготовить такие "эталоны"? Сложный вопрос :). Я думаю многие коммерческие производители ПО согласятся. Для некоторых форматов - должно проспонсировать государство >6. The last but not the least: Такие программы будут бесполезны, если для обмана пользователей была изменена среда, а не сама программа отображения документа, как в случае со шрифтом из вышеупомянутой статьи. Подобные технические сложности обязательно возникнут. Но они решаемы. В идеале, приложения должны быть полностью независимы от среды. Тот же рендеринг шрифтов должен быть реализован внутри программы визуализации. Вообще, напршивается один вывод. Будет очень удобно, если государство определило некий перечень форматов для юридически значимых электронных документов. И желательно чтобы эти форматы были открытыми.
Сергей Бушмелев 19 июля 2007 г. 13:07  

Еще пара слов по поводу форматов. Есть тенденция (или мода) использовать для государственных нужд (включая образование) открытое ПО и открытые форматы. Стоит ли считать началом тенденции признание властями штата Массачусетс изначально проприетарного (хотя и Microsoft пытается его и сертифицировать через ECMA) формата Microsoft Office Open XML - время покажет.

Законодатель может определить перечень открытых форматов для обмена между правительствиннеми организациями и для обращения к ним организаций и частных лиц. Устанавливать же подобные правила для всех - вопрос спорный. В принципе, бизнес всегда может установить любые правила в рамках договора

Сейчас обсуждают
Больше комментариев