Seit E-Mails nicht nur in geschlossenen Kreisen, also beispielsweise firmenintern, ausgetauscht werden, wird diese Art der Kommunikation zunehmend für illegale oder unerwünschte Zwecke missbraucht. Während der Dateiaustausch mittels tragbarer Medien, wie Disketten und CDs, der früher wesentlich für Virenbefall verantwortlich war, für die Systemadministration noch halbwegs kontrollierbar ist, ist dies im Bereich E-Mail nicht mehr so einfach.
Entwickler von Schadprogrammen haben sich häufig die dominante Stellung von Microsoft zu Nutze gemacht und die Installation von Viren auf bekannte Sicherheitslücken von Internet Explorer, Outlook oder Outlook Express abgestimmt. Neben Programmfehlern gerieten vor allem auch die verschiedenen Automatisierungsmöglichkeiten der E-Mail-Programme zum Problem. Diese wurden gerne von Viren verwendet, um sich selbsttätig weiter zu versenden.
Mit einem Update von Outlook 98 hat Microsoft durch eine Radikalkur diesem Treiben einen Riegel vorgeschoben. Jede automatisch verschickte Nachricht musste danach durch eine manuelle Eingabe bestätigt werden. Da die Virenautoren schnell dazu übergingen, ihre Programme mit eigenen SMTP-Clients zu versehen, wurde ein analoges Verhalten auch bei anderen Funktionen, beispielsweise bei Zugriff auf die Outlook-Kontakte, eingeführt.
Die hierdurch immer wieder angezeigten Dialoge machen allerdings nicht nur Virenautoren das Leben schwer. Nach dem Einspielen des Patchs in Outlook 98 war eine Vielzahl von selbst erstellten wie auch kommerziellen Erweiterungen für Outlook praktisch nicht mehr verwendbar, da die gewünschte Automatisierung nun nicht mehr funktionierte. Statt selbsttätig durchzulaufen, war ein manuelles Wegklicken von Dialogen notwendig.
Diese Funktionseinschränkung ist im Grunde genommen bis heute erhalten geblieben, in manchen Fällen noch verfeinert oder sogar verschärft worden. Allerdings hat Microsoft auch eine Reihe von Mechanismen bereitgestellt, um Administratoren zu ermöglichen, für bestimmte Programmkomponenten die Sicherheitsabfragen zu unterdrücken. Hierzu zählen beispielsweise:
-
Signierung von Programmen und Skripts
-
Freigabe von ausgewählten Modulen
-
Speicherung von Konfigurationsinformationen auf einem Exchange Server
Der wichtige Punkt dabei ist jeweils, dass bevor eine Software auf die Funktionen von Outlook zugreifen kann, ein manueller Eingriff einer berechtigten Person notwendig ist. Erst danach lässt das System den automatisierten Nachrichtenversand zu. Bei der Installation oder der ersten Ausführung – oder mithilfe eines externen Administrationsprogramms – muss der entsprechende Code freigegeben werden.
Freigeben von Add-Ins
Besonders gefährlich sind Skripts und einfache ausführbare Programme, die durch Sicherheitslücken oder durch fingierte Downloads zur Ausführung gebracht werden. Add-Ins hingegen müssen ohnehin erst einmal installiert werden. Dieser zusätzliche Schritt macht sie als Virenträger weniger attraktiv. Unbedarfte Anwender, die ein Installationsprogramm aus dem Netz herunterladen und ausführen, lassen sich allerdings immer noch genug finden. Sie verfügen in vielen Firmenumgebungen allerdings nicht mehr über die notwendigen Rechte. Viren, und andere Schadprogramme kommen deshalb kaum in der Form von Outlook-Add-Ins vor. Aus diesem Grunde vertraut Outlook 2003 standardmäßig allen installierten Add-Ins. Trotzdem unterliegen auch diese Erweiterungen grundsätzlich den in die Outlook-APIs integrierten Beschränkungen. Sie sind bloß für diese Komponenten deaktiviert.
Die zugehörigen Einstellungen lassen sich über das Menü Extras/Makros/Sicherheit einsehen und verändern. Im auf diese Weise angezeigten Dialog Sicherheit findet sich in der Registerkarte Vertrauenswürdige Herausgeber der Eintrag Allen installierten Add-Ins und Vorlagen vertrauen, der standardmäßig aktiviert ist. In angepassten Installationsroutinen kann die Standardeinstellung geändert werden.
Wird der genannte Eintrag deaktiviert, werden Add-Ins und Vorlagen analog der Einstellung für Makros in der Registerkarte Sicherheitsstufe behandelt. Die Stufe Sehr hoch steht in diesem Falle nicht mehr zur Verfügung. In der Einstellung Hoch wird nur signierter Code aus vertrauenswürdigen Quellen ausgeführt. Bei Mittel wird beim Laden des Codes beim Anwender nachgefragt. Dies ist allerdings in Unternehmensnetzen in der Regel nicht wünschenswert. Die Einstellung Niedrig deaktiviert schließlich die gesamten APISchutzfunktionen. Outlook ist in diesem Fall anfällig für Makroviren und externe Schadprogramme.
Signieren von Dateien
Das Signieren von Anwendungen ist ein gutes Mittel, die Vertrauenswürdigkeit von Programmen sicherzustellen, da hierdurch die Identität des Herstellers genauso nachgewiesen wird wie die Tatsache, dass der Code nicht zwischenzeitlich manipuliert wurde. Allerdings ist das hierfür notwendige Verfahren eher umständlich. Für kommerziell vertriebene Software ist es allgemein empfehlenswert, allerdings auch mit nennenswerten Kosten verbunden. Für unternehmensinterne Software bietet es sich nur dann an, wenn eine entsprechende Zertifikatsinfrastruktur vorhanden ist. Zur Signierung wird in jedem Fall ein Klasse 3-Zertifikat benötigt, welches zum Zweck der Code-Signierung ausgestellt wurde. Der Server des Ausstellers sollte zur Verifizierung der Signatur von den Client-Maschinen über das Netzwerk erreichbar sein. Softwarehersteller werden deshalb ein von einem kommerziellen Anbieter, wie etwa Verisign, stammendes Zertifikat verwenden, was zu den angesprochenen Kosten führt.
Signiert werden können die verschiedensten Dateien beziehungsweise Datensegmente, wie beispielsweise Installationsdateien (CAB oder MSI), .NET-Assemblies oder Skripts und Makros. Die Art, wie die Signierung durchgeführt wird, ist spezifisch für die Art der Datei. .NET-Assemblies können direkt über die Projekt-Eigenschaften in Visual Studio .NET signiert werden. Für Installationsdateien kann der in Visual Studio enthaltene Code Signing Assistent verwendet werden:
signtool.exe /signwizard
VBA-Projekte lassen sich über den in Office enthaltenen Visual Basic-Editor mit Signaturen versehen (Menü Extras/Digitale Signatur).
Weitere Möglichkeiten
Als Zugeständnis an die besonderen Bedürfnisse von Unternehmensnetzen hat Microsoft eine weitere Möglichkeit geschaffen, die Sicherheitsarchitektur von Outlook anzupassen. Diese legt eine speziell anpassbare Sicherheitskonfiguration in einem öffentlichen Ordner ab. Administratoren können auf diese Weise sehr feinkörnig festlegen, welche Funktionen und Erweiterungen in den Outlook-Clients eines Unternehmens ausgeführt werden dürfen. Die notwendigen Dateien sind in den Resource Kits der jeweiligen Office-Version enthalten (ADMPACK.EXE). Weitere Informationen hierzu finden sich unter http://support.microsoft.com/kb/290499/de.
Zudem gibt es ganze Reihe von Lösungen von Drittanbietern. Hierbei handelt es sich aber in der Regel um Workarounds und Programmierbibliotheken, deren Einsatz nur bei sehr konkretem Bedarf sinnvoll ist.
NET und Sicherheit
Wie bereits in den vergangenen Teilen dargestellt wurde, ist Office zum heutigen Zeitpunkt eine komplett auf Unmanaged Code basierende Anwendung, ohne jegliche Anpassung an .NET. Add-Ins werden deshalb auch nur als die COMKomponente wahrgenommen, die die IDTExtensibility2-Schnittstelle implementiert. Die dahinter liegenden .NET-Klassen sind für Office nicht sichtbar.
Bei Verwendung der mit Visual Studio .NET mitgelieferten generischen Add-In-Assistenten wird, wie beschrieben wurde, ein einziges Ladeprogramm für alle auf diese Weise erstellten Erweiterungen verwendet. Dies bedeutet aus dem Gesichtspunkt der Sicherheit heraus, dass Outlook sowie alle anderen Office-Anwendungen nur über das Ausführen dieses Ladeprogramms entscheiden können. Wenn es gestartet wird, werden alle damit verbundenen Add-Ins ausgeführt, oder keines. Die Makrosicherheitsstufen greifen für diese Art der Add-Ins nicht, da sich die einzelnen Module nicht voneinander trennen lassen. Um genau zu sein, müsste der allgemeine .NET-Laufzeitlader MSCOREE.DLL signiert werden, um ein solches Add-In als signiert erscheinen zu lassen. Da dies eine zentrale Systemkomponente ist, würde dies kaum Sinn machen, da die Signatur bei einer Aktualisierung des Systems verloren gehen kann, Zudem würde dies ein größeres Sicherheitsloch öffnen, da dann allen durch MSCOREE.DLL geladenen Komponenten automatisch vertraut würde.
Bei Verwendung von Shims sieht es wiederum anders aus. Hier stellt jede individuelle Shim das Add-In aus Sicht von Office dar. Entsprechend lassen sich die einzelnen Shims signieren und individuell freigeben. In diesem Fall besitzt der Entwickler auch die Kontrolle über das Ladeprogramm, was bei der generischen Laderoutine nicht der Fall war. Da Shims nicht offiziell unterstützt werden, ist auch dieser Weg eher eine Notlösung.
Add-Ins, die mit VSTO 2005 erstellt wurden, besitzen ebenfalls ein eigenes Ladeprogramm. Dieses ist bereits mit einem Authenticode-Zertifikat von Microsoft signiert, so dass diese Add-Ins auch in den Sicherheitsstufen Hoch und Sehr hoch ausgeführt werden können. Gleichzeitig findet in diesen Add-Ins aber auch die .NET-interne Code Based Security Anwendung. Hierdurch lassen sich über .NET-Systemrichtlinien Ausführungsbeschränkungen festlegen. Den Add-Ins muss zur korrekten Ausführung das Privileg Full-Trust zugewiesen werden, was allerdings standardmäßig der Fall ist.
Mit Office 12 wird wahrscheinlich die erste Office-Version auf den Markt kommen, die zwar weiterhin im Wesentlichen auf Unmanaged Code beruht, deren Design aber auf die Existenz von .NET ausgelegt ist. Wie sich das in der Praxis auswirken wird, ob es beispielsweise eine direkte Schnittstelle für .NET-Add-Ins geben wird und wie die .NET-Sicherheitsarchitektur unterstützt wird, kann aber endgültig erst die veröffentlichte Version zeigen. Auf der anderen Seite werden die hier beschriebenen Schnittstellen bis auf weiteres unterstützt werden, so dass eine Entwicklung mit VSTO 2005 auch heute noch sinnvoll ist.
Zusammenfassung
In den vier Teilen dieser Serie wurde eine kurze Einführung in die Technologie der Outlook-Add-Ins gegeben. Bei der Erstellung von Client-Erweiterungen wirkt vor allem die komplexe Struktur der COM-Schnittstelle IDTExtensibility2 abschreckend. Zudem kamen in der Vergangenheit eine Reihe von technischen Problemen der Schnittstellen und Applikationen hinzu, die diese Art der Entwicklung zu einer Expertendisziplin machte. Die Einführung von .NET-basierten Add-Ins hat die Situation zunächst auch nicht verbessert.
Mit der Veröffentlichung der Visual Studio Tools für Office 2005 hat sich nun allerdings einiges getan. Zwar lassen sich hiermit ohne Programmierkenntnisse immer noch keine fertigen Add-Ins schaffen, aber der dort enthaltene Assistent löst die bekannten Probleme und reduziert gleichzeitig die Komplexität der IDTExtensibility2-Schnittstelle durch eine eigene einfachere Basisklasse. Zudem lassen sich durch mit VSTO entwickelte Add-Ins nun auch die Sicherheitsstufen von Office sinnvoll einsetzen.
Grundsätzlich unterscheidet sich der in Add-Ins notwendige Code vom technischen Anspruch nur wenig von dem in VBA-Makros. Die Integration in Visual Studio macht die Entwicklung in manchen Belangen sogar komfortabler als diejenige im Visual Basic-Makro-Editor. Mit VSTO sollte damit die Hürde, Add-Ins zu entwickeln, auch für weniger erfahrene Entwickler deutlich gesenkt sein. Für professionelle Entwickler ist es nun deutlich einfacher geworden, stabilen und wartbaren Code zu erstellen.
|
Objekt |
Eingeschränkte Eigenschaften |
Eingeschränkte Methoden |
|
Action |
Execute | |
|
AddressEntries |
Alle |
Alle |
|
AddressEntry |
Alle |
Alle |
|
AppointmentItem |
Body, Organizer, RequiredAttendees, |
Respond, SaveAs, Send |
|
ContactItem |
Body, Email1Address, Email1AddressType, |
SaveAs |
|
DistListItem |
Body |
GetMember, SaveAs |
|
Inspector |
HTMLEditor, WordEditor |
|
|
ItemProperties |
Für jede eingeschränkte Eigenschaft |
|
|
JournalItem |
Body, ContactNames |
SaveAs |
|
MailItem |
Body, HTMLBody, SenderEmailAddress, |
SaveAs, Send |
|
MeetingItem |
Body, SenderName |
SaveAs |
|
NameSpace |
CurrentUser, GetRecipientFromID |
|
|
PostItem |
Body, HTMLBody, SenderName |
SaveAs |
|
Recipient |
Alle |
Alle |
|
Recipients |
Alle |
Alle |
|
TaskItem |
Body, ContactNames, Contacts, Delegator, |
|
|
UserProperties |
Find | |
|
UserProperty |
Formula |