Quellen

• CERT: ActiveX Report
• Emin Gün Sirer: ActiveX Security.
• Risks-18.83 ff.
• ActiveX security concerns continue (Risks-20.50).

Microsofts »Objekt-Modell«

COM = »Component Object Model« von Microsoft.

»Componentware«: wiederverwendbare Programmteile (~ Objekte).

Ursprüngliche Anwendung: OLE.

Verteilte Objekte nach Microsoft

DCOM = Distributed COM:

Entferntes Objekt wird über lokales Proxy-Objekt angesprochen. [Ähnlich wie in CORBA, aber ohne »Dienste«.]

ActiveX:

Entferntes Objekt wird übertragen (und installiert) und lokal angesprochen. Auf WWW-Seiten wie Applet, in anderen Dokumenten mit OLE.

Zertifikate nach Microsoft

Idee:

1. Heruntergeladene Software ist nur vertrauenswürdig, wenn sie von einem bekannten Urheber digital signiert ist.
2. Der Urheber weist sich mit einem Zertifikat eines anerkannten Trust-Centers aus.
3. Der Benutzer wird einmal gefragt, ob er dem Urheber traut - ab dann wird dessen Software grundsätzlich als vertrauenswürdig behandelt.

Was bescheinigt ein Zertifikat?

[Im Vorgriff auf Kryptographische Protokolle]

Zertifikate gehören zur asymmetrischen Kryptographie und lösen das Problem: Ist ein öffentlicher Schlüssel echt?

Ein Zertifikat bescheinigt die Zusammengehörigkeit von Name und Schlüssel durch digitale Signatur eines Trust Centers auf den Datensatz (Schlüssel, Name, weitere Merkmale)

Kritik von E. Felten

[Mythen über digitale Signaturen, Risks-18.83]

Mythos 1:

Eine digitale Signatur bescheinigt, wer ein Programm erstellt hat. (Aber: Jeder kann es signieren.)

Mythos 2:

Wenn ich dem Signierer vertraue, ist das Programm sicher. (Aber: Wie ist sein Sicherheitsstandard?)

Mythos 3:

Digitale Signaturen schaffen Verbindlichkeit. (Aber: Bösewicht verwischt Spuren.)

Standpunkt vom Microsoft

• Benutzer wollen automatische Software-Installation.
• Attacken sind illegal. (»... was nicht sein darf.«)
• Benutzer sind für Sicherheit selbst verantwortlich.

• Vertrauen auf Alles-oder-Nichts-Basis.
• Ein Zertifikat bescheinigt Sicherheit.
• Es gibt keine gehackten WWW-Server.
• Es gibt kein Web-Spoofing.
• Geheime Schlüssel werden nie kompromittiert.

Weitere Kritik

• Es gibt keine Mechanismen, die verhindern, dass eine HTML-Seite Controls von anderen Servern oder bereits installierte Controls aufruft.
• ActiveX-Controls haben keine Vorkehrungen gegen Stack-Manipulation (Buffer Overflow).
• Es gibt keine Widerrufsmöglichkeit für kompromittierte Schlüssel.
• Vom Benutzer wird Risikoabschätzung im falschen Moment mit unvollständiger Information verlangt.
• Es gibt keine weitere Sperre zwischen Laden und Ausführen (wie z. B. die Sandbox in Java).

Zusammenfassung

• Microsoft verkennt Komplexität der Probleme.
• Microsoft arbeitet an weiterer (völliger) Öffnung der Systeme.
• ActiveX-Technik nur innerhalb enger Sicherheits-Domäne brauchbar.
• Für ein Intranet Java-Technik wesentlich besser geeignet.