Объектам ole object linking and embedding или activex в word относят укажите все верные ответы

OLE
-технология

OLE – технология
(Object Linking and Embedding – объектное
связывание и встраивание) позволяет
создавать сложные составные документы,
в которых содержатся разнотипные
объекты, созданные различными приложениями.
Так в текстовый документ редактора Word
можно вставить таблицу Excel, диаграмму,
поясняющую текст, или математическую
формулу, для пользователя это останется
единым документом. Приложение, отвечающее
за составной документ, принято называть
контейнером. Оно имеет сложную структуру,
так как умеет работать с “чужими”
объектами. Приложение, создавшее объект,
называется сервером.

Контейнеры и
серверы могут поддерживать два режима
взаимодействия:

• встраивание
  (внедрение) объектов. Этот режим означает,
  что данные объекта будут храниться
  вместе с основным документом (например,
  внедренная таблица Excel будет сохранена
  в .doc – файле редактора Word).

• связывание
  объектов. В составном документе хранится
  только ссылка на объект, данные которого
  находятся в другом документе.

При внедрении
увеличивается объем хранимых документов,
однако, их легче перемещать, тогда как
при связывании, необходимо помнить, что
изменение места расположения файлов
может привести к ошибочным ссылкам.

Для редактирования
связанных данных открывается отдельное
окно, того приложения, в котором эти
данные были созданы, т.е. сервера. При
внедрении объектов можно также запустить
сервер в отдельном окне, но можно и
редактировать данные «на месте» («in
Place»), т.е. в окне контейнера, если он это
позволяет. В этом случае контейнер
обязан иметь меню, а загрузившийся «in
Place»сервер дополнит его своими командами.

На странице System
палитры компонент в Borland Builder С++ есть
специальный компонент , предназначенный
для внедрения и связывания объектов из
других приложений — OLEContainer.

Основные свойства

Свойство State
позволяет определить состояние объекта
и его сервера. Его значения:

• osEmpty
  –контейнер не содержит объекта;

• osLoaded
  – объект в контейнере, сервер не
  выполняется;

• osRunning
  – сервер запущен;

• osOpen
  – OLE –объект открыт в отдельном окне
  сервера;

• osInPlaceActive
  – объект активизирован «на месте», но
  меню еще не изменено. Это промежуточное
  состояние объекта перед полной загрузкой
  сервера.

• osUIActive объект
  активизирован «на месте», меню изменено.

Следующий код
позволяет определить имя объекта,
загруженного в контейнер (свойство
AnsiString
OleClassName), способ работы с
объектом (Linked
= true – связывание, иначе –
внедрение), а также получить имя связанного
документа:

if
(OleContainer1 -> State != osEmpty)

{

Label2
-> Caption = OleContainer1 -> OleClassName;

//
Состояние контейнера – целое число,
начиная с 0 (osEmpty)

Label6
-> Caption = OleContainer1 -> State;

if
( OleContainer1 -> Linked)

Label4
-> Caption = OleContainer1 -> SourceDoc;

}

Свойство bool
AllowInPlace определяет возможность
редактировать внедренный объект «на
месте». Если AllowInPlace
= true и Iconic
= false (свойство Iconic
определяет должен ли объект быть
представлен в виде пиктограммы), то
«InPlace» – редактирование разрешено. При
AllowInPlace
= false сервер будет открываться
в отдельном окне.

Свойство AutoActivate
имеет три возможных значения: aaManual,
aaGetFocus,
aaDoubleClick
и определяет способы активизации
загруженного в контейнер объекта.

По умолчанию
AutoActivate
= aaDoubleClick, то есть объект
становится активным при двойном щелчке.
Значение aaGetFocus определяет активизацию
при получении фокуса ввода. При
AutoActivate
= aaManual за активизацию объекта
отвечает программист. В этом случае
можно использовать метод компонента-контейнера
DoVerb,
который отвечает за передачу команд от
контейнера серверу. Например, можно
воспользоваться следующим оператором:

OleContainer1->DoVerb
(ovShow); // Показать объект

Кроме посылки
команд серверу, методы контейнера
обеспечивают создание, загрузку и
разрушение объектов. Перейдем к их
рассмотрению.

Создание и сохранение нового объекта (внедрение)

Создание нового
объекта можно обеспечить использованием
специального диалогового окна Insert
Object (вставка объекта) или вызовом
метода CreateObject. В первом случае класс
объекта выбирает пользователь из
системного списка возможных объектов,
а во втором программно создается
конкретный объект.

Для использования
диалогового окна можно воспользоваться
следующим кодом, расположенным, например,
в команде меню «новый»:

AnsiString
File_Name; // переменная объявлена глобально
или в классе формы

…

if
(OleContainer1->InsertObjectDialog() )

{
File_Name = «»;

OleContainer1->DoVerb(ovShow);

}

В появившемся
диалоговом окне необходимо установить
значение RadioButton — кнопки
«Создать новый», в списке выбрать
необходимый тип объекта и щелкнуть
«OK».

Программно объект
можно создать так (операторы можно
вставить, например, в соответствующие
пункты меню):

• таблица
  Excel

OleContainer1->CreateObject(«Excel.sheet»,false);

• документ
  Word

OleContainer1->CreateObject(«Word.Document»,false);

Если создать нужно
объект, имя типа которого неизвестно,
то нужно обратиться либо к соответствующей
документации по серверу, либо написать
тестовую программу с загрузкой объекта
методом OleContainer->InsertObjectDialog() и
воспользоваться свойством OleContainer
-> OleClassName для определения его имени.

