Untergeordnete Seiten
  • JVM 1.7.0_45 und JVM 1.6.0_65 LiveConnect, Manifest, Manifest Parameter und Signaturen
Zum Ende der Metadaten springen
Zum Anfang der Metadaten

LiveConnect

Mit 7U45 sind von Oracle weitere Manifest Parameter eingeführt worden. Insbesondere bei der Verwendung von JavaScript Aufrufen ist daher ein wenig mehr Aufmerksamkeit gefordert.
In älteren JVM Versionen konnte das Trusted-Library Manifest Attribut zur Verwendung von JavaScript-Java Aufrufen genutzt werden. Aus Sicherheitsaspekten ist mit der Version 7U45 zusätzlich das Caller-Allowable-Codebase Attribut eingeführt worden, um den genauen Ursprung von LiveConnect Calls spezifizieren zu können.

Eine detaillierte Beschreibung des Caller-Allowable-Attributs und deren Verwendung findet sich unter:

Caller-Allowable-Codebase

In den Release Notes der 7U45 wird für die Verwendung von LiveConnect Calls empfohlen, das Trusted-Library Attribut in den Manifest Dateien zu entfernen und mit dem neuen Caller-Allowable-Codebase Attribut zu ersetzen. Bei der gleichzeitigen Verwendung beider Attribute wird eine Sicherheitswarnung angezeigt. Damit ist eine "One-fits-all" Manifest Konfiguration für die Verwendung der 7U45 wie auch für ältere JVMs aktuell nicht möglich. Eine Co-Existenz beider Attribute ohne Warnhinweise soll aber in einer zukünftigen JVM Version wieder ermöglicht werden.

Weitere Hinweise und eine tabellarische Übersicht der verschiedenen Konfigurationen und Verhaltensweisen unterschiedlicher JVMs findet sich unter:

Caller-Allowable-Codebase und Trusted-Library

Manifest

Aktuelle JVMs sind extrem ungnädig beim Parsen von Manifest Dateien. Das falsche Encoding, fehlende oder zu viele Blanks aber auch fehlende oder zu viele Zeilenumbrüche sorgen schon für ein "korruptes" Manifest. Auch wenn man es der Manifest Datei in einem Editor nicht ansieht so ist dies ein häufiges Problem das zu einer "Potentiell Unsicher"-Bewertung beim Start eines Applets oder WebStart Anwendung führen kann.
Wir empfehlen daher grundsätzlich die Änderung an Manifest Dateien möglichst mit dem JAR Tool zu vollziehen. Beginnen Sie dazu einfach mit dem ursprünglichen Jar Manifest, z.B. für jadice mit dem Manifest aus dem jadice-documentplatform-all Jar, und fügen Sie die gewünschten Parameter mit dem JAR Tool hinzu. Sollte dabei etwas nicht nicht in Ordnung sein oder ein Fehler auftreten, meldet dies das JAR Tool.

Manifest Parameter

Ab JVM Version 7U21 bis zur aktuellen Version 7U45 wurden mit jedem Patch Release verschiedene Security Settings und Änderungen von Oracle eingeführt, die zu markanten Verhaltensänderungen führen. Diese Änderungen waren, obwohl es sich lediglich um Patch Releases handelte, invasiv und erfordern jeweils eine Anpassung des Applet/JNLP Deployments. Die von Oracle bereits vorgenommenen und noch geplanten Änderungen zeigen, dass dieser Prozess noch im Fluss ist und auch bei zukünftigen (Patch-)Releases mit erneuten Änderung der Manifest-Einträge, Signatur und des Deployments zu rechnen ist.
Wir empfehlen daher die von Oracle vorgegebenen Anpassungen in den Manifest-Einträgen, der Signatur und des Deployments ernst zu nehmen und konsequent anzuwenden. Desweiteren sollten Applets oder WebStart Anwendungen bei JVM Version Wechsel ausgiebig getestet werden, bevor ein RollOut stattfindet.
Sollte es dennoch zu Problemen mit Manifest Einträgen kommen, kann es an folgenden Fallstricken liegen:

  • Bei Verwendung der Version 7U45 und LiveConnect Calls muss das Caller-Allowable-Codebase Attribut mit einem der Zielumgebung entsprechenden Wert sinnvoll belegt sein. Das Trusted-Library Attribut darf dabei nicht parallel verwendet werden. Bei Verwendung älterer JVMs ist die Verwendung des Trusted-Library Attributs ausreichend. Siehe dazu auch obigen Abschnitt "LiveConnect".
  • Alle Manifest-Parameter müssen identisch in allen Jars Libraries im Klassenpfad gesetzt sein.
  • Alle Ressourcen müssen in Jar Libraries mit passender Manifest Datei vorliegen. Ressourcen in Verzeichnissen werden als potentiell unsicher angesehen.

Zertifikate und Signaturen

Code Signaturen werden verwendet zur Sicherstellung der Unveränderlichkeit der Codebasis einer (Web-)Anwendung oder eines Applets und zum Schutz vor (bösartiger) Manipulation durch Dritte. Oracle legt insbesondere für Web-Anwendungen und Applets sehr großen Wert darauf, dass alle Jars einer Anwendung signiert sind. Liegt keine Signatur vor oder ist die Signatur abgelaufen oder anderweitig ungültig, betrachten aktuelle JVMs die Web-Anwendung für "Potentiell Unsicher" und der Anwender wird bombardiert mit erschreckenden Warnhinweisen. Für das kommende 7U51 JVM Release im Januar 2014 hat Oracle zusätzlich angekündigt, dass zur Signatur nur noch qualifizierte Zertifikate von vertrauenswürdigen Zertifikatsdienstleistern akzeptiert werden. Nicht signierte oder selbst-signierte (self-signed) Libraries werden ab der Version 7U51 blockiert und nicht mehr ausgeführt.

  • Wir empfehlen daher dringend alle Jars im Klassenpfad einer WebStart oder Applet Lösung zu signieren.
  • Benötigte Ressourcen dürfen nicht mehr aus Ordnern oder Verzeichnissen angezogen werden. Sämtliche Ressourcen sollten in einer JAR Datei mit passendem Manifest gebündelt werden und ebenfalls signiert werden.
  • Alle Jars im Klassenpfad des Applets müssen mit dem gleichen Zertikat signiert werden und das Zertifikat muss gültig und darf nicht abgelaufen sein.
  • Die Signatur muss die letzte und einzige Signatur auf allen JAR Dateien im Klassenpfad sein.
  • Sind im Klassenpfad Jars enthalten, die bereits vorher signiert waren, müssen sämtliche alten Signatur Einträge aus diesen Jars entfernt werden und mit dem neuen Zertifikat frisch signiert werden.

 

Siehe auch:

RIA Checklist by Oracle

Jar File Manifest Security Entries

JVM 1.7.0_21 und 1.6.0_45 JavaScript-Java Aufrufe

JVM 1.7.0_25 und JVM 1.6.0_51 Neue Manifest Parameter