При создании нового
объекта используется внедрение (так
как для связывания необходим файл). В
этом случае за хранение данных объекта
отвечает программа — контейнер. Сохранить
данные в файле можно с помощью метода
SaveToFile (<имя
файла>), например, в пункте меню
«Файл — Сохранить…» можно использовать
следующий код:

void
__fastcall TForm1::FSaveClick(TObject *Sender)

{
if (File_Name==»»)

if
( SaveDialog1->Execute() )

File_Name
= SaveDialog1->FileName;

else
return;

OleContainer1->SaveToFile(ChangeFileExt(File_Name,».ole»));

}

В данном примере
расширение файла .ole указывает на то,
что объект будет сохранен в специальном
формате отличном от формата сервера.
Приложение — сервер отдельно от контейнера
прочесть эти данные не сможет.

Функция ChangeFileExt
была использована в примере для замены
расширения файла. При выполнении команд
сохранения и извлечения данных из файла
могут понадобиться и другие функции
обработки имен файлов:

• ChangeFileExt(const
  AnsiString FileName, const AnsiString Extension) –
  принудительно изменяет имя файла
  FileName, заменяя расширение на Extension;

• функция
  AnsiString
  ExtractFileExt(AnsiString
  FileName)
  возвращает расширение файла и,
  следовательно, позволяет проверить
  его тип;

• AnsiString
  ExtractFileName(AnsiString
  FileName) возвращает имя файла, извлеченное
  из строки FileName,
  т.е. после последнего обратного слэша
  или двоеточия;

• AnsiString
  ExtractFilePath(AnsiString
  FileName) извлекает путь к файлу, включая
  последний слэш или двоеточие;

• AnsiString
  ExtractFileDrive(AnsiString
  FileName) извлекает диск файла с
  двоеточием (например, «D:»).

Метод контейнера
LoadFromFile(<имя
файла>) позволяет загрузить
запомненный объект в контейнер:

void
__fastcall TForm1::FOpenClick(TObject *Sender)

{

if
( OpenDialog1->Execute() )

{

if
(ExtractFileExt(OpenDialog1->FileName)!= «.ole»)

return;

File_Name
= OpenDialog1->FileName;

OleContainer1->LoadFromFile(File_Name);

OleContainer1->DoVerb(ovShow);

}

}

Время на прочтение
16 мин

Количество просмотров 8.7K

Изначально архитектура Microsoft Office строилась на основе концепции составных документов, они же документы OLE, активно продвигаемой Microsoft на заре 32-разрядных Windows. В те времена идея «бесшовного» объединения в одном документе данных самых разных форматов казалась заманчивой и увлекательной, и до выявления первых проблем успела прочно врасти во многие масштабные продукты.

«Плохая новость» заключалась в том, что универсальный способ добавления в документы данных (и кода обработки этих данных) стал универсальным путем появления в продукте уязвимостей, который и сегодня постоянно преподносит

приятные

сюрпризы

создателям malware

исследователям безопасности.

Впоследствии приложения пакета получили довольно богатый набор инструментов для добавления в документы изображений, графиков и схем, управляющих элементов, которые создаются и обрабатываются самим приложением и являются его частью. С точки зрения безопасности эти элементы представляют несколько меньший интерес, чем элементы, о которых (в основном) пойдет речь в статье — элементы, использующие код внешних приложений, добавляемые в документы при помощи OLE.

«Дисковым» представлением составного документа является CFBF файл. В этой статье будет рассмотрено встраивание объектов в документы Microsoft Office (а точнее, только аспект безопасности) в контексте данных и кода, загруженных в память во время исполнения.

Формально встраиваемые в документы Microsoft Office объекты можно разделить на следующие группы:

• Управляющие элементы ActiveX (ActiveX Controls)
• Внедренные элементы данных OLE (OLE Embedded Objects)
• Внедряемые файлы (Packages)
• Встроенные элементы не-OLE

Управляющие элементы ActiveX

Элементы управления ActiveX можно представить как элементы окна программы — скажем, кнопки, переключатели, списки, поля ввода и другие формы — призванные производить некоторые события либо на события отвечать. Когда-то хорошей идеей казалось создавать подобные управляющие элементы универсальными, с возможностью использования в любом приложении, и помещать их с этой целью в компоненты COM.

Встраиваемые в вебстраницы ActiveX представляли известную брешь в безопасности Internet Explorer, меры безопасности со временем усиливались. Браузеры других производителей практически сразу отказались от поддержки ActiveX. Новый браузер Microsoft Edge окончательно расстался с этим пережитком прошлого. Встраивание в документы Office, однако, все еще возможно.

ActiveX в документах предназначены для использования в связке с Visual Basic for Applications. Тем не менее, для их загрузки и активации VBA не требуется, а для загрузки элементов из «белого списка» не требуется и разрешение пользователя.

Уязвимости в последних особенно опасны — настройки по умолчанию, задаваемые при установке приложения, не предполагают ни какой-либо защиты от загрузки этих элементов, ни предупреждения пользователя. Администратору необходимо принудительно ужесточить настройки, запретив загрузку любых элементов ActiveX (отметим однако, что в режиме безопасного просмотра ActiveX не загружаются).

Пример: CVE-2012-0158

Одной из самых опасных уязвимостей в документах Office в 2012 году была CVE-2012-0158. Код загрузки элемента Microsoft ListView Control 6.0 из библиотеки MSCOMCTL.OCX содержал возможность переполнения буфера, что позволяло подменить адрес возврата и выполнить произвольный код. Поскольку элемент находился в «белом списке» ActiveX, загрузка начиналась сразу же при открытии документа. На текущий момент уязвимость устранена, элемент ListView Control по-прежнему считается «безопасным».

Добавление ActiveX в документ

Для добавления управляющего элемента в документ Microsoft Office (для простоты возьмем Word) при помощи интерфейса пользователя необходимо открыть вкладку «Разработчик» (ее видимость настраивается в меню «Параметры Word») и выбрать Элементы управления -> Инструменты из предыдущих версий -> элементы ActiveX. Меню продемонстрирует набор значков, соответствующих элементам Microsoft Forms, а также возможность выбрать ActiveX из списка, составленного из имеющихся в системе элементов, отобранных по ряду критериев.

Выведенный список не соответствует набору элементов, которые действительно могут быть загружены в документ, поэтому на него нельзя ориентироваться при поиске уязвимых элементов. Сложная многоуровневая проверка загружаемых ActiveX имеет несколько этапов, различается для версий Office и меняется от обновления к обновлению, так что наиболее верный способ проверить возможность загрузки — «вручную» скомпоновать файл документа с интересующим элементом и попытаться открыть его в Office. Возможные форматы документов описаны ниже.

Программное представление

Каждый элемент ActiveX по сути является объектом одного из классов COM, отвечающих определенным требованиям. Загрузка элемента происходит при помощи подсистемы COM, а исполняемый код содержится в одном из модулей, как правило, «внешних» по отношению к приложению-контейнеру. Как и любой COM-объект, элемент ActiveX может быть реализован в виде библиотеки DLL, или же в виде исполняемого EXE-файла. В первом случае библиотека будет загружена в адресное пространство контейнера, во втором — элемент будет обрабатываться в отдельном процессе, с передачей данных между контейнером и объектом посредством COM-маршалинга.

Как и любой объект COM, ActiveX имеет Интерфейсы, Свойства и Методы.

Интерфейсы — это прежде всего набор стандартных интерфейсов, которые обязан иметь класс ActiveX для полноценной загрузки и взаимодействия с контейнером, в частности, IOleControl и IOleObject.

Отсутствие каких-то необходимых интерфейсов может урезать функциональность элемента или прервать его загрузку на каком-то этапе.

Пример: CVE-2015-2424
Уязвимость CVE-2015-2424 была связана с элементом TaskSymbol Class из библиотеки mmcndmgr.dll. Элемент не был предназначен для использования в документах, и не экспортировал интерфейс IDispatch. В процессе загрузки элемента запросившая этот интерфейс процедура получала ошибку и разрушала внутреннюю структуру элемента, что приводило к уязвимости типа use-after-free. На данный момент элемент запрещен к загрузке (несмотря на это, его все еще можно обнаружить в списке для добавления в меню «Разработчик»). Сама уязвимость не устранена.

Помимо стандартных, каждый класс ActiveX экпортирует «основной» интерфейс, представляющий его собственную уникальную функциональность. К примеру, для класса Forms.CommandButton.1 это ICommandButton.

Просматривать интерфейсы ActiveX можно при помощи инструмента OleView, входящего в пакет Microsoft Visual Studio.

Интерфейс элемента определяет его Методы и Свойства. Свойства представляют некоторые данные, определяющие вид и работу элемента. Разработчик ActiveX-элемента присваивает каждому свойству определенное имя, скажем BackColor или GridLineWidth, и тип, например, строка, целое или вещественное двойной точности. Для растровых изображений и значков существует такой тип свойства, как картинка. Клиентская программа может устанавливать отдельные свойства элемента управления, задавая их целочисленные индексы и значения.

С точки зрения низкоуровневой реализации деление на методы и свойства формальное, поскольку «свойства» представлены набором методов get/set. Однако есть и значимое отличие: Методы элемента (его основного интерфейса) могут быть вызваны только программно, в случае документов Office — только из выполняющейся программы VBA. С точки зрения безопасности это не представляет большого интереса, так как исполнение VBA это уже компрометация операционной системы. Свойства же сохраняются в документе и при его открытии будут обработаны и загружены в структуры в памяти даже если исполнение VBA запрещено.

С программной точки зрения, со стороны элемента для сохранения его свойств и состояния в документе контейнер предоставляет интерфейсы IStream, IStorage и IPropertyBag. Их реализация и представление данных в дисковом файле уже не забота элемента ActiveX, и целиком зависит от контейнера и формата документа. Нужно заметить, что набор и формат сохраняемых данных может соответствовать «публично» экспортируемому набору свойств, а может быть и совершенно иным. Рассмотрим примеры реализации, имеющие отношение к Microsoft Office.

Составной файл (compound file, CFBF)

Устаревший формат документов Office, где для хранения данных ActiveX выделялось хранилище нижнего уровня ObjectPool и отдельные подкаталоги внутри него. Поток «01CompObj» содержит идентификатор класса, который в конечном итоге и определяет класс загружаемого объекта. Замена идентификатора непосредственно в hex приведет к попытке загрузки объекта совсем другого класса.

Office Open XML

Современный XML формат документов. Файл представляет собой zip-архив. Данные элементов ActiveX хранятся в подкаталоге ActiveX в файлах с немудреными названиями типа activeX1.xml.

Пример файла:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ax:ocx ax:classid="{D7053240-CE69-11CD-A777-00DD01143C57}" ax:persistence="persistPropertyBag" xmlns:ax="http://schemas.microsoft.com/office/2006/activeX" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships">
<ax:ocxPr ax:name="Caption" ax:value="CommandButton1"/>
<ax:ocxPr ax:name="Size" ax:value="2540;847"/>
<ax:ocxPr ax:name="FontName" ax:value="Calibri"/>
<ax:ocxPr ax:name="FontHeight" ax:value="225"/>
<ax:ocxPr ax:name="FontCharSet" ax:value="204"/>
<ax:ocxPr ax:name="FontPitchAndFamily" ax:value="2"/>
<ax:ocxPr ax:name="ParagraphAlign" ax:value="3"/>
</ax:ocx>

В этих файлах в текстовой форме указаны идентификаторы классов. Замена идентификатора также вызовет попытку загрузки элемента другого класса.

Далее файл содержит указание на тип хранения данных объекта: persistPropertyBag, persistStorage или persistStream. Если элемент поддерживает хранение свойств persistPropertyBag, его данные могут быть сохранены в том же текстовом файле, см. пример выше. Если же ему необходимо хранилище или двоичный поток, данные будут сохранены в файле с именем типа activeX1.bin, представляющем собой файл CFBF.

RTF

В документе rtf элемент ActiveX определяется тэгами objectobjocx. Тэг objdata содержит хранилище свойств элемента в виде hex-представления файла CFBF.

{objectobjocxf37objsetsizeobjw1440objh480{*objclass Forms.CommandButton.1}
{*objdata 010500000200000016000000
466f726d732e436f6d6d616e64427574746f6e2e31000000000000000000000e0000
d0cf11e0a1b11ae1000000000000000000000000000000003e000300feff090006

Загрузка из файла

Процесс загрузки ActiveX из документа в целом достаточно прост. Приложение-контейнер создает чистый объект указанного класса, запрашивает у него указанный интерфейс хранения, и предоставляет указатель на хранилище, поток или «пакет свойств».

Фильтрация элементов, которые могут быть загружены, имеет множество этапов. Прежде всего отсеиваются классы, указанные в черном списке, известном как Office COM Kill Bit (подветка реестра *OFFICE_KEY*CommonCOM Compatibility). К примеру, флаги, предотвращающие загрузку, имеют такие классы как Microsoft Scriptlet Component и Microsoft Web Browser.

Остальные классы пройдут первоначальную загрузку. Это означает, что библиотека DLL будет загружена в приложение-контейнер, или же будет запущен процесс COM-сервера, реализованного в EXE-файле. Только после этого будут выполняться остальные проверки, включая элементарную — а является ли объект, собственно, представителем ActiveX.

Пример: CVE-2015-6128
В 2015 году исследователь обнаружил, что предварительную загрузку модулей COM можно использовать для обхода ASLR и выполнения произвольного кода за счет загрузки подложных динамических библиотек. В описании вышедшего впоследствии CVE-2015-6128 нет ни слова о Microsoft Office.

Если идентификатор действительно определяет ActiveX, он пройдет еще несколько проверок в нескольких черно-белых списках.

Можно видеть, что значительное место в списке занимают компоненты группы Microsoft Forms. Это набор управляющих элементов, поставляемых с пакетом Office, вы можете видеть их на панели «элементы ActiveX». Изначально все они регистрировались как «безопасные», но со временем выяснилось, что для отдельных элементов это не так. К примеру, элемент Frame загружает любые другие ActiveX, не проверяя никаких списков (в последних версиях это «исправлено», но собственный блэклист Frame отличается от общего Office). По этой причине часть элементов Microsoft Forms может быть загружена в документ только с разрешения пользователя. Microsoft Forms Frame также требует согласия пользователя (при настройках по умолчанию), зато позволяет загрузить некоторые элементы из Kill Bit списка, которые не могли бы быть загружены при других условиях.

Следовательно, если атакующему удается убедить пользователя разрешить загрузку ActiveX, Frame поможет ему существенно расширить «арсенал» за счет таких элементов как, например Web Browser.

Формат хранения свойств Microsoft Forms частично документирован спецификацией [MS-OFORMS].

В процессе сканирования ActiveX выяснилось, что набор классов для doc, docx и rtf разный, также разные списки доступных ActiveX для приложения, запущенного обычным образом и запущенного в режиме автоматизации.

Многие популярные приложения дополняют эти списки собственными ActiveX. В случае обнаружения уязвимости она будет отражена в бюллетене как имеющая отношение к приложению в состав которого входит. При этом единственным путем эксплуатации уязвимости могут оказаться документы Office.

Пример: Flash ActiveX
Flash ActiveX особенно полюбился вирусописателям за стабильно обнаруживаемые уязвимости и постоянное место в «белых списках» IE и Office. Первые известные уязвимости в этом компоненте появились еще в 2008 году, одна из последних CVE-2018-4878 закрыта в феврале этого года. С угасанием популярности IE документы Office стали основным путем распространения эксплойтов для Flash.

Внедряемые элементы данных OLE

Внедряемые элементы OLE призваны реализовать концепцию «документа в документе» с возможность редактирования «на месте» данных различных форматов, обрабатываемых другими приложениями. Подобно ActiveX, OLE-документы реализованы на основе COM.

Добавить OLE-элемент в документ Word можно следующим образом: открыть вкладку «Вставка» и выбрать Текст -> Объект. Программа выведет список типов документов, для которых зарегистрированы OLE-обработчики. Как и в случае с ActiveX, этот список мало соответствует набору классов, которые действительно могут быть загружены в качестве документов OLE.

Программное представление

Как и в случае ActiveX реализация любого OLE-документа представлена соответствующим классом COM, выполненным в виде DLL или EXE. Компонент экспортирует необходимые служебные интерфейсы, а сохранение состояния в документе-контейнере выполняется посредством интерфейсов IPersist*.

В документе формата CFBF данные объектов OLE сохраняются в хранилище второго уровня ObjectPool. Набор потоков в целом похож на соответствующий элементам ActiveX.

В документах Open Office XML данные объекта OLE сохраняются в подкаталоге embeddings, в файле-хранилище CFBF с именем типа oleObject1.bin.

В документах RTF информация об объекте сохраняется под тэгом objectobjemb. Раздел содержит также хранилище, закодированное как hex-представление файла CFBF.

{objectobjembobjw8307objh553{*objclass WordPad.Document.1}
{*objdata 010500000200000013000000576f72645061642e446f63756d656e742e31000000000000000000000a0000
d0cf11e0a1b11ae100000000


Формат RTF выделяется тем, что поддерживает тэг objupdate, вызывающий автоматическую активацию элемента в то время как по умолчанию OLE-элементы неактивны при загрузке.

Пример: CVE-2017-11882
Уязвимость CVE-2017-11882 OLE компонента Equation Editor благодаря обработке объекта в отдельном процессе давала возможность стабильной и универсальной эксплуатации. Тэг objupdate заставлял Word загружать уязвимый компонент сразу при открытии документа.

Пример: встроенные элементы Excel с макровирусом
Исследователями обнаружены вредоносные rtf-документы, не использующие никаких новых уязвимостей. Документы содержат в качестве встроенных объектов несколько документов Excel с макросом. Расчет сделан на то, что пользователь, вынужденный после открытия документа несколько раз подряд отказываться от выполнения макроса, в итоге «сдастся» и разрешит выполнение. На данный момент техника все еще работает.

Значительное отличие от ActiveX в случае внедряемых элементов OLE состоит в том, что идентификатор класса записывается непосредственно в файл хранилища функцией WriteClassStg. Эта методика унаследована из очень давних времен, когда в Microsoft увлеченно развивали концепцию «сериализации» и хранения объектов с их состоянием в формате CFBF. Документ-контейнер также сохраняет идентификатор класса внедряемого элемента, но загружен будет объект именно того класса, который указан в хранилище. Этот идентификатор возможно заменить, заставив приложение загрузить объект вовсе не предназначенный для этих целей.
Возможно отредактировать и данные элемента, что в определенных случаях приводит к выявлению уязвимостей.

Объекты OLE также проходят многочисленные проверки на возможность загрузки, что затрудняет получение полного списка потенциально загружаемых элементов. Набор элементов, которые могут быть загружены как объекты OLE, отличается от списка загружаемых ActiveX. В частности, проверку они проходят по KillBit списку принадлежащему не Office, а Internet Explorer (HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerActiveX Compatibility).

OLE по ссылке

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

Пример: CVE-2017-0199
Уязвимость CVE-2017-0199 заключалась в возможности добавления в документ «объекта по ссылке» формата hta. Последний представляет собой html с возможностью выполнения кода, то есть, фактически является исполняемым файлом. Обработчик автоматически скачивал и выполнял hta, позволяя выполнить произвольный код при открытии документа.

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

Внедряемые файлы (Packages)

Документы Office поддерживают возможность добавления любого файла (Объект -> Создание из файла или просто перетащить иконку файла в поле редактирования). Технически это реализовано добавлением в документ встраиваемого элемента Object Packager, записывающего в собственные данные желаемый файл. Object Packager позволяет заменить иконку и подпись файла, а также задать командную строку для открытия. Может он включать и файлы «по ссылке», когда открытие файла происходит не из собственного хранилища, а по указанному пути, в том числе и сетевому.

В последнее время функциональность Object Packager была значительно подрезана, а изначально элемент мог сохранять любые файлы, в том числе исполняемые, ссылки, и даже командную строку. Все, что нужно было сделать пользователю для запуска содержимого — дважды кликнуть иконку в тексте документа.

Пример: файлы в теле сообщения Outlook
Сообщения Outlook, которые также являются составными документами, позволяют добавлять элементы Object Packager в тело письма. Для пользователя элемент выглядит как изображение, произвольно выбранное злоумышленником. Двойной клик по изображению открывает упакованный файл. Злоумышленнику остается подобрать тип данных из тех, что еще не попали под ужесточение политик безопасности.

Встроенные элементы, реализованные не с помощью OLE

На данный момент наибольшую угрозу/интерес из не-OLE элементов могут представлять изображения, добавляемые в документ по ссылке. При открытии документа не в защищенном режиме изображения скачиваются автоматически, что может приводить к раскрытию местоположения и личности пользователя, скачавшего документ через анонимизирующие прокси или получившего конфиденциальный документ из третьих рук. Эта методика, в частности, была реализована в инструменте Scribbles, находящемся на вооружении спецслужб США.
В локальной сети Windows автоматическое скачивание изображений по ссылке делает возможной эксплуатацию уязвимости NTLMRelay. Механизм ссылок на картинки не совместим с требованиями безопасности сетей ActiveDirectory, поскольку администратор, получающий подобный документ по сути исполняет код злоумышленника с полными административными привилегиями.

Методы защиты

Что можно сделать? В целом, немного.

Наиболее действенный на сегодняшний момент метод защиты от уязвимостей во встроенных в документы Office объектах — режим защищенного просмотра. В этом режиме исключается как загрузка объектов, так и загрузка данных из внешних источников. К сожалению, для перехода в полнофункциональный режим требуются элементарные действия пользователя, с легкостью провоцируемые методами социальной инженерии.

Управляющие элементы ActiveX можно отключить в настройках Trust Center

Обратите внимание, что для встроенных элементов OLE это не работает.

Технология, разработанная Microsoft

Связывание и внедрение объектов (OLE ) — это собственная технология, разработанная Microsoft, которая позволяет встраивать и связывать с документами и другими объектами. Для разработчиков он предоставил OLE Control Extension (OCX), способ разработки и использования настраиваемых элементов пользовательского интерфейса. На техническом уровне объект OLE — это любой объект, реализующий интерфейс IOleObject, возможно, вместе с широким спектром других интерфейсов, в зависимости от потребностей объекта.

Содержание

• 1 Обзор
• 2 История
  • 2.1 OLE 1.0
  • 2.2 OLE 2.0
  • 2.3 Пользовательские элементы управления OLE
• 3 Технические детали
  • 3.1 Объект OLE
  • 3.2 OLE контейнер
  • 3.3 Другое
• 4 Конкурс
• 5 Взаимодействие
• 6 См. также
• 7 Ссылки
• 8 Внешние ссылки

Обзор

OLE позволяет редактировать приложение для экспорта часть документа в другое приложение для редактирования , а затем импортировать ее с дополнительным содержимым. Например, система настольных издательских систем может отправить текст в текстовый процессор или изображение в OLE. Основным преимуществом OLE является добавление в документ различных типов данных из разных приложений, таких как текстовый редактор и редактор изображений. Это создает документ составного файла в двоичном формате и главный файл, на который имеется ссылка в документе. Изменения данных в главном файле немедленно влияют на документ, который на него ссылается. Это называется «связывание» (вместо «встраивания»).

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

История

OLE 1.0

OLE 1.0, выпущенная в 1990 году, была развитием исходной концепции динамического обмена данными (DDE), которая Microsoft разработан для более ранних версий Windows. В то время как DDE был ограничен передачей ограниченных объемов данных между двумя запущенными приложениями, OLE могла поддерживать активные связи между двумя документами или даже встраивать один тип документа в другой.

Серверы и клиенты OLE взаимодействуют с системными библиотеками с помощью таблиц виртуальных функций или VTBL. VTBL состоит из структуры указателей функций, которые системная библиотека может использовать для связи с сервером или клиентом. Серверная и клиентская библиотеки, OLESVR.DLLи OLECLI.DLL, изначально были разработаны для связи между собой с помощью сообщения WM_DDE_EXECUTE.

OLE 1.0 позже превратился в архитектуру для программных компонентов, известную как Component Object Model (COM), а позже DCOM.

Когда Объект OLE помещается в буфер обмена или внедряется в документ, сохраняется как визуальное представление в собственных форматах Windows (например, bitmap или метафайл ), так и лежащие в основе данные в собственном формате. Это позволяет приложениям отображать объект без загрузки приложения, использованного для создания объекта, а также позволяет редактировать объект, если соответствующее приложение установлено.

Object Packager, компонент OLE, поставляемый с Windows 3.1 до Windows XP, позволяет «объекту, не относящемуся к OLE» быть » упакован », чтобы его можно было встроить в OLE-клиент.

OLE 2.0

OLE 2.0 был следующим этапом эволюции OLE, преследуя те же цели, что и версия 1.0, но был повторно реализован поверх COM вместо прямого использования VTBL. Новыми функциями были автоматизация OLE, перетаскивание и структурированное хранилище. Моникеры произошли от имен объектов OLE 1 и предоставили иерархическую систему именования объектов и ресурсов, аналогичную URL-адресам или URI, которые были изобретены независимо. Теперь Windows объединила две технологии, поддерживающие тип URL Moniker и схему URL Moniker.

Пользовательские элементы управления OLE

Пользовательские элементы управления OLE были представлены в 1994 году как замена устаревшим элементам управления Visual Basic Extension. Вместо их обновления новая архитектура была основана на OLE. В частности, любой контейнер, поддерживающий OLE 2.0, уже может встраивать настраиваемые элементы управления OLE, хотя эти элементы управления не могут реагировать на события, если контейнер не поддерживает это. Пользовательские элементы управления OLE обычно поставляются в виде библиотеки динамической компоновки с расширением.ocx. В 1996 году все интерфейсы для элементов управления (кроме IUnknown) стали необязательными, чтобы уменьшить размер файлов элементов управления, чтобы они загружались быстрее; затем они были названы Элементы управления ActiveX.

Технические детали

Объекты и контейнеры OLE реализованы поверх модели компонентных объектов ; это объекты, которые могут реализовывать интерфейсы для экспорта своей функциональности. Обязательным является только интерфейс IOleObject, но могут потребоваться и другие интерфейсы, если требуется функциональность, экспортируемая этими интерфейсами.

Чтобы облегчить понимание того, что следует, необходимо пояснить некоторую терминологию. Статус просмотра объекта — это то, является ли объект прозрачным, непрозрачным или непрозрачным со сплошным фоном, а также поддерживает ли он рисование с указанным аспектом. Местом расположения объекта является объект, представляющий расположение объекта в его контейнере. Контейнер поддерживает объект сайта для каждого содержащегося объекта.

Далее следует список интерфейсов, сгруппированных по объектам, которые обычно нуждаются в их реализации. Интерфейсы, обычно реализуемые объектом OLE, обычно вызываются контейнером OLE, и наоборот. Обратите внимание, что отступ в следующем списке указывает на наследование интерфейса. Все интерфейсы без отступа являются производными от IUnknown.

OLE-объекта

DataObject

При реализации позволяет передавать данные и уведомлять об изменениях данных. Он должен быть реализован объектами, которые должны поддерживать перетаскивание, копироваться или вставляться из буфера обмена, или быть связаны или встроены в содержащий документ.

ObjectWithSite

Позволяет вызывающий, чтобы сообщить объекту OLE о своем сайте. Эта функция также обеспечивается OleObject, но ObjectWithSite может использоваться, если поддерживается, если OleObject не используется для других целей.

OleCache

Позволяет кэшировать визуальные презентации из DataObject . Это позволяет встроенному объекту сохранять свое визуальное представление, таким образом, позволяя отображать его позже без необходимости запуска приложения, которое использовалось для создания объекта.

Обычно используется стандартная реализация.

OleCache2

Обеспечивает более детальный контроль над кешированием.

Обычно используется стандартная реализация.

OleCacheControl

Этот интерфейс не вызывается контейнером, но внутри объекта, чтобы позволить ему получать уведомления о том, когда его DataObject работает, тем самым позволяя ему подписаться на уведомления об изменении данных этого объекта и, таким образом, позволяя ему обновлять кешированное представление

Обычно используется стандартная реализация.

OleDocument

Позволяет объекту OLE поддерживать несколько представлений своих данных, а также несколько связанных функций.

OleDocumentView

Объект документа (объект, реализующий OleDocument ) реализует этот интерфейс для каждого представления. Он позволяет вызывающему абоненту установить местоположение объекта, запросить и установить размер объекта, а также показать и активировать его, а также некоторые связанные функции.

OleWindow

OleInPlaceActiveObject

Вызывается внешним контейнером объекта для взаимодействия с ним, пока он активен, например для обработки клавиш-ускорителей в очереди сообщений контейнера, которые предназначены для содержащегося в нем объекта.

OleInPlaceObject

Вызывается контейнером для активации или деактивации объекта.

IOleInPlaceObjectWindowless

Объект без окон — это объект, который не имеет собственного окна, но вместо этого отображается в окне своего контейнера. Он используется контейнером для ретрансляции сообщений, полученных окном контейнера, которые предназначены для содержащегося в нем объекта. Например, если мышь перемещается по окну, Windows помещает сообщение о перемещении мыши вместе с координатами мыши в очередь сообщений окна. Если это окно содержит внедренные объекты без окон, сообщение может быть передано такому объекту, если координаты указателя мыши находятся над этим объектом. По тем же причинам этот интерфейс также предоставляет доступ к интерфейсу объекта DropTarget.

OleLink

Позволяет объекту поддерживать связывание, например позволяя контейнеру устанавливать источник связанного объекта.

Обычно используется стандартная реализация.

OleObject

Возможно, наиболее важный интерфейс для объекта OLE. Например, он позволяет контейнеру информировать объект о своем сайте, инициализировать объект на основе данных, открывать и закрывать его, запрашивать и устанавливать размер объекта, запрашивать уведомления на AdviseSink <91 контейнера.>и выполнять объекты, определенные как «глаголы» на объекте. Эти глаголы часто включают «Открыть» или «Изменить», но могут также включать и другие глаголы. Один из глаголов определяется как главный глагол, и он выполняется, когда пользователь дважды щелкает объект.

ViewObject

Позволяет объекту рисовать себя напрямую, без передачи DataObject в контейнер. Для объектов, которые поддерживают и DataObject, и этот интерфейс, обычно используется общая реализация базовой реализации.

ViewObject2

Дополнительно позволяет вызывающей стороне запрашивать размер объекта.

ViewObjectEx

Добавляет поддержку рисования прозрачных объектов без мерцания, проверки попадания для объектов неправильной формы и установки размера объекта.

OLE container

IAdviseSink

Позволяет разработчику получать уведомления при сохранении, закрытии или переименовании объекта, а также при изменении его данных или визуального представления.

IAdviseSink2

Дополнительно позволяет разработчику получать уведомления при изменении источника ссылки объекта OLE.

IAdviseSinkEx

Дополнительно позволяет разработчику получать уведомления при изменении статуса просмотра объекта OLE.

IOleClientSite

Этот интерфейс позволяет вызывающему абоненту получать информацию о контейнере и местоположении объекта, а также запрашивать сохранение, изменение размера, отображение объекта, скрытый и т. д.

IOleDocumentSite

Позволяет вызывающему абоненту немедленно запросить активацию объекта на этом сайте. Если этот интерфейс реализован, также должны быть реализованы IOleClientSite, IOleInPlaceSite и IAdviseSink .

IOleContainer

Этот интерфейс позволяет вызывающей стороне перечислять встроенные объекты в контейнере или находить такие объекты по имени. Это в первую очередь полезно, если контейнер хочет поддерживать ссылки на встроенные объекты.

IOleWindow

IOleInPlaceUIWindow

Позволяет встроенным объектам согласовывать пространство для панелей инструментов в окне контейнера.

IOleInPlaceFrame

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

IOleInPlaceSite

Если контейнер реализует этот интерфейс, он позволяет активировать встроенные объекты на месте, т. е. без открытия в отдельном окне. Он обеспечивает доступ к IOleInPlaceUIWindow.

IOleInPlaceSiteEx

контейнера. Если контейнер реализует этот интерфейс, он позволяет встроенным объектам проверять, нужно ли им перерисовывать при активации или деактивации. Это также позволяет им запрашивать активацию пользовательского интерфейса.

IOleInPlaceSiteWindowless

Если контейнер желает поддерживать внедренные объекты без окон, он должен предоставить функциональность встроенным объектам, чтобы заменить функциональность, обычно предоставляемую окном внедренного объекта. Например, этот интерфейс предоставляет способ доступа к контексту устройства окна контейнера, тем самым позволяя встроенному объекту рисовать в окне контейнера.

IOleUILinkContainer

Содержит методы, которые стандартные диалоговые окна OLE, управляющие связанными объектами используйте для обновления связанных объектов в контейнере или для запроса и изменения их источников. Используется диалоговыми окнами «Ссылки», «Изменить источник», «Обновить ссылки» и «Свойства объекта».

IOleUILinkInfo

Дополнительно позволяет диалоговым окнам запрашивать, когда в последний раз обновлялись связанные объекты, и было ли это сделано автоматически или вручную.

IOleUIObjInfo

Содержит методы, необходимые для диалогового окна «Свойства объекта». Например, если пользователь открывает диалоговое окно «Свойства объекта» и просит преобразовать объект в другой тип, вызывается метод в этом интерфейсе.

IOleUndoManager

Предоставляет централизованную службу отмены для обоих сам контейнер и встроенные объекты. Когда выполняется отменяемое действие, создается IOleUndoUnit и добавляется в IOleUndoManager

Other

IDataAdviseHolder

Методы IDataObject, которые относящиеся к уведомлениям об изменении данных могут быть реализованы путем вызова методов этого интерфейса.

Обычно используется стандартная реализация.

IOleAdviseHolder

Методы IOleObject, относящиеся к уведомлениям, могут быть реализованы путем вызова методов этого интерфейса.

Обычно используется стандартная реализация.

IDropSource

Реализуется объектами, которые можно перетаскивать, т.е. он может быть источником операций перетаскивания. Когда он реализован, он позволяет объекту рисовать эффекты перетаскивания и указывать, когда объект отбрасывается или операция перетаскивания отменяется.

IDropTarget

Реализовано с помощью объекты, которые принимают отброшенные объекты, т. е. могут быть целью операций перетаскивания. Когда он реализован, он позволяет цели указать, будет ли принят отброшенный объект, и что произойдет с объектом после его удаления.

IOleCommandTarget

Может быть реализовано объектами (объектами OLE, OLE контейнеры и другие объекты), которые хотят поддерживать определенные стандартные команды. Он позволяет вызывающим абонентам запрашивать, поддерживаются ли команды, и выполнять команды. Команды, которые объект обычно может захотеть реализовать, могут включать такие вещи, как «удалить», «вырезать», «скопировать», «вставить», «отменить», «найти», «напечатать», «сохранить», «увеличить» и скоро. В настоящее время определено 58 стандартных команд, включая команды, обычно используемые офисным программным обеспечением, веб-браузерами и аналогичными приложениями.

IOleUndoUnit

Представляет действие, которое можно отменить. Он содержит всю информацию, необходимую для отмены действия. Он создается объектами и контейнерами, так что отменяемые действия могут быть добавлены в контейнер IOleUndoManager.

IOleParentUndoUnit

Позволяет блоку отмены содержать другие блоки отмены. По сути, это позволяет юниту отмены действовать как стек отмены, группируя юниты отмены вместе. Например, если запускается макрос, все отменяемые действия, выполняемые макросом, могут быть сгруппированы в один блок отмены.

IOleWindow

Этот интерфейс представляет окно контейнера или содержащегося объекта. Это позволяет вызывающим абонентам получать дескриптор окна и переключать функцию контекстно-зависимой справки. Когда функция контекстно-зависимой справки включена, указатель мыши обычно изменяется на стрелку со знаком вопроса, чтобы указать, что щелчок по элементу пользовательского интерфейса приведет к открытию окна справки.

Competition

OpenDoc Технологии пытались составить конкуренцию OLE. Некоторые конкуренты Microsoft считали OpenDoc более надежным и простым в использовании; однако OpenDoc имеет некоторые известные проблемы. OpenDoc позволял пользователям просматривать и редактировать информацию в приложениях, прямо конкурируя с проприетарным стандартом OLE от Microsoft. В 1993 году некоторые конкуренты Microsoft создали консорциум под названием Component Integration Laboratories («CIL») для разработки OpenDoc как открытого стандарта для межплатформенного связывания и встраивания.

Microsoft требовала совместимости с OLE в качестве условия сертификации Microsoft совместимости приложения с Windows 95. Изначально Microsoft объявила, что приложения, использующие OpenDoc, будут считаться совместимыми с OLE и получат сертификацию для Windows 95. Позже Microsoft отменила это решение и заявила, что приложения, использующие OpenDoc, могут вообще не проходить сертификацию. Microsoft не раскрывала спецификации и отлаженные версии OLE до тех пор, пока не выпустила свои конкурирующие приложения.

Взаимодействие

Использование объектов OLE ограничивает взаимодействие, поскольку эти объекты не широко поддерживаются в программах для просмотра или редактирования файлов вне Microsoft Windows (например, встраивание других файлов в файл, таких как в виде таблиц или диаграмм из приложения для работы с электронными таблицами в текстовом документе или файле презентации). Если программное обеспечение, которое понимает объект OLE, недоступно, объект обычно заменяется изображением (растровое представление объекта) или не отображается вообще.

См. Также

• OLE Automation
• OLE для управление процессами (OPC)
• Компонентная объектная модель (COM)
• Распределенная компонентная объектная модель (DCOM)
• Динамический обмен данными (DDE)
• Интернет-носитель тип
• Многоцелевые расширения почты Интернета (MIME)
• Shscrap.dll (файлы запоминания оболочки)

Ссылки

Внешние ссылки

• ripOLE — извлекает вложения из документов OLE

Эта статья основана на материалах, взятых из Free On-line Dictionary of Computing до 1 ноября 2008 г. и включенных в соответствии с условиями «перелицензирования» GFDL, версия 1.3 или новее.