Analyse Der Sicherheit Impliziter Autorisierung Durch Referenzenvergabe Bei CORBA Object Request Brokern

Diplomarbeit
Analyse der Sicherheit impliziter Autorisierung durch Referenzenvergabe bei CORBA Object Request Brokern
Institut fr Angewandte Mikroelektronik und Datentechnik u Universitt Rostock a
Diplomarbeit
Christoph Becker 20. September 2006
Gutachter:
Prof. Dr.-Ing. Ralf Salomon Universitt Rostock a Dipl.-Ing. Sebastian Staamann PrismTech GmbH
Danksagung
Ich bedanke mich bei Prof. Ralf Salomon fr die gute Betreuung der Arbeit. u Der Firma PrismTech, insbesondere Sebastian Staamann mchte ich fr o u das in mich gesetzte Vertrauen und die hilfreiche Untersttzung danken. u Ein herzliches Dankeschn verdienen Nicolas Noke fr seinen jederzeit o u sachkundigen Beistand und Thomas Bertow fr sein unendliches Reperu toire an aufmunternden Worten whrend der gesamten Bearbeitung. a Allen namentlich nicht erwhnten Mitarbeitern von PrismTech Berlin, die a mir bei kleineren oder auch greren Problemen zur Seite gestanden hao ben, mchte ich ebenfalls fr ihre Hilfsbereitschaft danken. o u Ein besonderer Dank gebhrt meiner Lebensgefhrtin fr ihre moraliu a u sche Untersttzung, ihr Verstndnis und die unermdliche Motivationsbeu a u reitschaft. Meinen Eltern danke ich, weil sie nie das Vertrauen in mich und meine Arbeit verloren haben und wie viele Freunde oft auf mich verzichten muten.
Inhaltsverzeichnis
1 Einleitung 1.1 1.2 1.3 Thematischer Hintergrund . . . . . . . . . . . . . . . . . . . Motivation und Zielstellung . . . . . . . . . . . . . . . . . . Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . .
1 2 3 3 5 5 10 11 15 17 19 19 22 25 27 28 35 39 41 45 48
2 Grundlagen 2.1 2.2 2.3 2.4 2.5 Was ist CORBA . . . . . . . . . . . . . . . . . . . . . . . . Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . . Sicherheitsanforderungen . . . . . . . . . . . . . . . . . . . . Angrisszenarien . . . . . . . . . . . . . . . . . . . . . . . . Bestehende Lsungen . . . . . . . . . . . . . . . . . . . . . . o
3 Material, Methoden und Werkzeuge 3.1 3.2 3.3 Betrachtete Produkte . . . . . . . . . . . . . . . . . . . . . Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Ergebnisse 4.1 4.2 4.3 4.4 4.5 4.6 MICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ORBacus . . . . . . . . . . . . . . . . . . . . . . . . . . . . Orbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sun ORB . . . . . . . . . . . . . . . . . . . . . . . . . . . . Visibroker . . . . . . . . . . . . . . . . . . . . . . . . . . . . Weblogic . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
Inhaltsverzeichnis 4.7 4.8 WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . Komplexitt der Objektschlssel . . . . . . . . . . . . . . . a u 51 53 56 56 58 60 63 65 65 69
5 Diskussion 5.1 5.2 5.3 Komplexitt . . . . . . . . . . . . . . . . . . . . . . . . . . . a Machbarkeitsstudie . . . . . . . . . . . . . . . . . . . . . . . Lsungsmglichkeiten . . . . . . . . . . . . . . . . . . . . . o o
6 Zusammenfassung A Anhang A.1 Quelltextauszge . . . . . . . . . . . . . . . . . . . . . . . . u A.2 Aufbau der Objektschlssel . . . . . . . . . . . . . . . . . . u
iii
Tabellenverzeichnis
3.1 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9
Ubersicht der benutzten Request Broker . . . . . . . . . . . Transiente MICO Objektschlssel . . . . . . . . . . . . . . . u Transiente MICO Objektschlssel mehrerer POA . . . . . . u Persistente MICO Objektschlssel . . . . . . . . . . . . . . u Persistente MICO OKs in POA-Hierarchie . . . . . . . . . . Transienter ORBacus Objektschlssel . . . . . . . . . . . . u Teile transienter ORBacus Objektschlssel u . . . . . . . . . Transiente Schlsselteile verschiedener POAs . . . . . . . . u Persistenter ORBacus Objektschlssel . . . . . . . . . . . . u Zwei Transiente Orbix Objektschlssel . . . . . . . . . . . . u . . . . . . . . . . . . . . .
20 29 29 31 31 36 36 36 37 39 40 40 42 43 43 46 46 47 49 50 51 53
4.10 Orbix Objektschlsselabschnitte u
4.11 Orbix - verschiedene POAs . . . . . . . . . . . . . . . . . . 4.12 Transienter SUN ORB Objektschlssel . . . . . . . . . . . . u 4.13 Transiente SUN Objektschlssel verschiedener POA . . . . u 4.14 SUN POA-Namen, Kodierung . . . . . . . . . . . . . . . . . 4.15 Transienter Visibroker Objektschlssel . . . . . . . . . . . . u 4.16 Persistenter Visibroker Objektschlssel . . . . . . . . . . . . u 4.17 Visibroker Zeitstempel . . . . . . . . . . . . . . . . . . . . . 4.18 Transienter Weblogic Objektschlssel . . . . . . . . . . . . . u 4.19 Weblogic Objektzhler . . . . . . . . . . . . . . . . . . . . . a 4.20 Transienter WebSphere Objektschlssel . . . . . . . . . . . u 4.21 Vergleich der Objektschlsselkomplexitt u a . . . . . . . . . .
iv
Tabellenverzeichnis 4.22 Umrechnung Komplexitt in Zeitaufwand . . . . . . . . . . a 55
Abbildungsverzeichnis
2.1 2.2 2.3 3.1 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9
Scheinbarer und tatschlicher Weg eines Objektaufrufs . . . a Aufbau einer Interoperablen Objektreferenz . . . . . . . . . Komponenten der corbaloc-URL . . . . . . . . . . . . . . . Anordnung der POA . . . . . . . . . . . . . . . . . . . . . . Aufbau transienter MICO-Objektschlssel . . . . . . . . . . u Aufbau persistenter MICO-Objektschlssel . . . . . . . . . u Aufbau transienter ORBacus-Objektschlssel . . . . . . . . u Aufbau persistenter ORBacus-Objektschlssel . . . . . . . . u Aufbau Orbix-Objektschlssel . . . . . . . . . . . . . . . . . u Aufbau von SUN-ORB Objektschlsseln . . . . . . . . . . . u Aufbau transienter Visibroker-Objektschlssel . . . . . . . . u Aufbau persistenter Visibroker-Objektschlssel . . . . . . . u Aufbau transienter Weblogic-Objektschlssel . . . . . . . . u
6 8 16 24 30 31 37 38 41 44 47 48 50 52
4.10 Aufbau transienter WebSphere-Objektschlssel . . . . . . . u
vi
Einleitung
Diese Arbeit befasst sich mit der Sicherheit von verteilten Systemen die auf CORBA basieren. Die Zugrissteuerung innerhalb dieser Systeme ndet mit Hilfe von Objektreferenzen statt. Diese ermglichen den Zugri o auf andere Objekte innerhalb des Gesamtsystems. In dieser Arbeit werden die Implikationen betrachtet, die durch die Vergabe dieser Referenzen entstehen und die Erzeugung der Objektreferenzen untersucht. Um Problemen mit Begrisdenitionen aus dem Weg zu gehen, werden die verbreiteten englischen Begrie und Namen verwandt. Dies betrit in der Hauptsache die Wrter, die aus der CORBA Spezikation stammen o und damit auch die darauf basierende Literatur prgen. Fachbegrie wera den aus dem Deutschen benutzt, wenn dies mglich und sinnvoll ist. o Alle Quelltexte und viele der erzeugten Analysedaten, sowie die Testprogramme die nachfolgend benannt werden, benden sich vollstndig auf a der beigelegten CD-ROM.
1 Einleitung
1.1 Thematischer Hintergrund

Viele Informationssysteme werden heute als verteilte Systeme realisiert. Ein verteiltes System ist nach [TvS03] ein Zusammenschluss unabhngiger a Computer, welches sich fr den Benutzer als ein einzelnes System prsenu a tiert. Einserseits knnen mehrere Rechner fr die Erledigung einer Aufgabe zu o u deren Beschleunigung benutzt werden, beispielsweise zur Berechnung komplizierter Sachverhalte wie Wetterprognosen. Andererseits kann der mehrfache Einsatz gleichartiger Systeme die Ausfallsicherheit erhhen. Durch o die Vervielfachung der Systemkomponenten erhht sich auch die Kompleo xitt. Um die Systemkomplexitt beherrschen zu knnen, wurden neuara a o tige Softwarekonzepte entwickelt. Eines dieser Konzepte ist die Common Object Request Broker Architecture (CORBA). Sie ist eine weit verbreitete und uber die Jahre gereifte Architektur fr verteilte Systeme1 . Die konkrete Realisierung dieser Archiu tektur sind Object Request Broker (ORB). Die ORB vermitteln als sogenannte Middleware zwischen mehreren Systemen und vermindern die aus dem Konzept heraus entstehende Komplexitt auf ein ertrgliches Ma. a a Der Anwendungsprogrammierer muss sich nicht mehr um einzelne Protokolle und deren Spezikation kmmern um eine verteilte Anwendung entu wickeln zu knnen. CORBA selbst speziziert im Wesentlichen eine Ordo nung zur Realisierung verteilter objektorientierter Anwendungen [Say97, S. 15] in heterogenen Netzen. Durch den Einsatz verteilter Systeme und deren weite Verbreitung muss besonders groer Wert auf die Sicherheit gelegt werden, um Risiken zu minimieren. Setzt beispielsweise eine Bank CORBA ein, um die Auszahlungen ihrer Geldautomaten erfassen zu knnen, so ist es nicht nur fr o u die Bank wichtig, dass diese Transaktionen nachvollziehbar sind und nicht manipuliert werden knnen, sondern auch fr den Kunden. o u
engl.: distributed computing
1 Einleitung
1.2 Motivation und Zielstellung

Bis heute ist die Annahme verbreitet, dass ein Zugri auf CORBA-Objekte nur durch zuvor autorisierte Personen oder Systeme mittels ubergebener Objektreferenzen stattnden kann.2 Praktisch wrde dies bedeuten, dass u nur die Polizei, die Stadtverwaltung und alle von mir benachrichtigten Personen bei einem Umzug meine neue Adresse erhalten. Niemand sonst? Jeder der meine Adresse bekommt, wurde durch mich autorisiert? Im Rahmen dieser Arbeit wird untersucht, inwiefern die Beschaung typischerweise nicht geschtzter Informationen, wie Interoperable Objeku tereferenzen, es ermglicht, illegal Zugri auf entfernte, verteilte Systeo mem zu erlangen. Daraus resultierend wird der hierbei durchschnittlich bentigte Aufwand (Zahl der ntigen Versuche oder geschtzte Zeit) ero o a mittelt. Als reprsentative Untersuchungsobjekte wird die Arbeit gngige a a ORB-Produkte wie MICO, Orbix, SUN-ORB, VisiBroker, WebLogic-ORB und WebSphere-ORB verwenden und analysieren. Um die praktische Relevanz der theoretisch ermittelten Risiken beurteilen zu knnen, werden Werkzeuge entwickelt, die versuchen, illegalen o Zugri auf entfernte Objekte zu erhalten. Im Anschluss an die Vorstellung dieser Werkzeuge werden Vorschlge zur Verbessung der Sicherheit a gemacht, die verschiedenen Lsungsanstzen, mit und ohne Anderungen o a an bestehenden Systemen, folgen.
1.3 Gliederung der Arbeit

Die Arbeit beginnt mit einer kurzen Einfhrung in CORBA und erklrt, u a was Objektreferenzen sind und woher diese stammen. In Kapitel drei werden die untersuchten Programme und die fr diese Arbeit notwendigen u Methoden betrachtet. Im Anschluss daran benden sich die Ergebnisse der einzelnen Analysen die wiederum im fnften Kapitel, der Diskussion u
2
Natrlich existiert auch die Mglichkeit uber einen Namensdienst oder ein Implemenu o tation Repository eine Referenz zu erhalten, nur ist dies nicht der Gegenstand dieser Arbeit.
1 Einleitung zusammengefasst und diskutiert werden. Eine Machbarkeitsstudie und deren Ergebnis sind ebenso Teil dieses Kapitels, wie Lsungsvorschlge zur o a Beseitigung der ermittelten Sicherheitslcken. Die Arbeit schliet mit den u letzten Worten der Zusammenfassung.
Zweifel zu haben ist ein unangenehmer, sich in Sicherheit zu wiegen ein absurder Zustand. Voltaire
Grundlagen
2.1 Was ist CORBA

Die Common Object Request Broker Architecture ist eine durch die Object Management Group 1 (OMG), einem internationalen nicht gewinnorientierten Gremium, standardisierte Architektur zum Aufbau verteilter Systeme. Die Hauptziele der OMG sind die Entwicklung und Standardisierung von Softwarekonzepten. CORBA ist die Middleware-Plattform2 der OMG. Hauptbestandteil des CORBA Standards ist der Object Request Broker, kurz ORB. Er tritt als Vermittler auf und versetzt Systemkomponenten (Programme oder deren Teile) in die Lage, sogenannte Objektfernaufrufe3 durchfhren zu knnen. u o Die einzelnen Systemkomponenten kennen weder den eigenen Standort im
http://www.omg.org Middleware wird im Deutschen gelegentlich als Integrationsplattform bezeichnet. 3 auch bekannt als RMI (engl.: remote method invocation)
2 1
2 Grundlagen Gesamtsystem, noch den des Kommunikationspartners.4 Ein weiterer Bestandteil ist die Interface Denition Language 5 (OMG IDL) als abstrakte Sprache zur Schnittstellenbeschreibung. Mit IDL ist eine einfache Abstraktionsprache gefunden worden, die jederzeit ein Quelltextgrundgerst fr u u eine Anwendung in vielen Programmiersprachen erzeugen kann.6
Abbildung 2.1: Scheinbarer und tatschlicher Weg eines Objektaufrufs a
Abbildung 2.1 zeigt den prinzipiellen Aufbau eines CORBA-Systems und den Weg, den ein Objektaufruf nimmt. Ein Clientobjekt will auf die von einem anderen Objekt (Server) bereitgestellte Funktionalitt zugreia fen. Aus Sicht der Objekte, interagieren sie so, wie sie auch ohne CORBA miteinander interagieren wrden. Der Client stellt seine Anfrage in CORu BA aber an einen Stellvertreter des Serverobjektes, den sogenannten Stub. Dieser setzt die Anfrage in ein generisches ORB-Format um und ubergibt sie an den ORB. Im Folgenden sei der Einfachheit halber angenommen, dass der ORB die Adresse des Zielobjektes kennt. Uber diese Addresse ndet er den passenden Portable Object Adapter (POA), eine Art Registratur, bei der das Serverobjekt vom Programmierer angemeldet wurde. Der POA leitet die Anfrage an ein Stellvertreterobjekt (Skeleton) weiter, dass die Anfrage dann an das Serverobjekt stellt. Das Skeleton simuliert fr den Server das Clientobjekt bzw. dessen Schnittstellen. Dem Server eru scheint ein Aufruf so, als wrde der Client direkt mit ihm kommunizieren. u
4
In der Literatur auch als Ortstransparenz [HJS01, S. 14] oder location transparency [Sie96, S. 306][BVD01, S. 12] bezeichnet. 5 ISO 14750 6 Beispielsweise C++, Java oder Python.
2 Grundlagen Htte der ORB keine Addresse fr das Zielobjekt erhalten, so gibt es in a u CORBA die Mglichkeit, anhand des vom Client verlangten Objekttyps o (TypeId bzw. RepositoryId ) ein passendes Objekt heraus zu suchen. Dieser Mechanismus wird uber ein Implementation Repository bereitgestellt und ist optional. Wo kommen Stubs und Skeletons her? Die in der Interface Denition Language verfassten Objektdenitionen werden mit Hilfe eines IDLCompilers in Quelltexte fr die jeweils gewnschte Programmiersprache u u umgewandelt. Diese, auch Gerste genannten Quelltexte, dienen beim Obu jektaufruf dazu, dem Client die Schnittstelle des Servers zur Verfgung u stellen zu knnen und umgekehrt. o Damit Objektaufrufe in verteilten (und gegebenenfalls vernetzten) Systemen funktionieren, mssen die Vermittler miteinander kommunizieren u knnen. Deshalb kommt fr die Kommunikation dieser verteilten Systeme o u das General Inter-ORB Protocol (GIOP) zum Einsatz. GIOP deniert ein einfaches Format, um Anfragen und Antworten von Client und Servant zu transportieren, ohne sich auf Transportprotokolle festzulegen [BVD01, S. 81f]. Das Internet Inter-ORB Protocol (IIOP) ist eine GIOP-Ergnzung, a die GIOP auf TCP/IP abbildet [Kli00, S. 128][OMG04, 15.2]. Damit die Anfrage in Abbildung 2.1 von einem Objekt zum anderen vermittelt werden kann, muss diese adressiert werden. Doch wo wird die Adresse festgelegt? Zunchst wird ein Serverobjekt bei einem Objektadapa ter (POA) registriert. Dadurch erhlt es innerhalb des POAs eine eindeua tige Addresse. Der POA selbst ist innerhalb des ORB ebenfalls eindeutig identizierbar. Dies geschieht in der Regel durch einen Namen. Der ORB erzeugt fr jedes Objekt eine Adresse, es ist die Anschrit des Objeku tes innerhalb des ORBs7 . Die Objektadresse innerhalb eines ORB ist der Objektschlssel 8 . Mit ihm ist ein Zugri auf das Objekt mglich. Damit u o (wie in Abbildung 2.1) Client 1 und Client 2 auf das Serverobjekt zuAlle Objekte und Objektadapter die zu einem ORB gehren, also von ihm erzeugt o wurden, sind Teil einer Domne. Man bezeichnet diese hug auch als ORB-Domne. a a a 8 engl.: object key
7
2 Grundlagen greifen knnen, ist eine ORB-bergreifende Adressierung notwendig. Fr o u u diese Adressierung und Zustellung von Anfragen uber ORB-Grenzen hin weg und zur Zusammenarbeit mit den ORB anderer Hersteller, wird IIOP benutzt. In IIOP existieren die Objektschlssel als Bestandteil einer Inteu roperable Object Reference (IOR), der Interoperablen Objektreferenz. Zur Veranschaulichung ist die IOR in Abbildung 2.2 graphisch dargestellt.9 Der Fokus dieser Arbeit liegt auf dem Objektschlssel (rot) innerhalb der u IOR.
Abbildung 2.2: Aufbau einer Interoperablen Objektreferenz
Fr die Generierung jedes Objektschlssels ist der jeweilige Portable u u Object Adapter (POA) verantwortlich. An einem Objektadapter (POA) knnen nicht nur Objekte, sondern auch andere POA registriert werden, o wodurch der Aufbau einer Hierarchie mglich ist. Die Wurzel dieser Hiero archie bildet immer der sogenannte RootPOA. Bei ihm knnen Kind-POAs o registriert werden. Objektadapter werden mit sogenannten Policies initialisiert. Diese legen fest, wie der POA Objekte benennen, also den Objektschlssel erzeugen soll10 und wie der Lebenszyklus11 der Objekte deniert u ist. Bei der Namensgebung unterscheidet man zwischen vom System vergebenen Objektschlssel und vom Benutzer vergebenen Objektschlsseln. u u
Die Denition der IOR ist im Anhang in den Quelltexten A.1 und A.2 zu nden. IdAssignmentPolicy 11 LifespanPolicy
10 9
2 Grundlagen Objekte haben ferner zwei mgliche vorbestimmte Lebenslufe. Der Erste o a nennt sich transient und bedeutet, dass das Objekt aufhrt zu existieren, o wenn der POA bei dem es registriert wurde aufhrt zu existieren. Persistent o nennt man Objekte, die lnger existieren knnen, als der POA.[OMG04, a o 11.3.8.2] Des Weiteren benden sich Objekte im aktiven oder inakti vem Zustand. Aktiv heisst in diesem Kontext, dass das Objekt benutzt werden kann und nicht, dass es aktiv etwas tut. Meist wird die sogenannte Implizite Aktivierung benutzt, dabei werden Objekte, wenn sie bei einem POA registriert werden, automatisch durch diesen aktiviert. Wie gelangt man an die Objektreferenzen um diese weitergeben zu knnen? Durch die ORB-Funktionen object to string() und string to o object() kann eine Objektreferenz in eine Zeichenkettenform und wieder zurck in eine Referenz konvertiert werden [OMG04, 13.6.9]. Um einen u Eindruck davon zu bekommen, wie eine IOR aussieht, ist nachfolgend eine IOR eines ORBacus Objektes abgebildet: IOR:000000000000001749444c3a48656c6c6f4170702f48656c6c6f3a312 e30000000000001000000000000007800010200000000166c6f63616c686f 73742e6c6f63616c646f6d61696e00975a0000002aabacab3131313436343 233313539005f526f6f74504f41006e756c6c0000cafebabe445507770000 0000000000000001000000010000001c00000000000100010000000200010 020050100010001010900000000 Um auf ein Objekt zu verweisen kann alternativ zur IOR, auch das fr u Menschen besser verstndliche corbaloc URL-Format [OMG04, 13.6.10.1] a benutzt werden. Ein Beispiel12 fr eine corbaloc-Adresse ist: u corbaloc:iiop:1.1@555xyz.com/mypoa/object0001 Whrend corbaloc: dem Format und iiop:1.1 dem Protokoll und desa sen Version entspricht, steht 555xyz.com fr die Addresse des Rechners, u auf dem das Objekt zu nden ist. Daneben bezeichnet mypoa/object0001
12
Das Beispiel ist ktiv.
2 Grundlagen das Objekt, wobei es sich um den Objektschlssel handelt. Er kann Inu formationen uber seinen POA enthalten. Der POA und der ORB sorgen dafr, dass ein Objektaufruf mit Hilfe des Objektschlssels in der IOR u u oder der corbaloc Adresse auch an die richtige Inkarnation eines Objektes weitergeleitet wird. Damit ein Objektaufruf zwischen ORB verschiedener Hersteller auf verschiedenen Rechnerarchitekturen funktioniert, wurde die Common Data Representation (CDR) eingefhrt. Der Client-ORB wandelt alle Daten in u dieses Format um und ubertrgt sie an den ORB der Gegenseite. Dieser a kmmert sich selbststndig um die Rckwandlung dieser Daten. Somit u a u entstehen keine Probleme mit der Anordnung der Bytes (Little vs Big Endian) und der Datenstrom ist klar deniert.
2.2 Anwendungsbeispiel
Die Ubermittlung der aktuellen Messdaten einer Wetterstation erfolgt beispielsweise zwischen Client und Server, die auf jeweils verschiedenen Rechnern laufen. Zwischen beiden besteht eine ungesicherte Netzwerkverbindung. Das heisst, es wird weder SSL noch eine andere Verschlsselung u benutzt. Diese Teststellung wre unter anderem fr eingebettete Systeme a u realistisch. Die Datenbermittlung soll von dem in der Wetterstation beu ndlichen Client auf den Server, der mit einer Datenbank gekoppelt ist, erfolgen. Zunchst bentigt der Client eine Mglichkeit, den Server physisch zu a o o erreichen. Diese ist durch die Netzwerkverbindung gesichert. Der logische Zugri, also der Datentransport, soll mit Hilfe von CORBA realisiert werden. Der Client bentigt also die Adresse des Servers in Form der Objektreo ferenz. Der Einfachheit halber kann man annehmen, dass dem Client die Adresse in Form einer Datei, die die IOR enthlt, mitgeteilt wird. Er hat a nun alle notwendigen Daten, um mit dem Server interagieren zu knnen. o Der Zugri ist uber die IOR gewhrleistet. Desweiteren geht man davon a
10
2 Grundlagen aus, dass entweder der Client berechtigt ist, diese Dienste in Anspruch zu nehmen oder der Server geeignete Mechanismen besitzt, eine Berechtigung zu prfen. Derartige Kontrollmechanismen bentigen hug eine umfangu o a reiche Implementierung. Dieser Umfang ist jedoch nicht immer erwnscht u oder zweckmig. a Im Bereich eingebetteter Systeme geht man oftmals davon aus, dass dasjenige Objekt autorisiert ist, welches eine IOR besitzt oder dass die Vergabe einer IOR eine Autorisierung darstellt. Diese Annahme ist als implizite Autorisierung bekannt und basiert auf der Annahme, dass es mit vertretbarem Auswand nicht mglich ist, an eine gltige Objektreferenz o u zu gelangen. Dies wirft natrlich die Frage auf, ob und wie Dritte (z. B. Angreifer) u ohne legitime Ubergabe einer IOR in deren Besitz gelangen knnen und o somit Zugri auf das entsprechende Objekt erhalten.
2.3 Sicherheitsanforderungen
An informationsverarbeitende Systeme werden heute hohe Sicherheitsanforderungen gestellt. Diese Anforderungen sind gleichzeitig auch Ziele, die bei der Integration der Software zu erreichen sind. Im Besonderen interessieren Anforderungen an die Zugrissicherheit wie Autorisierung und Authentikation. Findet eine Autorisierung statt? Wenn ja wie? Wie sicher ist diese und kann sie umgangen werden? Analoge Fragen stellen sich auch zur Authentikation.
2.3.1 Authentikation
Authentikation ist die Indentittsberprfung (oder -kontrolle) einer Gea u u genstelle. Identizierung und Authentikation werden oft synonym benutzt. Jedoch besteht ein Unterschied insofern, dass bei der Authentikation eine Identitt uberprft wird und bei der Identizierung nur das a u Vorhandensein einer Indentizierungseigenschaft ntig ist. Das Vorlegen o
11
2 Grundlagen eines Personalausweises ist beispielweise die Identittsbehauptung (Indena tikation), die Uberprfung durch einen Polizisten hingegen eine Authenu tizierung (Identittsberprfung). Zu beachten ist hierbei, dass der Polia u u zist der Ausgabestelle des Personalausweises und dem Dokument an sich, dass heisst dessen Integritt trauen muss. Dies ist das Prinzip des vera trauenswrdigen Dritten, der die Identitt besttigt hat. Dies wird beiu a a spielsweise bei SSL-Zertikaten so gehandhabt. Eine Certication Authority (CA) kontrolliert die Identitt des Antragstellers und besttigt mit a a der eigenen Signatur, dass die im Zertikat vorgegebene Identitt, die a des Antragstellers ist. Derjenige, dem das signierte Zertikat vorgelegt wird, muss der CA trauen und Mechanismen besitzen, die Korrektheit der CA-Signatur zu uberprfen. Dann kann er auch der vorgelegten Inu dentittsbehauptung trauen. a Der Nachweis der eigenen Identitt kann uber viele Wege erfolgen. Zum a einen uber Besitz (man hat etwas wie einen Schlssel), via Wissen (man u wei etwas, Beispiel: PIN, Passwort) oder uber krperliche (biometrische) o Merkmale (man ist/kann etwas). Die verbeitete 2-Faktor-Authentizierung ndet statt, wenn zwei dieser Mglichkeiten kombiniert werden (Beispiel: o Geldautomat - man hat etwas, die Karte und man weiss etwas, die PIN). Authentizierung ist die Grundlage fr andere Anforderungen wie Veru traulichkeit, Verbindlichkeit oder Autorisierung.
2.3.2 Autorisierung
In der Informationstechnologie bezeichnet Autorisierung die Zuweisung und Uberprfung von Zugrisrechten auf Daten oder Diensten an Nutu zern.13 Sie kann explizit oder implizit erfolgen. Explizite Autorisierung bedeutet, dass ein Mechanismus einem Nutzer (oder auch einem Prozess) den Zugri auf ein deniertes Objekt erlaubt hat. Dies kann gegebenenfalls uberprft werden. Diese Form der Autoriu sierung setzt Authentikation voraus, es sei denn, es gibt die Zulassung fr u
13
http://de.wikipedia.org/wiki/Autorisierung, Stand 09:54, 20. Jul 2006
12
2 Grundlagen anonyme Benutzer. Dieser Fall kann Autorisierung an sich ad absurdum fhren.14 u Zur Vereinfachung von Autorisierungsmechanismen, wird meist Role Based Access Control 15 (RBAC) eingesetzt. Dem Rollensystem liegt die Idee zugrunde, dass Berechtigungen zur Nutzung geschtzer Komponenten dieu rekt an Rollen bzw. Aufgaben geknpft ist. Die Aufgaben werden durch u die Rollen modelliert. Es muss nun sichergestellt werden, dass die Subjekte (Nutzer) nur in die fr sie vorgesehenen Rollen schlpfen knnen. Der u u o Nutzer selbst steht im RBAC nicht im Mittelpunkt, sondern seine Aufgabe und die dafr ntigen Rechte. u o Mit Rollen knnen auch sogenannte Rollenhierarchien erzeugt werden. o Explizite Autorisierung auf einer Hierarchiestufe kann eine implizite Autorisierung auf anderen Hierarchiestufen bewirken. Beispiel einer Rolle: Ein Hausmeister erhlt einen Generalschlssel, durch a u den er Zutritt zu allen Rumen mit Ausnahme der Brorume eines Broa u a u hauses hat. Ein Firmenchef, der eine Etage gemietet hat, bekommt Zugang zum Gebude und allen gemieteten Rumen. Die Rechte des Hausmeisters a a resultieren aus seinen Aufgaben und begrnden sich nicht auf die Person u an sich. Als Beispiel einer Rollenhierarchie bekommen in einer Bank bekommen alle Angestellten einen Hausschlssel, aber nur Kassenprfer einen Tresoru u schlssel. Ein Kassenprfer wird aber auch als Angestellter gefhrt - ubt u u u also auch diese Rolle aus. Er hat in der Rolle des Angestellten auch das Recht, einen Hausschlssel zu besitzen. u
2.3.3 Verbindung zu CORBA

Bei der Realisierung von CORBA-basierten Applikationen wird von Anwendungsprogrammierern oftmals die Annahme gemacht, dass die VergaWenn anonym Zugri erlangt werden kann, so ist eine Authentikation der eigenen Person prinzipiell sinnfrei. Dass Anwendungen denkbar sind, in denen es trotzdem Sinn hat die eigene Identitt zu beweisen, sei unbestritten. a 15 Oftmals Rollenbasierte Systeme genannt.[Eck06, S. 245]
14
13
2 Grundlagen be einer Objektreferenz an ein Nutzerobjekt eine implizite Autorisierung, a hnlich einer Capability darstellt. Eine Capability ist nach [Eck06, S. 555] als geschtzter Zugrisausweis u deniert, der Zugri auf das benannte Objekte gestattet und gleichzeitig auch die Berechtigungen regeln kann. Um die Capabilities flschungssicher a zu machen, werden zunehmend Verschlsselungs- und Signaturmechanisu men eingesetzt. Da Capabilities nicht an Subjekte gebunden sind, knnen o sie in einfacher Weise weitergegeben werden. Eine kontrollierte Weitergabe ist nicht mglich. o Beispielsweise werden fr ein Musikkonzert verschiedene Eintrittskarten u verkauft (VIP, Sitz- und Stehpltze). Diese Information ist auf der Kara te vermerkt. Damit nun das Personal am Getrnkestand nicht jedesmal die a Karten kontrollieren muss, werden am Einlass die Karten gegen Farbbnder a getauscht. Ein grnes Band ist nun der Ausweis fr den VIP Status. Eiu u ne erneute Berechtigungsprfung erfolgt nicht. Der Veranstalter versucht u aber flschungssichere Farbbnder zu produzieren, die sich nicht vom Bea a sucher (Subjekt) trennen lassen. Er kmpft also mit den Schwchen einer a a auf Capabilities basierenden Autorisierung. Ein weiteres Einsatzgebiet fr Zugrisausweise ist Kerberos16 . Ein nach u der Authentizierung erhaltenes Ticket dient als Capability und somit als Ausweis und Legitimation gegenber anderen Diensten und Prozessen. So u kann man auf weitere Authentizierungsmanahmen verzichten. Kerberos kann beispielsweise auch beim sogenannten Single-Sign-on benutzt werden. Weitere Informationen zu Capabilities und deren Notwendigkeit ndet man in The Confused Deputy, or why capabilities might have been inven ted 17 . Eine Objektreferenz kann ebenfalls als Capability angesehen werden. Nimm man nun an, dass eine Objektreferenz illegal erlangt werden kann, so erhlt man das Recht zur Interaktion mit diesem Objekt, wenn keine a
Kerberos ist ein Protokoll, das den Zugang zu geschtzen Systemen kontrolliert. Siehe u RFC4120. 17 http://www.cis.upenn.edu/KeyKOS/ConfusedDeputy.html
16
14
2 Grundlagen zustzlichen Zugriskontrollmechanismen vorhanden sind. a Diese Annahme wirft die Frage auf, ob und wie solche Objektreferenzen erzeugt werden knnen. In CORBA identiziert der Objektschlssel jedes o u Objektes innerhalb einer ORB-Domne, die IOR systemweit. Whrend die a a Bestandteile der IOR wie Netzwerkadresse und Portnummer in der Regel aus der Kenntnis des Anwendungsszenarios gewonnen werden knnen, o erfordert die Bestimmung des Objektschlssels detaillierte Analysen. Eiu ne solche ergibt, dass Objektschlssel hug durch einfache Mechanisu a men generiert werden, die die Vorhersage weiterer Objektschlssel zulassen u [SB06][Bec06]. Dadurch lassen sich weitere Schlssel erraten und es werden u nicht autorisierte Zugrie auf Objekte des gleichen ORBs ermglicht. Dies o stellt eine potentielle Sicherheitslcke dar. u Fr die Zugriskontrolle ist es zwingend notwendig, dass IORs oder Obu jektschlssel nicht erraten oder geflscht werden knnen. Diese Forderung u a o ergibt sich aus ihrer Verwendung als Capabilities.
2.4 Angrisszenarien
Im Folgenden wird betrachtet, welche Mglichkeiten ein nicht autorisierter o Angreifer besitzt. Die Kenntnis von Host und Port, sowie der Signatur18 des anzugreifenden Objektes kann man als gegeben hinnehmen. Host und Port knnen o gegebenenfalls durch Netzwerkscans ermittelt werden - die Signatur ist fr eine aktive Nutzung des Objektes jedoch essentiell. Dieses Wissen ist u per se nicht geheim, man denke nur an eine Wissensabwanderung durch natrliche Mitarbeiteruktuation. Die einzig fehlende Information ist der u Objektschlssel (Siehe Abbildung 2.3, corbaloc-URL). u Dieser ist durch die OMG nicht standardisiert worden und somit herstellerabhngig [OMG04, 2.1.4]. Ob und wie man diese selbst produzieren a
18
Die Signatur ist hier im Kontext der funktionalen Programmiersprachen zu sehen. Sie beinhaltet die Anzahl und Typen der Methodenparameter und den Typ des Rckgabewertes, ggf. auch zu erwartende Ausnahmen (Exceptions). u
15
2 Grundlagen
Abbildung 2.3: Komponenten der corbaloc-URL
kann, ist der Schwerpunkt dieser Arbeit und wird im Hauptteil eingehend errtert. o Ist man bereits im Besitz einer IOR und ist das referenzierte Objekt immer noch aktiv, also ansprechbar, so besitzt man alle Daten fr den Objektzuu gri. Fr den Zugri auf andere Objekte muss hug nur ein Zugrispau a rameter gendert werden. Anhand einer IOR oder auch nur eines Objekta schlssels ist es mglich, sowohl den ORB-Typ und den POA-Namen oder u o die -Hierarchie, als auch Erzeugungszeiten beider zu ermitteln. Evaluiert man die Mechanismen, die solche Objektschlssel erzeugen u und kann man diese nachstellen, so msste es mglich sein, selbst gltige u o u Objektschlssel zu erzeugen. Mit Hilfe dieser kann illegal der Zugri eru langt werden. Die Algorithmen sind natrlich im Quelltext zu nden. Open u Source ORBs, so knnte man annehmen, sind eine leichtere Beute als Cloo sed Source Produkte. Doch eine Geheimhaltung des Algorithmus19 hilft in diesem Fall nur mig, da das Ergebnis, die Objektschlssel, ja in bea u liebiger Menge erzeugt werden knnen und somit auf den Algorithmus o dahinter schlieen lassen. Nach Jay Beale20 kann Closed Source hier nur helfen, potentielle Sicherheitslcken oder sogenannte Geheimnisse etwas u lnger zu bewahren. Im weiteren Verlauf der Arbeit wird gezeigt, dass es a fr den Angreifer unerheblich ist, woher der ORB stammt. Ein Weg hinein u ndet sich immer. Zuvor wurde davon ausgegangen, dass Host und Port bekannt sind. Allein mit diesen Daten ist es mglich einen Denial-of-Service (DoS) Angri o durchzufhren. Durch fehlerhafte Implementierung des ORBs kann man u bereits mit einfachen Mitteln einen Dienst auer Gefecht setzen. So ist
19 20
Dies wird oft auch als security by obscurity bezeichnet. http://www.bastille-linux.org/jay/obscurity-revisited.html
16
2 Grundlagen es gelungen, durch einen zufllig gewhlten Objektschlssel einen MICOa a u Server-ORB21 zum Absturz zu bringen, da die Fehlerbehandlung fr dieu sen eher seltenen Fall fehlerhaft war. In Anbetracht der Tatsache, dass viele Objektschlssel Zeitstempel besitzen, ist diese Manahme geeignet u den Zeitpunkt des ORB-Starts oder der Objekterzeugung minutengenau vorhersagen zu knnen. Ein Angrisziel knnte sein, einen ORB gezielt o o zum Absturz zu bringen, um dadurch eine bessere Ausgangsposition zu erhalten.
2.5 Bestehende Lsungen o

Durch den Absturz von MICO und der Existenz von Sicherheitslsungen o fr CORBA wird deutlich, dass bereits Probleme bei der Sicherheit exisu tieren und weitere vermutet werden knnen. o Die Frage, welches System per se sicherer ist eines, das hinter einer gut kongurierten Firewall steht oder eines, welches nackt uber entliche o Netze erreichbar ist, mge sich jeder selbst beantworten. Wie in [BS02] daro gelegt wurde, fhrt die nachtrgliche Integration von Sicherheitslsungen u a o in bestehende Java- und CORBA-basierte Anwendungen hug zu praka tischen Problemen, die durch vorhandene Firewall-Infrastrukturen noch verstrkt werden. Herkmmliche Firewalls arbeiten in der Regel Porta o basiert, wenn auf einem Port ausgehender Verkehr (also eine Anfrage von innerhalb des geschtzten Bereiches nach Auen) stattndet, so ist u zulssig, wenn hier wieder Daten hereinkommen (Antwort). Bei CORBA a erfolgt diese Portzuweisung jedoch dynamisch und fhrt deshalb zu Probleu men. Als Lsung wird hier auf sogenannte IIOP-Proxies oder Application o Security Gateways als Application Level Firewalls verwiesen.
21
Betrit Mico 2.3.12 ohne Security Fix 001.
17
2 Grundlagen
2.5.1 IIOP-Firewalls
Fr CORBA kann eine spezielle IIOP-Firewall eingesetzt werden, um den u systemspezischen Belangen gerecht zu werden. Eine IIOP-Firewall implementiert Zugriskontrollmechanismen die ein- und ausgehende IIOP/GIOP Nachrichten einer Domne kontrollieren und somit die Dmane zu a o schtzen. Eine IIOP-Firewall kann auch Parameter uberprfen die an Obu u jektmethoden ubergeben werden, wenn sie Kenntnis uber die Objekte und deren Schnittstellen besitzt. So wre es mglich, eine manipulierten Gelda o automaten zu ermitteln, der versucht, mehr als EUR 2000 auszuzahlen.22 Diese Firewall agiert dann auf hheren Schichten23 als TCP/IP indem es o GIOP-Nachrichten analysiert und verndert. So ist es denkbar, dass eine a solche Firewall oder ein Gateway vorhandene Objektreferenzen gegen eigene austauscht die besonders gesichert sind.24 Beim Eintreen einer Anfrage von Auen, kann somit geprft werden, ob diese Referenz vom Gateway u selbst erstellt wurde oder nicht. Der Aufruf des Objektes wird also sicherer gemacht vergleichen ungeprfter Weiterleitung. u
2.5.2 CORBASec
Eine weitere Lsung ist die CORBA Security (CORBASec) Spezikation. o Sie erweitert die CORBA-Spezikation zustzlich um Schnittstellen fr a u Sicherheitsaspekte. Darin erfolgt eine Spezizierung folgender Funktionalitt: Identikation und Authentizierung, Zugriskontrolle und Autorisiea rung, Auditing (Uberwachung), Datenintegritt, und die Administration a aller der genannten Policies. Allerdings hat sich CORBASec bis heute am Markt nicht durchsetzen knnen und keine Verbreitung erfahren. o
22
23
Wenn die maximale Geldmenge fr Auszahlungen EUR 2000 entspricht. u Bezogen auf das im ISO/OSI Schichtenmodell. 24 US Patent 6981265, http://www.patentstorm.us/patents/6981265.html
18
Erst zweifeln, dann untersuchen, dann entdecken. Henry Thomas Buckle
Material, Methoden und Werkzeuge
In diesem Kapitel werden zunchst die im Rahmen dieser Arbeit genutza ten Object Request Broker nach Sprache und Lizenz geordnet vorgestellt. Im Anschluss ndet eine kurze Vorstellung der Methoden und Werkzeuge statt, mit deren Hilfe die Interoperablen Objektreferenzen analysiert werden.
3.1 Betrachtete Produkte

Die analysierten ORB lassen sich in verschiedene Klassen einteilen. In Tabelle 3.1 werden alle betrachteten ORB nach der Oenlegung ihres Quellextes und ihrer Programmiersprache eingeordnet.
19
3 Material, Methoden und Werkzeuge Tabelle 3.1: Ubersicht der benutzten Request Broker ORB MICO ORBacus Orbix Sun JDK Visibroker Weblogic WebSphere Open Source ja ja nein ja nein nein nein Sprache C++ Java Java Java Java Java Java
3.1.1 MICO
MICO ist ein zehn Jahre alter, quelloener und unter GNU Lizenz vero o entlichter ORB, der von Kay Rmer und Arno Puder zu Lehrzwecken entwickelt wurde und heute mageblich von Object Security1 weiterentwickelt wird. Der Name ist ein rekursives Akronym und steht fr u MICO is CORBA. Im Rahmen dieser Arbeit wurde mit der Version 2.3.12 mit und ohne Security Fix 001 gearbeitet. Der Quelltext kann unter http://www.mico.org heruntergeladen werden. MICO ist CORBA 2.1 complient. 2
3.1.2 ORBacus
Von IONA3 eingekauft wurde der auch als C++ ORB erhltliche ORa Bacus. Er untersttzt den CORBA 2.6 Standard, liegt als Quelltext vor u und wird uber IONA kommerziell vermarktet. Speziell der Support ist bis 2010 auf aktuellen Systemen garantiert. Die Version 4.3 wurde fr die u Objektschlsselanalyse genutzt und kann uber http://www.orbacus.com u bezogen werden.
http://www.objectsecurity.com http://www.opengroup.org/press/7jun99 a.htm 3 http://www.iona.com

2
20
3 Material, Methoden und Werkzeuge
3.1.3 Orbix
Orbix 6 ist der kommerzielle ORB von IONA, der in zwei Varianten gepegt wird. Einerseits als Versionszweig 3.x mit der Untersttzung von u CORBA 2.1 andererseits fr Hochlastsysteme im Bereich Telefonie oder u Banken als Version 6.3. Genutzt wurde letztere, die Enterprise Edition als SOA/CORBA Allesknner. Unter http://www.iona.com/downloads o kann eine Testversion heruntergeladen werden.
3.1.4 Sun JDK

JDK steht fr Java Development Kit, kurz Java, und ist eine von Jau mes Gosling Anfang der 1990er bei Sun Microsystems entwickelte objektorientierte Programmiersprache. Das Hauptaugenmerk lag auf dem Erreichen einer hohen Plattformunabhngigkeit4 . Durch die Einfhrung von a u Funktionsfernaufrufen (Remote Method Invocation, RMI) 1997, wurde Java selbst zunchst als Gegenpart zu CORBA positioniert. Mit CORBA a 2.25 kam dann das Language-Mapping IDL/Java und in Java wurde die IIOP Untersttzung integriert. Mit der Freigabe der Quelltexte erfreut sich u Java einer groen Beliebtheit bei Open Source Entwicklern. Jedoch sind sowohl die Lizenzpolitik als auch die Performanz von Java umstritten.6 Das aktuelle Java 5 Tiger (eigentlich Java 1.5) untersttzt die CORBA u 7 Spezikation und kann als Bestandteil jeder Java-Umgebung unter 2.3 http://java.sun.com bezogen werden.
3.1.5 Visibroker
Der Borland Enterprise Server, VisiBroker Edition8 , wurde in den Versionen 7 und 6.5, Java Edition fr diese Arbeit analysiert. Als CORBA 2.6 u kompatibler Application Server ist die CORBA-Untersttzung im Laufe u
4 5
Sinngem aus http://en.wikipedia.org/wiki/Java programming language a Siehe http://www.omg.org/gettingstarted/history of corba.htm 6 Vgl. http://en.wikipedia.org/wiki/Java criticisms, Stand 27.08.2006 7 Vgl. http://java.sun.com/j2se/1.5.0/docs/guide/idl/compliance.html 8 http://www.borland.com/de/products/visibroker/
21
3 Material, Methoden und Werkzeuge der letzten Jahre durch den WebServices-Hype etwas in den Hintergrund getreten. Eine Testversion kann unter http://borland.com/downloads heruntergeladen werden.
3.1.6 Weblogic
Der WebLogic Server von BEA ist ein Allrounder, der sich mittlerweile im WebServices Segment ausbreitet. Er bietet eine komplette Portallsung fr o u Unternehmen und ist nicht als ORB zu sehen, wie beispielsweise MICO. Die Version 9.1 wurde als Evaluationskopie via http://commerce.bea.com bezogen und verursachte massive Probleme beim Testen. Ein Evaluationssupport war von Bea trotz mehrfacher Nachfrage nicht zu erhalten. Innerhalb der Arbeit konnten deshalb nur transiente Objekte untersucht werden.
3.1.7 WebSphere
Der WebSphere Application Server 6 (WAS) ist Teil der WebSphere Produktlinie vom IBM. Wie Weblogic und Visibroker ist WebSphere eigentlich ein J2EE9 Application Server, der auch CORBA untersttzt. CORBA wird u zum Beispiel fr den clientseitigen Anwendungszugri benutzt. u 1998 hie der WAS noch Servlet Express10 , war klein und bot nur Servlets an. Im Laufe der Zeit hat sich das Paket immer weiter vergrert und o schlielich die in dieser Arbeit verwandte Version WAS 6.1, bezogen von http://www.software.ibm.com/webapp/, erreicht.
3.2 Methoden
Um zu analysieren, ob und wie Objektreferenzen erraten werden knnen, o beiten sich zwei Methoden an. Die erste liegt klar auf der Hand und ist der Blick in den Quellcode - die Quelltextanalyse. Als zweite Methode
9 10
Java Platform Enterprise Edition Siehe http://en.wikipedia.org/wiki/WebSphere Application Server, 25.08.2006
22
3 Material, Methoden und Werkzeuge eignet sich die Betrachtung der Ojektreferenzen selbst, um daraus auf den Erstellungsmechanismus schlieen zu knnen. o
3.2.1 Referenzanalyse
Die Analyse von Objektreferenzen setzt voraus, dass der zu analysierende ORB fr das Testsystem vorhanden ist und gegebenenfalls uber eine Liu zenz verfgt. Als Testsystem fungiert ein Ubuntu Debian 6.06 System auf u einem AMD Athlon 1800+ mit 512MB Arbeitsspeicher. Fr alle lizenzu pichtigen Systeme11 wurde eine vom Hersteller bereitgestellte Evaluationslizenz genutzt. Die Java ORB wurden entweder unter Java 5 oder, sofern vorhanden, unter der mitgelieferten Java VM12 betrieben. Um eine fr jeden ORB gleiche Testumgebung sicherstellen zu knnen, u o ist fr die Java ORB eine Testapplikation (siehe Abschnitt 3.3.2) zu entu wickeln. C++ ORB sind im Vergleich zu den Java Varianten nicht im gleichen Mae portabel, deshalb werden hier hnliche Beispielprogramme a fr jeden ORB seperat entwickelt. u Um aus den gewonnenen Objektschlsseln auf die zugrundeliegenden u Mechanismen schlieen zu knnen, ist eine wohldenierte Vorgehensweio se erforderlich. Zunchst werden 1000 transiente Objekte mit einem POA a erzeugt. Dieser und alle folgenden Schritte werden jeweils zwei Mal wiederholt. So kann bereits im ersten Schritt erkannt werden, welcher Teil des Schlssels ORB- bzw. POA-abhngig ist und welche Teile sich von Obu a jekt zu Objekt unterscheiden. Aufgrund [SB06] und [Bec06] besteht die Vermutung, dass die Objekte jeweils nur durchgezhlt werden. a In einem zweiten Schritt wird mit vier POA gearbeitet, die alle Kinder des RootPOA sind. Daraus lsst sich ermitteln, welche aus dem ersten a Schritt vermuteten Teile den ORB und welche den POA identizieren. Desweiteren kann damit eine Vermutung uber die Form der Objektnummer besttigt werden. a
11 12
Orbix, Visibroker, Weblogic und WebSphere VM steht fr Virtuelle Maschine (engl.: virtual maschine) u
23
Abbildung 3.1: Anordnung der POA
Anschlieend werden die vier POA (Siehe Abbildung 3.1) in einer Hierarchie angeordnet. Wenn sich die POA-Hierarchie in irgendeiner Form im Objektschlssel widerspiegelt, so ist diese Methode geeignet, dies herauszuu nden. Um abschlieend getroene Vermutungen besttigen zu knnen, ist a o die POA-Hierarchie im letzten Schritt auf vier POA anzuwenden, whrend a vier weitere direkt dem RootPOA untergeordnet sind (Kombination der Strukturen aus Abbildung 3.1). Die so zur Verfgung stehenden acht POA u lassen eine vergleichende Analyse zu und bieten direkte Vergleichsmglicho keiten.
3.2.2 Quellcodeanalyse
Insofern der zu untersuchende ORB als Quelltext vorliegt, werden die Mechanismen zur Erzeugung der Objektschlssel direkt dort nachgeschlagen. u Fr die Bereitstellung eines neuen Objektschlssels ist bei transienten Obu u jekten in der Regel der POA13 zustndig. Der Blick in den Quelltext und a die Ableitung brauchbarer Ergebnisse setzt Kenntnisse der internen Mechanismen und Programmierparadigmen voraus. Prinzipiell muss nur die POA-Implementierung gefunden und analysiert werden, selten auch die des ORB-Kerns. Die OpenSource-ORB sind in der jeweils benutzten Version auf der beiliegenden CD vollstndig enthalten weshalb auf eine umfassena de Wiedergabe entsprechende Quelltexte verzichtet und im Regelfall nur darauf verwiesen wird.
13
Die IdAssignmentPolicy ist so eingestellt, dass das System die Schlssel erzeugen soll. u
24
3.3 Werkzeuge
3.3.1 Analyseprogramm
Eine IOR in Zeichenkettenform ist schwer zu analysieren, wenn sie nicht in ihre Bestandteile zerlegt wird. Viele davon sind ohnehin fr diese Arbeit u uninteressant. Ein Programm, mit dem sich eine IOR dekodieren lsst, a liegt in der Regel jedem ORB bei. Dadurch werden die einzelnen Komponenten fr den Menschen besser verstndlich dargestellt. Die Variante u a des freien Java ORB JacORB (dior), wird fr die Ziele dieser Arbeit so u verndert, dass nun auch mehrere IORs in einem Schritt dekodiert werden a knnen. Desweiteren ist es mglich, sich die Objektschlssel sowohl als o o u ASCII-Text (URL-Form), als auch als HEX-Darstellung anzeigen zu lassen. Mittels Doppelkreuz (#) ubergebene Kommentare hinter den IORs bleiben bei der Referenzdekodierung erhalten und erleichtern somit die sptere Zuordnung der Objektschlssel zur IOR. Dies ist insbesondere bei a u vielen POA notwendig. Ein zweites Analyseprogramm, orbinfo, ebenfalls basierend auf JacORB, soll anhand der Ergebnisse der Arbeit implementiert werden. Es wird zu einer IOR oder einem Objektschlssel mglichst viele Informationen ermitu o teln wie beispielsweise der ORB-Typ, die Erstellungszeit und viele mehr.
3.3.2 Testprogramm
Die zu entwickelnden Testprogramme zur Objektschlsselgenerierung solu len grundstzlich wie folgt vorgehen: a 1. Auswertung der Kommandozeilenargumente 2. Erzeugung des ORB 3. Erzeugung der POA 4. Erzeugen der Servants (Objektinkarnationen) 5. Eintritt in die Generatorschleife
25
3 Material, Methoden und Werkzeuge a) Aktivierung der Objekte b) Ermittlung der Referenz, Schreiben der IOR c) Deaktivierung der Objekte 6. Aufrumen a 7. Ausgabe der Statistik Die POA knnen jeweils fr das Binden persistenter und transienter Obo u jekte konguriert werden. Desweiteren ist es mglich, die POA in einer o Hierarchie aufzubauen. Eigene Versuche haben gezeigt, dass sich an der prinzipiellen Systematik keine Anderungen ergeben, wenn mehr als ein POA pro Ebene aktiv ist. Die Anzahl erzeugbarer Objekte wird programmtechnisch auf 10 6 begrenzt, da in der Praxis keine greren Mengen an Objekten zur POAo Laufzeit zu erwarten sind. Weiterhin knnen persistente und transiente Objekte erzeugt werden, jeo doch nicht gleichzeitig. Eine Ausnahme hierzu stellt der RootPOA dar, der immer nur transiente Objekte verwalten kann. Um zeitliche Abhngigkeiten a innerhalb der Schlssel besser nden zu knnen, muss eine Einstellung exisu o tieren um die Erzeugung einzelner POAs oder Objektinkarnationen zeitlich steuern zu knnen. Ebenfalls mglich und fr das Testen selbsterzeugter o o u Objektreferenzen vorteilhaft, ist die Mglichkeit den ORB laufen zu lassen o (ORB->run()) und somit fr Anfragen von Auen erreichbar zu machen. u Dieses Testprogramm wird in einer Machbarkeitsanalyse die Serverobjekte erzeugen und als Server fungieren. Im Rahmen dieser Analyse wird ein Programm zu entwickeln sein, das auf den Ergebnissen dieser Arbeit basiert und den Zugri auf andere Objekte mit Hilfe von selbst erzeugten Objektreferenzen ermglicht. o
26
Ergebnisse
Die durch die Analyse gewonnenen Ergebnisse werden nach ORB getrennt betrachtet. Des Weiteren sind bei den OpenSource-ORB die Ergebnisse der Referenzanalyse und die der Quelltextanalyse nicht seperat angefgt. Zur u besseren Vergleichbarkeit der Aufwandsabschtzung fr das reverse engia u neering der zugrunde liegenden Algorithmen wurde zunchst jedoch fr a u alle Request Broker die Referenzanalyse durchgefhrt. Eine Zusammenu fassung der Ergebnisse fr alle ORB erfolgt im letzten Abschnitt dieses u Kapitels. Das Format der Objektschlssel wird zunchst graphisch dargestellt und u a im Anhang mit Hilfe einer kontextfreien Grammatik1 , der Erweiterten Backus-Naur-Form 2 (EBNR), beschrieben. Die angegebenen Zahlen fr die verschiedenen Mglichkeiten, aus denen u o
1 2
Bezogen auf die Chomsky-Hierarchie ist die Grammatik G Typ2 . Die Erweiterte Backus-Naur-Form ist in ISO/IEC 14977:1996(E) standardisiert. Siehe auch http://www.cs.man.ac.uk/pjj/bnf/bnf.html#EBNF.
27
4 Ergebnisse ein Schlssel bestehen kann, sind mit Annahmen versehen. Dies dient im u Rahmen dieser Arbeit der besseren Vergleichbarkeit der ORB untereinander. Die Zahlen geben die jeweils maximal vermuteten Mglichkeiten o wieder, die Zeiten dahinter stellen lediglich einen Anhaltspunkt dafr dar, u wie lange man maximal bentigt, um den gesamten Suchraum3 zu durcho suchen. In der Realitt wird, wenn Gleichverteilung vorliegt, nur die Hlfte a a davon bentigt werden. Versuche haben gezeigt, dass die Suche am Ano fang des Wertebereiches bei Zhlern mit frhen Erfolgen verbunden ist. a u Dies folgt aus der Natur eines Zhlers. a
4.1 MICO
4.1.1 Transiente Objekte
Bei der Referenzanalyse wird nach dem in Abschnitt 3.2.1 beschriebenen Verfahren vorgegangen. Im Interesse der Ubersichtlichkeit wird auf eine allzu detaillierte Darstellung verzichtet und auf die der Arbeit beiliegenden Analyserohdaten verwiesen.4 Um eine Vorstellung von einem MICO-Objektschlssel zu bekommen, u ist nachfolgend einer in HEX- und URL-Darstellung zu sehen: 2F 31 35 37 32 2F 31 31 35 31 33 33 36 32 31 32 2F 30 2F 5F 30 /1572/1151336212/0/ 0 Erzeugt man mit Hilfe des Testprogramms viele IOR und extrahiert den Objektschlssel in URL-Form5 , so kann man schnell auf den Mechanismus u schlieen, der einzelne Objekte voneinander unterscheidet. Die Objektschlssel in Tabelle 4.1 unterscheiden sich nur in der letzten Stelle bzw. u den Stellen hinter dem letzten Schrgstrich. Dies ist ein Zhler fr das a a u laufende Objekt. Im weiteren Analyseverlauf wird nur noch die URL-Form benutzt, da offensichtlich der gesamte Schlssel als Zeichenkette behandelt wird, die aus u
3 4
Der Suchraum ist der gesamte Wertebereich fr mgliche gltige Schlssel. u o u u Siehe CD am Ende dieser Arbeit. 5 Aufruf: dior -f datei-mit.iors -u > datei-fuer.urls
28
4 Ergebnisse einzelnen numerischen Komponenten besteht. Der gefundene Objektzhler a Tabelle 4.1: Transiente MICO Objektschlssel u Objekt 0 1 2 3 10 99 100 101 Objektschlssel u /1572/1151336212/0/ /1572/1151336212/0/ /1572/1151336212/0/ /1572/1151336212/0/ /1572/1151336212/0/ /1572/1151336212/0/ /1572/1151336212/0/ /1572/1151336212/0/
0 1 2 3 01 99 001 101
verhlt sich bei der Benutzung mehrerer POA (Siehe Tabelle 4.26 ) als a ORB-weiter Objektzhler. Die vorletzte Stelle wird fr die Identikation a u des POA benutzt. Dabei ist diese Stelle immer numerisch und unabhngig a vom POA-Namen oder dessen Stellung in einer vermeintlichen Hierarchie. Es handelt sich um einen POA-Zhler. a Tabelle 4.2: Transiente MICO Objektschlssel mehrerer POA u POA 1 2 3 1 2 3 Objekt 0 0 0 1 1 1 Objektschlssel u /1572/1151336212/0/ /1572/1151336212/1/ /1572/1151336212/2/ /1572/1151336212/0/ /1572/1151336212/1/ /1572/1151336212/2/
0 1 2 3 4 5
Die erste und zweite Stelle des Schlssels (jeweils durch einen Schrgu a strich getrennt) lassen Raum fr Mutmaungen. Whrend der erste Teil u a immer drei- bis fnfstellig ist (Beispiele: 1572, 32669, 316, 763, 1246), so u ist der zweite Teil immer konstant zehnstellig und beginnt in der Regel mit 11. Begibt man sich auf die Suche nach hnlichen Werte, so kommt man a
6
Aus mico-200606261736.iors.oid.url
29
4 Ergebnisse zur Vermutung, dass es sich um einen Zeitstempel handelt. Die Ursache hierfr ist die Korrelation des Wertes mit dem UNIX Timestamp7 korreu liert. Umgerechnet ergibt dieser Stempel den 26.06.2006 um 17:36 Uhr, die Startzeit des ORBs. Der erste Teil wchst bei aufeinanderfolgenden Vera suchen stetig, nimmt bei spteren Versuchen jedoch scheinbar willkrlich a u einen geringen Wert an und steigt erneut. Zunchst knnte man einen Zua o fallswert in den Grenzen von 1-99999 vermuten, doch steht dies mit der vorhandenen Stetigkeit im Widerspruch. Nheres ist nur durch die Quella textanalyse zu klren. a Die Quelltextanalyse kann einerseits die Ergebnisse der Referenzanalyse untermauern, andererseits auch bisher Verborgenes an den Tag bringen. Auch liefert sie Hinweise darauf, von welcher Qualitt die Referenzanalyse a ist und worauf mglicherweise bei den nachfolgenden ORB geachtet werden o sollte. Die Suche nach dem Objektschlssel beginnt praktischerweise in der u POA-Implementation, da die Objekte am POA registriert werden. Betrachtet man dazu die Quelltexte A.3 und A.4, ndet man in ersterem einen Zhlmechanismus und im zweiten den Hinweis auf die ORB-Erstellungszeit a und die Prozess-ID des ORB. Diese ist die erste, durch die Referenzanalyse nicht aufklrbare Variable. a Mit diesem Wissen ergibt sich folgender Aufbau fr transiente Objektu schlssel des MICO-ORB8 : u
Abbildung 4.1: Aufbau transienter MICO-Objektschlssel u
4.1.2 Persistente Objekte

Der Aufbau von Schlsseln persistenter Objekte ist leicht verndert geu a genber dem transienter Objekte. Tabelle 4.3 zeigt die ersten drei Schlssel u u
7 8
Anzahl der Sekunden seit dem Beginn der UNIX Ara am 1.1.1970 1:00Uhr. Eine detaillierte Darstellung in EBNF ist im Anhang zu nden.
30
4 Ergebnisse eines POAs mit solchen Objekten. Man erkennt, dass in diesem Fall der Schlssel mit einem Text beginnt. Default ist der Standard-ORB-Name. u Ein solcher Name wird zur besseren Identikation an ORB vergeben, damit sie spter auch noch fr die Aufrufzustellung aundbar sind. Nach dem a u Trennzeichen ndet man den Namen des POAs an dem der Servant angemeldet ist, anschlieend vermutlich wieder die Prozessnummer des ORBs und dessen Erstellungszeit. Liegt eine POA-Hierarchie vor, so ndet man auch die gesamte HierarTabelle 4.3: Persistente MICO Objektschlssel u lfd. Objekt 0 1 2 Objektschlssel u Default/mypoaeins/%5C/23271%5C/1151920396 0 Default/mypoaeins/%5C/23271%5C/1151920396 1 Default/mypoaeins/%5C/23271%5C/1151920396 2
chie im Schlssel wieder (siehe Tabelle 4.4). Der hintere Abschnitt folgt u a hnlichen Prinzipien wie in Abschnitt 4.1.1 beschrieben. Konsultiert man Tabelle 4.4: Persistente MICO OKs in POA-Hierarchie Objektschlssel u Default/eins/ %5C/6940%5C/1157548901 Default/eins/zwei/ %5C/6940%5C/1157548901 Default/eins/zwei/drei/ %5C/6940%5C/1157548901 Default/eins/zwei/drei/vier/ %5C/6940%5C/1157548901 0 1 2 3
die gleichen Quellen wie bereits fr die Analyse transienter Objekte, so u besttigt sich der vermutete Aufbau. Als Anlaufpunkt dient hier wieder a die POA-Implementation. Persistente Objektschlssel des MICO-ORB seu hen damit wie folgt aus:
Abbildung 4.2: Aufbau persistenter MICO-Objektschlssel u
31
4 Ergebnisse
4.1.3 Fazit
Fr das Herausnden eines MICO Objektschlssels ohne Vorwissen, muss u u bei persistenten Objekten eine POA-Hierarchie erraten werden. Nimmt man an, dass die gesamte Zeichenkette nicht lnger als zehn Zeichen ist und a nur aus Gro- und Kleinbuchstaben, sowie Zahlen besteht, ist die Wahrscheinlichkeit9 hier einen Treer zu landen 1 : 6210 , also aussichtslos. Man ist darauf angewiesen, den Suchbereich der POA-Namen eingrenzen zu knnen. Da zuvor angenommen wurde, dass auch die TypeID bekannt ist o man will ja mit dem Objekt interagieren so wird im Folgenden fr das u Erraten der Hierarchie eine Wahrscheinlichkeit von 1 : 1, 28106 angesetzt. Dieser Wert ergibt sich aus der Uberlegung, das bekannt sein knnte, dass o die POA-Hierarchie maximal aus drei Ebenen (unterhalb des RootPOA) besteht und die POA-Namen aus einem Pool von 50 Mglichkeiten ento nommen werden. Dies soll einen Wrterbuchangri simulieren. Die POAo Namen knnten beispielsweise durch ehemalige Mitarbeiter bekannt sein. o Bei persistenten Objekten bendet sich der ORB-Name im Objektschlssel u wieder. Der Einfachheit halber sei angenommen, dass der Default-Name benutzt wird, andernfalls ergibt sich eine hnliche Komplexitt wie bei a a der POA-Hierarchie. Da bei transienten Objekten kein POA-Name, sondern nur ein POA-Zhler vorhanden ist, sei dieser auf 103 Mglichkeiten a o begrenzt. Diese Grenze ist zwar willkrlich, jedoch ist nicht anzunehmen, u dass sie uberschritten wird. Um die Prozess-ID eines ORBs erraten zu knnen, muss der Bereich in o dem diese ID liegen kann bekannt sein. Dieser ist jedoch vom Betriebssystem abhngig. Die benutzte Debian 3.1 Linux Distribution zhlt diese bis a a 216 = 65536 hoch und beginnt wieder von vorn. Werden insgesamt zur Lebenszeit des Servers10 nur sehr wenige Prozesse erzeugt bzw. wenige neu erzeugt so ist die Wahrscheinlichkeit am Anfang des Wertebereiches am grten und nimmt zum Ende hin ab. o Die Erstellungszeit des ORB sollte geschtzt werden knnen. Nimmt a o
9 10
26 Klein- plus 26 Grobuchstaben plus 10 Ziern Gemeint ist hier die Zeit zwischen Ein- und Ausschalten des Rechners.
32
4 Ergebnisse man dafr eine Genauigkeit von einem Tag (86400 Sekunden) an, so eru geben sich 86400 verschiedene Mglichkeiten. Der Aufwand, diese Zahl zu o erraten steigt also linear mit dem Zeitraum an, der durchsucht werden soll. Die Anzahl der Objekte, die an einem gltigen POA ausprobiert werden u mssen, sei auf 105 begrenzt. Dabei sei gleichzeitig angenommen, dass 10 u Prozent der vermuteten Objekte noch aktiv sind. Eine gngige Praxis zur Erzeugung von Objekten oder Objektadapa tern gibt es nicht. Untersuchungen darber existieren nicht und drften u u auch keinen Konsens nden. Die jeweilige Objektmenge pro Zeit ist immer abhngig vom Gesamtsystem und dem Gesamtkonzept. Die Zahl der a Objekte ist insofern willkrlich gewhlt. Oftmals ist es so, dass diese Zahl u a linear abhngig von der Lebenszeit des POAs ist. Dies soll nachfolgend a auer Acht gelassen werden, da viele Variablen bereits geschtzt sind und a das Betrachten dieser Abhngigkeit eine nicht vorhandene Genauigkeit a vortuschen wrde. a u Die Gesamtkomplextt eines MICO Objektschlssels betrgt: a u a Transiente Objekte: 65536 86400 10 = 5, 6 1010 648d Persistente Objekte: 1, 28 106 65536 86400 10 = 7, 2 1016 2, 3 106 a
Die Angaben spiegeln jeweils die maximale Anzahl der Versuche wider, die ntig sind, um einen gltigen Objektschlssel zu generieren. Dahino u u ter ist angegeben, wie lange man dafr bentigt, wenn ein Versuch pro u o Millisekunde durchgefhrt werden kann [Bec06]. u Die mittlere Wahrscheinlichkeit, einen transienten MICO-Objektschlsu sel zu erraten, betrgt 1 : 2, 8 1010 . Nimmt man an, man sei im Besitz a der technischen Lsung, die 1000 Mal pro Sekunde einen Schlssel auso u probieren kann, so wrde man durchschnittlich 324 Tage auf das Erraten u verwenden. Bei einem persistenten Objekt ist der Aufwand ca. 106 Mal hher und liegt damit gnzlich im Bereich des Unmglichen. o a o Gelangt man aber in den Besitz einer IOR, so sind folglich die ORB-Zeit,
33
4 Ergebnisse der ORB-Namen, die POA-Hierarchie und die Prozess-ID bekannt. Die Wahrscheinlichkeit des Erratens sinkt dramatisch. Die Komplexitt, also a die Anzahl der maximalen Versuche um ein weiteres Objekt am selben POA zu erraten sinkt fr alle Objekte auf 10, im Mittel also 5. u Innerhalb von 5ms ist ein weiteres aktives Objekt an diesem POA zu nden. Um alle 105 Objekte zu testen, bentigt man 100s. o Zum Aunden von Objekten an einem anderen POA dieses ORBs, muss man zunchst nur die POA-Hierarchie variieren. Im umfangreichsten Fall a kann man 1 : 1, 28 106 Mglichkeiten dafr ansetzen. Man bentigt im o u o Mittel dreieinhalb Stunden um ein gltiges Ergebnis zu erhalten. Dies setzt u allerdings vorraus, dass man nicht erkennen kann, ob ein POA existiert und fr jeden (eventuell auch ungltigen) POA alle Objekte ausprobiert werden u u mssten. Bei MICO ist dies nicht der Fall, denn er liefert die Ausnahme11 u OBJECT NOT EXIST, wenn der POA nicht existiert und OBJ ADAPTER, wenn das Objekt nicht existiert.12 Bercksichtigt man dies bei obigen Berechu nungen, so verringern sich diese um den Faktor 10. Die Gesamtkomplextt unter Bercksichtigung mglicher Optimieruna u o gen eines MICO Objektschlssels ergibt sich wie folgt, wenn keine Daten u bekannt sind: Transiente Objekte (t1 ): 65536 86400 = 5, 6 109 64, 8d Persistente Objekte (t2 ): 1, 28 106 65536 86400 = 7, 2 1015 228310a
Falls eine IOR bekannt ist, sind viele Variablen gegeben und mssen nicht u mehr evaluiert werden. Die Mglichkeiten reduziert sich auf nachfolgende o Werte und bentigen in etwa: o Objekte am gleichen POA (t3 ): 10 10ms
11 12
Exception Man wrde hier jedoch erwarten, dass OBJECT NOT EXIST dann geworfen wird, wenn u nur das Objekt nicht existiert und OBJ ADAPTER in allen anderen Fllen. a
34
4 Ergebnisse Objekte an anderen transienten POAs (t4 ): 103 1s Objekte an anderen persistenten POAs (t5 ): 1, 28 106 21min Ist eine gltige Objektreferenz bekannt, so ist es relativ leicht mglich, u o andere gltige Objektreferenzen zu erzeugen. u
4.2 ORBacus
Die Darstellung der ORBacus Objektschlssel erfolgt byteweise als HEXu Wert. Dort, wo es sinnvoll erscheint, wird gleichzeitig auf die URL-Form zurckgegrien. u
4.2.1 Transiente Objekte

In Tabelle 4.5 sieht man einen transienten Objektschlssel an POA null u (Kind von RootPOA) in HEX- und URL-Darstellung. Man kann erkennen, dass die POA-Hierarchie (RootPOA/null) einen Teil des Schlssels ausu macht. Die einzelnen Elemente der Hierarchie werden oensichtlich mittels Nullbyte13 verbunden. Aullig ist auch die Zeichenkette (ab Byte a fnf): 1146423159. Sie legt die Vermutung nahe, dass es sich um einen u Zeitstempel handelt. Der Grund dafr ist, dass sie mit dem UNIX Timeu stamp syncron luft. Umgerechnet ergibt dieser Stempel den 30.04.2006 a 20:52Uhr - die Startzeit des ORBs. Die ersten vier Byte stellen scheinbar ein magic14 dar, dass den ORB identiziert. Bei der Analyse aufeinander folgender Objektschlssel bemerkt man, dass sich nur ein kleiner Teil des u Schlssels ndert. In Tabelle 4.6 ist zu sehen, dass die letzten Stellen einen u a linaren Zhler darstellen. Die Bytes vor der POA-Zeit, CA FE BA BE, sind a
13
Ein Nullbyte (0x00) wird in der Programmiersprache C hug fr das Terminieren a u einer Zeichenkette benutzt. 14 Als magic werden oft Zeichenketten benannt, die implementierungs- oder versions abhngige Zustnde oder Ahnliches denieren. a a
35
4 Ergebnisse Tabelle 4.5: Transienter ORBacus Objektschlssel u HEX AB AC AB 31 31 31 34 36 34 32 33 31 35 39 00 5F 52 6F 6F 74 50 4F 41 00 6E 75 6C 6C 00 00 CA FE BA BE 44 55 07 77 00 00 00 00 URL ...11146423159 . RootPOA.null ......DU.w....
bereits als Java-magic bekannt und tauchen in allen ORBacus Objektschlsseln als Konstante auf. Davor sind jeweils zwei Nullbytes vorhanden. u Tabelle 4.7 zeigt die letzten acht Byte von Objektschlsseln des ersten Obu jektes an verschiedenen POA. Dabei ist es fr diesen Teil belanglos, ob dieu se vom gleichen ORB erzeugt wurden oder nicht. Es ndern sich jeweils maa ximal vier Bytes. Es deutet also darauf hin, dass der erste Teil der letzten acht Byte POA- und die letzten vier der acht Byte Objekt-spezisch sind. Die letzten vier Byte entsprechen der laufenden Objektnummer innerhalb des POAs. Konvertiert man die ersten vier der letzten acht Bytes (0x44 55 Tabelle 4.6: Teile transienter ORBacus Objektschlssel u lfd. Objekt 0 1 2 16 255 256 letzten acht Byte 44 55 07 6E 00 44 55 07 6E 00 44 55 07 6E 00 44 55 07 6E 00 44 55 07 6E 00 44 55 07 6E 00
00 00 00 00 00 00
00 00 00 00 00 01
00 01 02 10 FF 00
Tabelle 4.7: Transiente Schlsselteile verschiedener POAs u POA 1 2 3 letzten acht Byte 44 55 07 6E 00 00 00 00 44 53 58 98 00 00 00 00 44 55 07 77 00 00 00 00
07 6E) in Dezimaldarstellung, so erhlt man 1146423150. Beachtet man a
36
4 Ergebnisse jedoch, dass diese vier Byte stndig wachsen und das sich dieses Wachstum a langsam vollzieht, so kann man vermuten, dass Zeitabhngigkeit vorliegt. a Ist 1146423150 ebenfalls die Anzahl der Sekunden seit dem 1.1.1970, so bezeichnet dieser Wert den 30.04.2006 um 20:52Uhr. Dies entspricht dem Zeitpunkt der POA-Erstellung. Daraus schlussfolgernd lt sich folgender Aufbau15 fr transiente ORa u Bacus Objektschlssel feststellen: u
Abbildung 4.3: Aufbau transienter ORBacus-Objektschlssel u
Die vollstndige und detailliertere Darstellung bendet sich ebenfalls im a Anhang.
4.2.2 Persistente Objekte

In Tabelle 4.8 sieht man einen persistenten Objektschlssel. Im Vergleich u zum transienten fllt auf, dass das vierte Byte statt 0x30 den Wert 0x31 bea sitzt. Ab dem fnften Byte folgt dann sofort die POA-Hierarchie, ebenfalls u durch zwei Nullbytes terminiert. Es schliet sich die bekannte Kombination aus Java-magic, POA-Zeit und Objekt-Nummer an. Betrachtet man mehrere Objektschlssel16 , so besttigt sich diese Vermutung. Ein persisu a Tabelle 4.8: Persistenter ORBacus Objektschlssel u HEX AB AC AB 30 5F 52 6F 6F 74 50 4F 41 00 6E 75 6C 6C 00 00 CA FE BA BE 44 A8 13 6A 00 00 00 00 URL ...0 RootPOA .null...... D.......
tenter ORBacus Objektschlssel kann nach folgender Bildungsvorschrift u

15 16
Darstellung in EBNR. Wie in der Datei orbacus 060702 2051.iors.pers2p.oid auf der CD.
37
4 Ergebnisse erzeugt werden:
Abbildung 4.4: Aufbau persistenter ORBacus-Objektschlssel u
4.2.3 Fazit
Fr das Erraten eines ORBacus Objektschlssels ohne Vorwissen werden u u die gleichen Annahmen wie in Abschnitt 4.1.3 getroen. Die Erstellungszeit des POA stellt keine groe Hrde dar. Ein Tag hat u 86400 Sekunden also 86400 verschiedene POA-Erstellungszeiten. Der Aufwand, diese Zahl zu erraten, steigt also linar mit der Zeit, bzw. dem Zeitraum, der fr die Erstellung vermutet wird. Die Anzahl der Objekte ist u wieder auf 105 begrenzt. Die Gesamtmenge der Mglichkeiten sieht wie folgt aus, wenn ORB und o POA-Erstellung auf einen Tag genau vorhergesagt und die POA-Namen eingegrenzt werden knnen: o Transiente Objekte (t1 ): 864002 1, 28 106 10 = 9, 6 1016 3 106 a Persistente Objekte (t2 ): 86400 1, 28 106 10 = 1, 1 1012 34, 9a Bei object keys persistenter Objekte ist die mittlere Wahrscheinlichkeit 1 : 5 1011 . Wenn man pro Millisekunde einen Versuch unternehmen kann, so wre man im Mittel rund 16 Jahre beschftigt. Ist nun durch eine a a IOR, die ORB-Zeit, die POA-Hierarchie und POA-Zeit bekannt, so mssen u in beiden Fllen nur noch alle Objekte getestet werden. Die Anzahl der a Mglichkeiten und die Zeit um diese auszuprobieren sinkt auf: o Objekte am gleichen POA (t3 ): 10 10ms
38
4 Ergebnisse Objekte an einem anderen POA (t4 , t5 ): 86400 1, 28 106 = 1, 1 1011 3, 5a Allerdings bleibt hierbei unbercksichtigt, dass die Zeit zwischen der Eru stellung beider POA weniger als 24h betrgt. Geht man von fnf Minuten a u aus, so ist man in (t6 =) 4,4 Tagen am Ziel.17
4.3 Orbix
Durch Probleme bei der Erzeugung persistenter Objekte knnen nur trano siente Objektschlssel betrachtet und in HEX-Darstellung analysiert weru den. Der Analysegegenstand, ein transienter Orbix Objektschlssel ist nachu folgend dargestellt: 3A 3E 02 31 31 0C 78 3B 83 D7 33 46 E8 61 7F 30 D6 B1 08 00 00 00 00 00 00 00 01 Zum besseren Verstndnis vergleicht man (Tabelle 4.9) zwei aufeinandera folgende Schlssel, die Zugunsten der Ubersicht willkrlich zerlegt wuru u den. Man erkennt sofort, dass sich nur die letzte Stelle verndert hat. Wie a Tabelle 4.9: Zwei Transiente Orbix Objektschlssel u Eins 3A 3E 02 31 31 0C 78 3B 83 D7 33 46 E8 61 7F 30 D6 B1 08 00 00 00 00 00 00 00 01 Zwei 3A 3E 02 31 31 0C 78 3B 83 D7 33 46 E8 61 7F 30 D6 B1 08 00 00 00 00 00 00 00 02
aus Abschnitt 4.1 und Abschnitt 4.2 bereits bekannt, knnte es sich hier o ebenfalls um einen Objektzhler handeln. Tabelle 4.10 zeigt die letzten a acht Stellen von Objektschlsseln eines POAs. Die Vermutung mit dem u Objektzhler hat sich besttigt. Als nchstes ist die Unterscheidung vera a a schiedener POA von Interesse. MICO und ORBacus haben hierfr die u
17
5 60 1, 28 106 = 3, 8 108 3, 8 108 1000 3600 24 = 4, 444d
39
4 Ergebnisse Tabelle 4.10: Orbix Objektschlsselabschnitte u Objektnr. 0 1 2 3 255 256 1024 Schlsselabschnitt u 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 04
00 00 00 00 00 00 00
01 01 01 01 FF 00 00
POA-Hierarchie im Klartext in den Schlssel integriert. Bei Orbix ist dies u oensichtlich nicht der Fall. Tabelle 4.11 zeigt fnf Schlsselabschnitte18 u u verschiedener POA. Whrend die ersten sechs Byte konstant sind, trea Tabelle 4.11: Orbix - verschiedene POAs lfd. Nr. 1 2 3 4 5 78 CC 2C E3 CB 3B 31 42 00 9C 83 9B 80 BB EE Schlsselabschnitt u D7 33 46 E8 61 7F 3F 69 39 B1 6C 91 B1 85 5F 72 5B E2 09 FA 19 5B 6C 05 5A F7 6B A5 84 34 30 06 E4 F5 1B D6 C7 71 60 67 B1 C1 A4 0A 3A
ten vom siebten bis zum 18. Byte Varianten auf, die keinem Algorithmus zu folgen scheinen. Es knnte sich um eine Zufallsbytefolge handeln oder o aber um den Hash bzw. Teil eines Hashes des POA-Namens oder der POAHierarchie. Erzeugt man aber die gleichen POA nochmal (also mit gleichem Namen), so dieriert dieser Wert ebenfalls. Die Bedeutung der ersten sechs Bytes ist momentan noch unbekannt. Sicher ist nur, dass diese fr transiente Objektschssel konstant 3A 3E 02 u u 31 31 0C sind. In einer uber ein Internetforum bezogenen IOR eines per sistenten Objektes ist der Schlsselteil 3A 3E 02 31 32 0C. Denkt man u kurz uber die CDR, die Transfersyntax, nach, so fllt auf, dass die 02 a
18
Jeweils Byte sieben bis 18 Byte.
40
4 Ergebnisse der Lnge der nachfolgenden Zeichenkette 31 31 bzw. 31 32 entspricht, a whrend 0C die Lnge des POA-Schlssels anzeigt. Dementsprechend wre a a u a 08 die Lnge des Objektzhlers. Mag dies alles Zufall sein, so funktioniert a a es doch gut.
Abbildung 4.5: Aufbau Orbix-Objektschlssel u
Ein Orbix Objektschlssel bietet nicht viele Dinge, die zu erraten sind. u Die POA-ID ist mit zwlf Byte sehr lang und ergibt 25612 = 8 1028 o Mglichkeiten. In diesem Fall ist der Versuch des Erratens vollkommen o zwecklos. Die Chancen verbessernden Annahmen knnen nicht gemacht o werden. Der Objektzhler hingegen erlaubt es, alle Objekte eines POAs abzusua chen. Nachfolgend ist die Gesamtzahl der Mglichkeiten unter den beo kannten Annahmen fr die Objekte aufgefhrt: u u Transiente und/oder persistente Objekte (t1,4 ): 25612 10 = 8 1029 2, 5 1019 a Objekte am gleichen POA (t3 ): 10 10ms Orbix kann als resistent gegenber dem Erraten ohne Vorwissen angeseu hen werden. Ebenso ist es, statistisch gesehen, unmglich eine POA-ID o zu erraten. Die Ermittlung weiterer Objekte an einem bekannten POA ist allerdings genauso gering, wie bei allen vorgenannten ORB.
4.4 Sun ORB

Bevor mit der Analyse begonnen wird, muss man sich ins Gedchnis rufen, a dass der Sun Java ORB bei der Verentlichung von Java 1.5 Tiger ein o Redesign erfuhr. Ob dies auch die Objektschlssel betrit, soll mit Hilfe u von Testdaten der 1.4.2er Version ermittelt werden. Nachfolgend wird nur
41
4 Ergebnisse der 1.5er ORB betrachtet, auf den 1.4.2er wird gegebenenfalls explizit hingewiesen. Zunchst betrachtet man in Tabelle 4.12 den Objektschlssel in HEXa u und URL-Darstellung mit jeweils zwlf Byte pro Zeile (nicht-druckbare o Zeichen sind durch einen Punkt gekennzeichnet). Man erkennt, dass die POA-Struktur im Schlssel abgelegt wird und selbiger anscheinend mit u einem magic beginnt (Byte 1-3). Tabelle 4.12: Transienter SUN ORB Objektschlssel u HEX C2 47 00 02 41 00 00 00 00 01 14 URL ............ ............ ....RootPOA. ....null.... ............ .
AF 00 00 00 00
AB 00 00 00 00
CB 00 00 00 00
00 01 08 05 08
00 00 52 6E 00
00 00 6F 75 00
00 00 6F 6C 00
20 00 74 6C 01
61 00 50 00 00
F5 00 4F 00 00
Vergleicht man nun Schlssel verschiedener Objekte desselben POA, so u stellt man auch hier fest, dass an einer Stelle (dem vorletzten Byte) hochgezhlt wird (Tabelle 4.13). Variiert man zustzlich den POA, so ndert a a a sich das sechste Byte von hinten derart, dass es fr jeden neuen POA u inkrementiert. Erzeugt man nun an einem ORB verschiedene POA und fr diese jeweils mehrere Objekte, so knnen diese Abhngigkeiten gut u o a gefunden werden. In Tabelle 4.13 sind auf die letzten zehn Byte reduzier te Objektschlssel dargestellt. Byte fnf ndert sich pro POA-Anderung u u a und Byte neun pro Objektnderung. Was sich ebenfalls andert, sind die a POA-Namen im Objektschlssel. Beginnend ab Byte 28 ndet sich der u RootPOA und anschlieend der jeweils zustndige POA. Es handelt sich a hierbei um CDR kodierte Zeichenketten. Im long-Wert, vier Bytes vor der Zeichenkette, wird deren Lnge zuzglich des Nullbytes kodiert. In Tabelle a u 4.14 werden vier solcher Schlsselteile dargstellt. 08 52 6F 6F 74 50 4F u 41 0019 steht fr acht Zeichen, dem RootPOA plus Nullbyte und wurde u
19
Siehe Tabelle 4.12
42
4 Ergebnisse Tabelle 4.13: Transiente SUN Objektschlssel verschiedener POA u POA 1 2 3 1 2 3 1 2 3 Objekt 0 0 0 1 1 1 16 16 16 Schlsselabschnitt u 01 00 00 00 00 14 02 00 00 00 00 14 03 00 00 00 00 14 01 00 00 00 01 14 02 00 00 00 01 14 03 00 00 00 01 14 01 00 00 00 10 14 02 00 00 00 10 14 03 00 00 00 10 14
08 08 08 08 08 08 08 08 08
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Tabelle 4.14: SUN POA-Namen, Kodierung Schlsselabschnitt u 6C 6C 00 00 00 00 65 6F 6E 65 00 00 74 77 6F 00 00 00 68 72 65 65 00 00 POA-Name null oneone twotwotwo threethree
00 00 00 00 00 0A 74 00 00 00 0B 74
00 00 77 68
00 00 6F 72
05 07 74 65
6E 6F 77 65
75 6E 6F 74
in der Tabelle weggelassen. Jeweils angehngte 00 dienen dem CDRa Alignment und Padding [OMG04]. Betrachtet man nun wieder den Start des Schlssels, so sind fr transiente Objekte die ersten acht Byte immer u u AF AB CB 00 00 00 00 20. Betrachtet man persistente Objektschlssel u oder blickt man in den Quelltext, so kann man feststellen, dass persistente Schlssel immer mit AF AB CB 00 00 00 00 22 beginnen. Byte vier bis u acht spiegelt also die LifespanPolicy des POAs wieder. Nur mit Hilfe des Quelltextes20 ist dieser Verdacht zu besttigen. Die nachfolgenden vier Bya tes (Bsp.: 59 79 A9 BA) variieren von ORB zu ORB, wachsen stetig und beginnen bei Uberlauf wieder von vorn. Dass es sich hier um einen Zeitstempel handelt liegt auf der Hand. Zeitexperimente belegen, dass sich der Wert pro Sekunde um 1000 vermehrt. Es ist also anzunehmen, dass es sich um einen Millisekundenzhler handelt, wie ihn System.currentTimeMillis() a
20
In Datei com/sun/corba/se/impl/orbutil/ORBConstants.java, Zeile 87f.
43
4 Ergebnisse bereitstellt. In der ORB-Implementierung ndet sich auch genau dieser Punkt. Durch eine Typumwandlung werden nur die letzten 32 Bit betrachtet, dadurch rotiert dieser Wert alle 49,7 Tage.
Abbildung 4.6: Aufbau von SUN-ORB Objektschlsseln u
Fr persistene Objekte muss keine gesonderte Betrachtung stattnden, u da nur die ORB-ID anders belegt wird. Durch Variation der fr persistente u POA typischen Einstellungen, wie Server-Id und Server-Port, gelangt man zu dem Ergebnis, dass dort die PersistentServerId21 statt der Zeitangabe zu nden ist. Um nun einen SUN Java ORB object key ohne Vorwissen erraten zu knnen, ist es notwendig, dass man bei transienten Objekten den ORBo Zeitstempel (ORB-ID) und die gesamte POA-Hierarchie errt. Der Zeita stempel kann 2564 = 4, 3 109 verschiedene Werte annehmen. Die POAHierarchie ist theoretisch unendlich komplex, kann aber durch bereits in vorherigen Abschnitten getroene Annahmen auf 1, 28106 Mglichkeiten o begrenzt werden. Da fr persistente Objekte die ORB-ID (als Persistentu ServerId) die gleiche Komplexitt aufweist, treen diese Annahmen gleia chermaen zu. Transiente und persistente Objekte (t1,2 ): 4, 3 109 1, 28 106 10 = 5, 5 1016 1, 7 106 a Dieses Ergebnis verspricht zunchst ein hohes Ma an Sicherheit. Betracha tet man jedoch die Wahrscheinlichkeiten, wenn bereits eine gltige IOR beu kannt ist, so verringern sich diese Zahlen drastisch. Ist also ein Informati onsleck aufgetreten oder sind ohnehin IORs bekannt, dann besteht akuter
21
Sie bezeichnet den Servernamen oder eine Servernummer, die den ORB spter bei eia nem Neustart wieder korrekt identiziert. Dieser Mechanismus ist fr den persistenten u Objektaufruf wichtig.
44
4 Ergebnisse Handlungsbedarf. Nicht vergessen werden darf jedoch, dass bezglich der u Wahrscheinlichkeit fr Objekte anderer POAs auch hier bestimmte Anu nahmen vorausgesetzt sind. Die praktische Sicherheit kann deutlich uber oder unter dem angegebenen Werten liegen. Objekte am gleichen POA (t3 ): 10 10ms Objekte an anderem POA (t4 , t5 ): 1, 28 106 21min20s
4.5 Visibroker
Objektschlssel des Borland Visibroker weisen generell die gleichen Merku male wie alle zuvor behandelten Schlssel auf. Somit erscheint es zwecku mig, den Aufbau der Objektschlssel nicht so detailliert darzustellen, a u wie bisher. Es wird nur noch auf Eigenheiten eingegangen und der Schlsu selaufbau graphisch dargestellt. Die EBNF ndet sich, wie fr alle anderen u Schlssel auch, im Anhang. Da es sich nicht um ein OpenSource Produkt u handelt und sich transiente von persistenen Schlsseln kaum unterscheiu den, wird keine Quelltextanalyse und auch keine textuelle Trennung der Schlsseltypen vorgenommen. u Tabelle 4.15 zeigt einen transienten Visibroker 7 Objektschlssel, der u ein an POA null gebundenes Objekt referenziert, Tabelle 4.16 das ent prechende persistente Pedant. Ein Test mit Visibroker 6.5 ergab, dass diese Schlssel identisch aufgebaut sind. Innerhalb aller Analysen konnu te kein Unterschied zwischen beiden Versionen festgestellt werden.22 Bei den ersten vier Byte handelt es sich wieder um ein magic, das jedoch auch die LifespanPolicy des POAs anzeigt. Die bereits bekannte POAHierarchie ist ebenfalls beim Visibroker im Objektschlssel wiederzunu den. Der Vergleich mehrerer Objekte eines POAs zeigt auerdem, dass vom Objektzhler ebenfalls Gebrauch gemacht wird. Die einzige Speziaa
22
Bezogen auf den Schlsselaufbau. u
45
4 Ergebnisse Tabelle 4.15: Transienter Visibroker Objektschlssel u HEX 00 56 42 01 00 00 00 06 2F 6E 75 6C 6C 00 20 20 00 00 00 04 00 00 00 00 00 00 02 18 34 34 ED 39 URL .VB...../null ............. .....9
Tabelle 4.16: Persistenter Visibroker Objektschlssel u HEX 00 50 4D 43 00 00 00 04 00 00 00 06 2F 6E 75 6C 6C 00 20 20 00 00 00 04 00 00 00 00 URL .PMC......../ null......... ..
litt ist eine Art Zeitstempel bei transienten Objekten. Die letzten acht a Bytes (zwei Variablen vom Typ long oder ein long long) des Schlssels u beinhalten diesen Stempel. Versucht man jedoch den Timestamp 00 00 02 18 34 34 ED 3923 umzurechnen, so stt man auf eine scheinbar zu o groe Zahl. 0x000002183434ED39 = 2 302 978 354 489 Diese Zahl entspricht keinesfalls den Sekunden oder Millisekunden eines UNIX-Zeitstempels. Betrachtet man dies jedoch uber einen langen Zeit raum, so kommt man zu der Annahme, dass es sich um zwei long-Werte handelt, die miteinander die korrekte Zeit ergeben knnten. In Tabelle 4.17 o sind zwei Stempel, deren Erstellungszeit und die dazugehrige UNIX-Zeit o in Millisekunden24 aufgefhrt. Berechnet man die Dierenz der Stempel, u so mssten diese ca. 102 Tage auseinander liegen, in Wirklichkeit sind es u aber nur 84 Tage. Spaltet man nun die acht Bytes in zwei long Werte auf und nimmt an, dass 0x02 15 fr das Ergebnis relevanter ist25 , also Vielu fache von 232 darstellt, so macht man die Beobachtung, dass dieser Wert
23 24
aus Tabelle 4.15 Der Bereich der Sekunden und Millisekunden wurde mit Nullen gefllt, da die Erstelu lungszeit nur minutengenau vorliegt. 25 Aus engl.: most signicant.
46
4 Ergebnisse Tabelle 4.17: Visibroker Zeitstempel Stempel 00 00 02 15 4C 80 65 DC 00 00 02 18 34 33 7A A4 Erstellungszeit 24.04.2006 17:24 03.07.2006 13:43 currentTimeMillis() 1145892230000 1141735400000
(232 = 2 289 217 568 768) nahezu das Doppelte des Wertes ist, der die eigentliche UNIX-Zeit darstellt. Halbiert man diesen, multipliziert also mit 231 statt 232 und addiert die restlichen Bytes des zweiten long hinzu, so erhlt man26 a 533 231 + 1 283 483 100 = 1 145 892 267 484. Dies ist der bis auf 37s genaue, anhand der bekannten Erstellungszeit erwartete Zeitstempel. Der Stempel s = l1 l2 folgt also der Formel l1 = t mod 0x7FFFFFFF l2 = t 0x7FFFFFFF (4.1) (4.2)
Verfhrt man beim zweiten Stempel aus Tabelle 4.17 analog, so kommt a man zu einem identischen Ergebnis. Ein transienter Schlssel ist wie folgt u aufgebaut:
Abbildung 4.7: Aufbau transienter Visibroker-Objektschlssel u
Bei persistenten Objekten wird auf diesen Zeitstempel ersatzlos verzichtet. Ein Einu der ServerId auf die Schlssel konnte ebenfalls nicht u festgestellt werden. Der persistente Schlssel folgt folgender Erzeugungsu vorschrift:
26
Die Hexadezimalwerte wurden in das Dezimalsystem uberfhrt. u
47
4 Ergebnisse
Abbildung 4.8: Aufbau persistenter Visibroker-Objektschlssel u
Unter der Magabe, dass die Erstellungszeit auf einen Tag genau vorhergesagt werden kann und sonst nichts bekannt ist, betrgt die Anzahl a der Mglichkeiten fr Visibroker Objektschlssel: o u u Transiente Objekte (t1 ): 86 106 1, 28 106 10 = 1, 1 1015 35 103 a Persistente Objekte (t2 ): 1, 28 106 times10 = 1, 28 107 = 3, 6h Knnen Aussagen uber die POA-Hierarchie bezglich des Aufbaus bzw. o u der Namen getroen werden, wird der Wertebereich deutlich verkleinert und man bentigt erheblich weniger Zeit. Es erfolgt eine Nherung an die o a Komplexitt der Objektschlssel, wenn bereits eine Interoperable Objekta u referenz bekannt ist und weitere Annahmen wie bei den anderen Untersuchungen27 getroen werden: Objekte am gleichen POA (t3 ): 10 10ms Objekte an anderen POAs (t4,5 ): 1, 28 106 21min Auch hier zeigt sich, dass wenn eine IOR bekannt ist, ein potentielles Sicherheitsproblem besteht.
4.6 Weblogic
Wie bereits beim Visibroker, werden an dieser Stelle zur Redundanzvermeidung nur noch die Endergebnisse vorgestellt. In 3.1.6 wurde dargelegt,
27
Ca. 10% der Objekte eines POAs sind aktiv, maximal 105 Objekte sind vorhanden und die maximale Komplexitt der POA-Hierarchie betrgt 1, 28 106 . a a
48
4 Ergebnisse Tabelle 4.18: Transienter Weblogic Objektschlssel u Zeile 1 2 3 4 5 6 7 8 9 10 11 HEX 00 01 00 17 70 70 00 00 00 01 00 00 F0 BD 49 3A 30 30 00 01 31 URL .BEA........ ............ IDL:HelloApp /Hello:1.0.. ....259..... BEA....6.... ........s... ........RMI: B:000000000 0000000..... 1
00 00 49 2F 00 42 00 7F 5B 30
42 00 44 48 00 45 00 FF 42 30
45 00 4C 65 00 41 00 FF 3A 30
41 00 3A 6C 04 11 00 02 30 30
08 00 48 6C 32 00 00 00 30 30
01 00 65 6F 35 00 00 00 30 30
03 00 6C 3A 39 00 00 00 30 30
00 00 6C 31 00 36 00 18 30 00
00 00 6F 2E 00 00 73 52 30 00
00 00 41 30 00 00 B2 4D 30 00
dass Probleme bei der Erstellung persistenter Objekte und der Portzuweisung der Servants eine umfangreiche Analyse verhinderten und hier nur die transienten Objektschlssel analysiert werden. Tabelle 4.18 zeigt den u Schlssel des zehnten Objektes eines POAs unterhalb des RootPOA. u Aullig ist, dass die RepositoryId (TypeId) im Schlssel vorkommt. Bea u kannt und fast schon erwartet hat man ein ORB-magic, hier BEA. Eine Besonderheit, die sich ohne Quelltext nicht klren lsst, sind die letzten a a acht Bytes der siebten Zeile, hier00 00 00 00 73 B2 F0 BD. Die ersten vier Bytes sind entweder alle 00 oder FF whrend die zweite Hlfte anscheia a nend mit Zufallswerte gefllt wird. Eine Korrelation mit der Zeit konnte u nicht festgestellt werden. Da diese Bytefolge nur pro ORB einmalig ist, erhht dies leicht die Sicherheit. Weshalb die RepositoryId in den Schlssel o u integriert wurde, kann nicht gesagt, historische Grnde drfen aber vermuu u tet werden. Erst in CORBA 2.1 wurde mit IIOP ein Protokoll eingefhrt, u in dem der Objekttyp zu nden ist. In Zeile fnf ist im Klartext ein POAu Zhler mit dem Oset 258 zu nden. Am Ende der vorletzten Zeile steht a die Lnge des Objektzhlers (es wird ORB-weit hochgezhlt) dem der Oba a a jektzhler selbst in ASCII folgt. Gut zu erkennen ist dies in Tabelle 4.19. a
49
4 Ergebnisse Tabelle 4.19: Weblogic Objektzhler a lfd. Objekt 1 2 9 10 99 100 Lnge a 00 00 00 00 00 00 00 00 00 00 00 00 Schlsselteil u 31 32 39 31 30 39 39 31 30 30
00 00 00 00 00 00
01 01 01 02 02 03
Abbildung 4.9: Aufbau transienter Weblogic-Objektschlssel u
Weblogic object keys sind die mit Abstand kompliziertesten. Nicht allein die Grammatik, auch die Erzeugungsvorschriften sind komplex und zeigen die Verschachtelung des Schlssels in sich. Sollte beim Design ein Ziel geu wesen sein, eine Analyse zu verhindern, so ist dies, zumindest teilweise, gelungen. Die Erzeugung der ORB-ID konnte mit legalen Mitteln28 nicht nachvollzogen werden. Trotzdem ist das Erraten eines gltigen Schlssels u u kein unmgliches Unterfangen. Die Anzahl der Mglichkeiten verdeutlicht o o dies: Transiente Objekte (t1 ): 2564 2 50 10 = 4, 3 1012 136a Diese Zahl ergibt sich aus den Annahmen, dass maximal 50 POA existieren, 10 Prozent aller Objekte die getestet werden, aktiv sind und die ORBID zufllig ist. Nimmt man aber an, dass bereits eine IOR bekannt ist, a reduziert sich diese Zahl dramatisch: Objekte am gleichen POA (t3 ): 10 10ms
28
Zu den illegalen Mitteln gehrt reverse engineering bzw. Dekompilieren wie es beio spielsweise mit JAD mglich ist. o
50
4 Ergebnisse Objekte an anderem POA (t4 ): 50 50ms Beim Ausprobieren der einzelnen POA wird davon ausgegangen, dass man bereits beim ersten Zugrisversuch feststellen kann, ob dieser POA existiert. Die gesamte Anzahl mglicher Objekte wird also nur bei lebenden o POA geprft und kme noch hinzu, ist aber meist nicht signikant29 . u a
4.7 WebSphere
WebSphere Objektschlssel unterscheiden Persistenz und Transienz nur u anhand einer Variablen, deshalb treen die folgenden Aussagen auf beiderlei Schlsselarten zu. Sie verfgen uber ein magic, eine einem Zeitstemu u pel hnliche ORB-ID, die POA-Hierarchie und einen Objektzhler. Tabelle a a 4.20 zeigt einen transienten Schlssel am POA null. In Zeile eins sieht u Tabelle 4.20: Transienter WebSphere Objektschlssel u HEX 4C 4D 42 49 00 00 00 16 C6 D6 EB D8 00 15 00 05 04 6E 75 6C 6C 00 04 00 00 00 00 URL LMBI......... ....null...... ......
man die ersten vier Bytes 4C 4D 42 49 - diese sind fr WebSphere Obu jektschlssel spezisch und stellen ein magic dar. Die nachfolgenden vier u Bytes sind die einzigen, wodurch sich grundstzlich persistente und trana siente Objekte unterscheiden lassen. Byte acht ist fr persistente Objekte u 16 und fr transiete 15. Anschlieend folgt die vier Byte lange ORB-ID, u die zufllig erscheint. Die folgenden vier Byte sind jeweils zwei short a zwei a Byte. Der Erste gibt die absolute Startposition des Objektzhlers an und a der Zweite die relative, gemessen ab der Position hinter dieser Angabe, also einschlielich ab Byte 17. Die Dierenz beider Angaben ist immer
29
In diesem Fall doch, da sich die Zeit um 20% erhht. o
51
4 Ergebnisse 0x10. Die zweite Angabe kann man auch als die Gesamtlnge der POAa Hierarchie ansehen, diese folgt nmlich nach folgendem Schema: Lnge des a a POA-Namen (in einem Byte) und der POA-Name selbst, als ASCII Zeichenkette. Beendet wird der Schlssel mit der Lnge des Objektzhlers u a a (zwei Byte) und dem Objektzhler selbst (vier Byte). a
Abbildung 4.10: Aufbau transienter WebSphere-Objektschlssel u
Der WebSphere ORB nutzt einen Groteil der Mechanismen, die ebenfalls von anderen ORB benutzt werden. Da diese bereits vorgestellt wurden, wird an dieser Stelle nicht nher darauf eingegangen. Die Komplexitt a a des Schlssels ergibt sich in der Hauptsache aus einer zuflligen ORB-ID u a und der POA-Hierarchie. Die Anzahl verschiedener Schlssel ist fr: u u Transiente und persistente Objekte (t1,2 ): 2564 1, 28 106 10 = 5, 5times1015 174 105 a
Die bereits in vorherigen Abschnitten getroenen Annahmen, 50 verschiedene POA-Namen in drei Hierarchieebenen und 10 Prozent aktive Objekte, wurden hierbei bercksichtigt. Ist eine Objektreferenz bekannt, muss nur u noch wenig herausgefunden werden: Objekte am gleichen POA (t3 ): 10 10ms Objekte an anderem POA (t4,5 ): 1, 28 106 21m20s Abschlieend kann man sagen, dass auch bei diesem ORB keine echte Sicherheit vorliegt und er sich folglich in die Masse der anderen ORB einreiht.
52
4 Ergebnisse
4.8 Komplexitt der Objektschlssel a u

Die Zahlen in Tabelle 4.21 entsprechen der Anzahl von Mglichkeiten fr o u Objektschlssel. Die Einzelwerte sind dem Fazit der einzelnen ORB entu nommen und hier zusammengefasst. Zur besseren Ubersicht und Vergleichbarkeit bieten sich Komplexittsklassen an Je hher die Klasse, desto a o hher die Komplexitt. Die Klasse spiegelt die Zehnerpotenz wider, die o a die maximale Anzahl der Mglichkeiten reektiert. So gehren 5, 6 109 o o Mglichkeiten in die Klasse 10, da 5, 6 aufgerundet und folglich aus 109 o 1010 wird. Klasse 1 bedeutet, dass die Anzahl der Mglichkeiten hchstens o o 101 = 10 ist. Aus den untersuchten Varianten resultierend, ergeben sich fr u jeden ORB maximal fnf Ergebnisse. Dies resultiert aus den untersuchten u Varianten. Tabelle 4.21: Vergleich der Objektschlsselkomplexitt u a ORB MICO ORBacus Orbix SUN ORB Visibroker Weblogic WebSphere t1 10 17 30 17 15 12 16 t2 16 12 17 7 16 t3 1 1 1 1 1 1 1 t4 3 11 30 6 6 2 6 t5 6 11 6 6 6 t 7,2 10,4 20,3 9,4 7,0 3,0 9,0
t1 Mglichkeiten fr transiente Objektschlssel unter der Annahme, o u u dass nichts bekannt ist. Ist jedoch der POA-Name oder die POAHierarchie Teil des Schlssels, so wurde angenommen, dass es maxiu mal 50 POA-Namen gibt die bekannt und in maximal drei Ebenen miteinander verbunden sind. Ferner ist angenommen, dass 10 Prozent der Objekte am POA aktiv und diese zustzlich uber den Schlssela u raum gleichverteilt sind. t2 Wie t1 , nur fr persistente Objekte. u
53
4 Ergebnisse t3 Verschiedene Mglichkeiten fr Objekte am gleichen POA. 10 Prozent o u der Objekte am POA sind aktiv. t4 Hier ist eine IOR bekannt und es zhlt die Anzahl der Mglichkeiten a o fr andere transiente Objekte an anderen POA. u t5 Wie t4 , nur fr persistente Objekte. u t Der Durchschnittswert der Komplexitt soll hier in einer Zahl zua sammengefasst werden um einen Vergleich zu gewhrleisten Diesem a Anspruch kann dieser Durchschnittswert nur begrenzt gerecht werden, da einerseits Annahmen zu diesen Ergebnissen fhrten und anu dererseits nicht bei allen ORB alle Werte verfgbar waren. u Um den Komplexittsklassen maximal bentigte Zeiten fr das Erraten a o u zuordnen zu knnen, ist diese Beziehung in Tabelle 4.22 dargelegt. Es wird o gezeigt, dass ab Klasse neun ein Erraten sinnlos wird. Mit Klasse 20 wird das Erdalter von 4,6 Milliarden Jahren uberschritten.
54
4 Ergebnisse
Tabelle 4.22: Umrechnung Komplexitt in Zeitaufwand a Komplexittsklasse a 1 2 3 4 5 6 7 8 9 10 11 12 13 15 20 30 Zeitquivalent a 50ms 500ms 5s 50s 8min 80min 13h 6d 58d 578d 16a 158a 1578a 158 Jahrtausende 3,4 Erdenleben 3, 4 1010 Erdenleben
55
Diskussion
In diesem Kapitel wird errtert, ob die in der Einleitung getroene Vermuo tung des illegalen Zugris zutreend ist. Es werden die Komplexitt der a Objektschlssel diskutiert und Lsungen angeboten, die die dargelegten u o Schwachstellen beseitigen knnen. o
5.1 Komplexitt a
Die im Ergebnisteil getroenen Annahmen bezglich der Komplexitt der u a POA-Hierarchien haben auf viele Wahrscheinlichkeiten einen sehr groen Einuss. Gelingt es, diese Variable deutlich zu veringern, so wrden sich u die bentigten Zeiten veringern. Die POA-Komplexitt und die bentigte o a o Zeit fr das Erraten sind linear abhngig. Weiterhin ist diese Komplexitt u a a nur angenommen, Erfahrungen aus der Praxis konnten nicht in die Arbeit integriert werden.
56
5 Diskussion Weiterhin vorhandene Zeitstempel innerhalb der Schlssel knnen, je u o nach praktischer Ausprgung eines Systems, mehr oder weniger gut vora hergesagt werden. Ist beispielsweise bekannt, dass ein ORB am 1.1.2006 1:00 Uhr neu gestartet wurde und dabei alle Dienste neu initialisiert hat, so ist sicher, dass diese Zeitstempel alle auf ein Datum kurz nach dem 1.1.2006 1:00 Uhr zeigen. Die Komplexitt reduziert sich, die Wahrscheinlichkeit a des Erratens erhht sich. Werden keinerlei Zeitstempel oder stringizierte o Daten uber den ORB, POA und das Objekt in den Objektschlssel einu gearbeitet und stattdessen auf andere als die vorgestellten Mechanismen zurckgegrien, ist ebenfalls viel gewonnen. u In Tabelle 4.21 sieht man, dass die Komplexitt der Schlssel stark varia u iert. Dies verwundert insofern, da die meisten ORB die gleichen Mechanismen zur Schlsselerzeugung einsetzen. Orbix geht mit dem Einsatz eines u Hashes fr die POA-Identikation einen eigenen Weg. Dieser ist im Veru gleich zu den anderen ORB auch sicherer, da die Anzahl der notwendigen Versuche um einige Zehnerpotenzen hher liegt. Leider wurde versumt, o a diesen Mechanismus auch fr die Objekte einzusetzen. Der hier immer einu gesetzte Zhler beitet keine Sicherheit und ldt zum Ausprobieren anderer a a Objekte frmlich ein. o Da ein Designziel der meisten ORB die Ausfhrungs- oder Verarbeiu tungsgeschwindigkeit ist, liegt es natrlich nahe, einfache Methoden zur u Schlsselerzeugung zu nutzen. Wichtig ist sicher auch, diese Schlssel wieu u der schnell einem Objekt zuordnen zu knnen. Gleiches trit auch auf die o POA-Hierarchie und den POA zu. Wird der Weg zum zustndigen POA a gleich mit im Schlssel abgelegt, muss kein aufwndiges Listenmanagement u a innerhalb des ORB fr die Zuordnung sorgen. u Es wurden also Designziele bercksichtigt, die Sicherheitskonzepte entu weder vllig ausblendeten oder aber bewusst auf diese verzichteten. o
57
5 Diskussion
5.2 Machbarkeitsstudie
Die fr die Objektschlssel ermittelten Komplexitten lassen vermuten, u u a dass man ohne Vorwissen keinen, mit Vorwissen jedoch schnell und einfach einen Zugri auf ein Objekt erhalten kann. Am Beispiel von MICO wird versucht, eine Angrissoftware zu schreiben, die es ermglicht, Obo jektreferenzen zu generieren und zu testen. Da fr das Aunden weiterer Objekte am selben POA durchweg die u geringste Komplexitt vorliegt, soll dies zuerst versucht werden. Anschliea end sollen Objekte an anderen POA gefunden und uberprft werden. Fr u u dieses Szenario wird das Tool zur Erzeugung der Objektreferenzen derart modiziert, dass der ORB in den Zustand run geschaltet wird und min destens ein weiteres Objekt am selben und eines an einem weiteren POA aktiv sind. Die IOR eines gltigen aktiven Objektes sei gegeben. u Auf der beiliegenden CD bendet sich das Programm iGuess. Es ist ein Java Programm, dass MICO-Objektschlssel erzeugen und ausprobieu ren kann. Wird ein aktives Objekt gefunden, so kann man den Objekttyp ebenfalls testen. Die Anzahl der zu untersuchenden POA und Objekte lsst sich ubergeben. Ein typischer Aufruf mit einer bekannten IOR und a die Programmausgabe sieht wie folgt aus:
$ ./start -mc IOR:010000000e0000004...0000 -o 1000 -p 1000 \ -t IDL:Hello:1.0 ************************************************************* * I Guess - Object Key Guessing Tool * * Version 0.4.3 - (C) christoph.becker@prismtech.com * ************************************************************* found active Object (Obj# 10 POA# 0) corbaloc:iiop:1.0@localhost.localdomain:52501//6323/1158735167/0/_01 Type: IDL:Hello:1.0
********************************* Statistic =========
58
5 Diskussion
Objects to be tested: 1000000 active/tested Objects: 1/1999 active/tested POAs: 1/1000 -------------------------------Time total: 6243ms Time per Object 3ms -------------------------------known Types: 1 Object not exists: 999 Bad Op Exceptions: 0 Object Adapter E.: 999 Comm Failure Ex. : 0 System Exceptions: 0 Other Exceptions : 0 *********************************
Man kann hier deutlich erkennen, dass ein Objekt gefunden werden konnte. Die TypeID entspricht auch dem gesuchten IDL:Hello:1.0. An dieser Stelle knnte man nun mittels eines weiteren Programmes mit dem o gefundenen Objekt interagieren. Die Aufwandsabschtzung mit der im Verlauf dieser Arbeit gerechnet a wurde, hat sich fr groe Testszenarien (mehr als 10000 Objekte) besttigt. u a Die Testzeit von 1ms pro Schlsseltest ist realistisch. u Ob und inwiefern sich Verbesserungen durch Parallelisierung erreichen lassen, wurde nicht geprft. Jedoch ist zu vermuten, dass der ORB, der das u aktive Objekt verwaltet, an seine Leistungsgrenzen stoen wird. Aufgrund der Last, die ein Angri erzeugt, sind ORB auf schnellen (und damit teureren) Rechnern eher angreifbar als ORB auf alten leistungsschwachen Rechnern. Die verfgbare Bandbreite spielt sicher auch eine Rolle, wurde u aber vernachlssigt, da von guter Vernetzung ausgegangen werden kann. a Jede Firma, die verteilte Dienste anbietet oder selbst in Anspruch nimmt, wird sicherstellen, dass diese auch genutzt werden knnen. o In Zukunftz kann iGuess so erweitert werden, dass Angrie auf Schlsu sel parallel und auch fr andere ORB durchgefhrt werden knnen. Ebenu u o falls denkbar ist die direkte Kopplung mit einer bisher nicht vorhandenen Schadfunktion.
59
5 Diskussion
5.3 Lsungsmglichkeiten o o
Die Machbarkeitsstudie zeigt, dass die angenommenen Sicherheitslcken u praktische Relevanz besitzen. Doch wie kann man diese Lcken schlieen u oder die Sicherheit anderweitig erhhen? Muss dafr der ORB gendert o u a werden?
5.3.1 Zeitstempel - Bereichserweiterung

Eine Lsung, die Vernderungen am ORB vornimmt, verbessert den Umo a gang mit Zeitstempeln. Diese werden meist dazu eingesetzt, um den ORB eindeutig identizieren zu knnen. Kein Stempel existiert zwei Mal. Zwei o ORB mit selbem Stempel wurden zwar zur selben Zeit erzeugt, besitzen aber trotzdem unterschiedliche Merkmale wie Host oder Port. Setzt man nun den Zeitstempel im Sekunden oder Millisekundenbereich auf den Nanosekundenbereich um und integriert diese Werte vollstndig in a den Schlssel, dann steigt die Komplexitt, sowohl fr den ORB, als auch u a u fr den POA und gegebenenfalls pro Objekt beachtlich. Sie betrge u u (8, 6 1010 )3 = 6, 4 1032 . Nimmt man nun an, der Zeitrahmen knnte auf fnf Minuten reduziert o u werden, betrgt der Wert immernoch: a (3 108 )3 = 2, 7 1025 Wird eine gltige Objektreferenz bekannt, so htte man fr ein anderes u a u Objekt desselben POA noch 3 108 Mglichkeiten allein fr den Zeitstemo u pel wenn man wieder annimmt, dieses Objekt sei innerhalb von fnf Minuu ten nach dem anderen Objekt erzeugt worden. Fr die Komplexittsklasse u a acht kann ein maximaler Zeitraum von sechs Tagen angenommen werden. Ob das Objekt dann noch existiert? Um das Bekanntwerden eines Zeitstempels im Klartext zu vermeiden und somit die Rckgewinnung von Informationen, wie Startzeit zu verhinu dern, ist der Einsatz von Einwegfunktionen zweckmig. Einerseits wird a
60
5 Diskussion der zur Verfgung stehende Wertebereich besser ausgenutzt, andererseits u wird der besagte Stempel geschtzt. Das einzige Problem, dass auch nach u dieser Modikation besteht, ist die implizite Autorisierung durch den Erhalt einer gltigen IOR. Allerdings bestnde der Zugri dann nur noch auf u u dieses Objekt. Alle anderen Objekte wren durch die hohe Komplexitt a a geschtzt. u
5.3.2 ORB-basiertes Signieren

Wenn Objektreferenzen durch den ORB (bzw. den POA) signiert werden wrden, so ist das Erzeugen anderer Schlssel fr Auenstehende zwar u u u mglich, jedoch ist immer die Signatur falsch und der Zugri kann abgeo wiesen werden. Der Zugri auf das Objekt anhand einer abgefangenen IOR ist aber noch mglich. Um zu verhindern, dass der Aufruf vom Client zum o Server nicht manipuliert wurde, kann eine Verschlsselung oder Signierung u des Datenverkehrs in beide Richtungen helfen. Somit ist zwar das Abhren o und Wiederholen der Nachrichten mglich, eine Datenvernderung wrde o a u aber erkannt werden. Um Replay-Attacken zu vereiteln, muss man uber die Objektreferen zen hinaus Anderungen am ORB vornehmen. Man kann eine Transaktionsnummer einfhren, die in die Objektreferenz einiet und ebenfalls u signiert wird. Wenn diese Transaktionsnummern fortlaufend sind, so darf der Empfnger keine Nachrichten verarbeiten, die eine bereits benutzte a Transaktionsnummer besitzen.
5.3.3 Verschlsselung u
Auch bei CORBA ist Verschlsselung eine gute Idee, besonders wenn die u Informationen uber einen ungesicherten Kanal wie das Internet geschickt werden mssen. Einige OpenSource ORB untersttzen SSL, kommerzielle u u Produkte sind ebenfalls verfgbar. Da beiden Kommunikationspartnern u das Zertikat des Anderen bekannt ist, kann man sogenannte Man-inthe-middle Angrie erkennen und anschlieend wieder eine sichere Lei-
61
5 Diskussion tung herstellen. Diese Lsung geht davon aus, dass beide Partner jederzeit o vertrauenswrdig sind. Ist einer der an der Kommunikation Beteiligten u nicht vertrauenswrdig, so ist es zwar die Verbindung, aber an Sicheru heit wurde nicht viel gewonnen. Nicht vertrauenswrdige Partner wren u a Geschftspartner/-kunden die uber eine Schnittstelle an die eigene Vera waltungssoftware angeschlossen sind und dadurch beispielsweise Nachbe stellungen erhalten oder Ahnliches.
5.3.4 IIOPProxy, IIOPFirewall

Eine Variante zur Erhhung der Sicherheit, ohne Vernderungen am ORB o a vornehmen zu mssen, sind Proxies/Firewalls, die speziell fr CORBA entu u wickelt wurden. In diesen Bereich fallen auch Security Gateways. Dies sind Programme, die den Verkehr von und zu CORBA-Systemen uberwachen und gegebenenfalls unterbinden knnen. Durch Auslesen und Verndern o a der Felder im IIOP-Protokollkopf ist es diesen Programmen mglich, den o Zugri auf Objekte in einfacher Art zu kontrollieren und zu manipulieren. Je nach Produkt knnen sogar einzelne Aufrufparameter begrenzt wero den. Bekannte Vertreter dieser Softwareklasse sind der Xtradyne Domain Boundary Controller (I-DBC) und IONAs Wonderwall. Diese Programme sind im Prinzip beides IIOP-Proxies bzw. Security Application Gateways. Einen etwas lteren Vergleich beider Produkte ndet man bei [Jet01]. a
62
Zusammenfassung
Die Ergebnisse der Arbeit zeigen, dass Objektreferenzen keinesfalls als Capabilities angesehen werden drfen. u Es wurde theoretisch und praktisch nachgewiesen, dass es in wenigen Sekunden bis Stunden mglich ist, gltige Objektreferenzen zu erzeugen o u und diese zu nutzen. Alle sicherheitsrelevanten Implikationen auf Basis dieser Referenzen fhren zu Problemen. Die scheinbare Unvorhersagbarkeit u der herstellerabhngigen Schlssel vermittelt ein Gefhl der Sicherheit. a u u Dieses trgt. u In der Zukunft muss versucht werden, Lsungen, die angeboten wuro den, umzusetzen oder neue, mglicherweise bessere Lsungen zu nden. o o Systemimmanent ist und bleibt ein gewisses Restrisiko. Doch durch den gezielten und vor allem bewussten Einsatz von Schutzprogrammen oder Sicherungsmechanismen, wird einerseits eine gesicherte Umgebung geschaffen und andererseits die Sensibilitt fr Sicherheitsprobleme erhht. a u o
63
6 Zusammenfassung Eine vollkommene Sicherheit gibt es nicht. Sie kann deshalb auch nicht erreicht werden, man kann sich ihr aber nhern. a
64
Anhang
A.1 Quelltextauszge u
A.1.1 IDL - IOP Denitionen
Listing A.1: IOP Modul - Prolcontainer
module IOP { // IDL typedef unsigned long P r o f i l e I d ; struct TaggedProfile { P r o f i l e I d tag ; s e q u e n c e <o c t e t > p r o f i l e d a t a ; }; t y p e d e f s e q u e n c e <T a g g e d P r o f i l e > T a g g e d P r o f i l e S e q ; // an I n t e r o p e r a b l e O b j e c t R e f e r e n c e i s a s e q u e n c e o f // o b j e c t s p e c i f i c p r o t o c o l p r o f i l e s , p l u s a t y p e ID . s t r u c t IOR { string type id ; s e q u e n c e <T a g g e d P r o f i l e > p r o f i l e s ; }; // M u l t i p l e p r o f i l e s would be e n c a p s u l a t e d i n a T a g g e d P r o f i l e . t y p e d e f u n s i g n e d l o n g ComponentId ; s t r u c t TaggedComponent { ComponentId t a g ; s e q u e n c e <o c t e t > c o m p o n e n t d a t a ;
65
A Anhang
}; t y p e d e f s e q u e n c e <TaggedComponent> TaggedComponentSeq ; };
Listing A.2: IIOP IOR Prole

module IIOP { // IDL e x t e n d e d f o r v e r s i o n 1 . 1 , 1 . 2 , and 1 . 3 struct Version { o c t e t major ; o c t e t minor ; }; s t r u c t P r o f i l e B o d y 1 0 {// renamed from P r o f i l e B o d y Version i i o p v e r s i o n ; s t r i n g host ; unsigned short port ; s e q u e n c e <o c t e t > o b j e c t k e y ; }; s t r u c t P r o f i l e B o d y 1 1 {// a l s o u s e d f o r 1 . 2 and 1 . 3 Version i i o p v e r s i o n ; s t r i n g host ; unsigned short port ; s e q u e n c e <o c t e t > o b j e c t k e y ; // Added i n 1 . 1 unchanged f o r 1 . 2 and 1 . 3 s e q u e n c e <IOP : : TaggedComponent> components ; }; };
A.1.2 MICO
Fr diese Arbeit wurde MICO 2.3.12 mit und ohne Security Fix 001 beu nutzt. Der gesammte Quelltext ist auf der beigelegten CD verfgbar. u Listing A.3: MICO: new UniqueId, orb/poa impl.cc
1089 char 1090 MICOPOA : : UniqueIdGenerator : : new id ( ) 1091 { 1092 char i d ; 1093 1094 / 1095 Generate a new u n i q u e i d 1096 / 1097 1098 i f ( u i d == NULL) { 1099 ulen = 1; 1100 u i d = CORBA: : s t r i n g a l l o c ( u l e n ) ; 1101 a s s e r t ( uid ) ; 1102 uid [ 0 ] = 0 ; 1103 uid [ 1 ] = 0 ;
66
A Anhang
1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 } else { int i ; f o r ( i =0; i <u l e n ; i ++) { i f ( u i d [ i ] != 9 ) break ; uid [ i ] = 0 ; } i f ( i == u l e n ) { CORBA: : s t r i n g f r e e ( u i d ) ; u i d = CORBA: : s t r i n g a l l o c (++u l e n ) ; a s s e r t ( uid ) ; f o r ( i =0; i <ulen 1; i ++) { uid [ i ] = 0 ; } u i d [ ulen 1] = 1 ; uid [ ulen ] = 0 ; } else { uid [ i ] = uid [ i ] + 1 ; } } i d = CORBA: : s t r i n g a l l o c ( u l e n + p f x l e n ) ; assert ( id ) ; i f ( p r e f i x ) s t r c p y ( id , p r e f i x ) ; s t r c p y ( i d+p f x l e n , u i d ) ; return i d ; }
Listing A.4: MICO: transient prex

49 50 51 52 53 54 55 56 57 58 59 60 61 62 // l i n e 20712081 i n s i d e RootPOA c o n s t r u c t o r / Generate a u n i q u e p r e f i x f o r t r a n s i e n t POAs b a s e d on t h e PID and t h e c u r r e n t time . / OSMisc : : TimeVal c t = OSMisc : : g e t t i m e ( ) ; o a p r e f i x = / ; o a p r e f i x += xdec ( OSMisc : : g e t p i d ( ) ) ; // cb : p r o c e s s i d o a p r e f i x += / ; o a p r e f i x += xdec ( c t . t v s e c ) ; // cb : system time i n s
67
A Anhang
63 64 65 66 67 68 69 70 // l i n e 208389 / The Root POA has a TRANSIENT L i f e s p a n P o l i c y . T h e r e f o r e , use / <pid > / <time> as t h e u n i q u e name / oaid = oaprefix ;
68
A Anhang
A.2 Aufbau der Objektschlssel u

A.2.1 MICO
Folgende Denitionen sind bei der Betrachtung der EBNF-Darstellung der Objektschlssel zu beachten: timeorb ist die Anzahl der Sekunden nach dem 1.1.1970. u Dieser Wert ist in der URL-Form im Klartext lesbar. Eine ascii-number ist der HEX-Wert einer Zier im ASCII-Format. Die Null entspricht der 0x30, die Eins der 0x31 und so weiter. s ist ein Seperator. poa-h entspricht der POA-Hierarchie mit poa als einzelnen POA-Namen, in dieser Arbeit oftmals null, einseins usw. bezeichnet. timepoa entspricht ebenfalls der Sekunden seit Beginn der UNIX-Ara, wird aber direkt in die HEX-Darstellung umgewandelt, typische Werte beginnen mit 0x44, 0x45. Der Objektzhler object# zhlt im Hexadezimalsystem die Ana a zahl der jemals an diesem POA aktivierten Objekte hoch. Diese Hinweise gelten nicht ausschlielich fr MICO, sie wurden nur beispielhaft u an ihm erklrt. a
Transient
<MICO-tkey> <process-id> <s1 > <zahl> <zifferOhneNull> <ziffer> <timeorb > <poa> <s2 > <object#> ::= <process-id> <timeorb > <poa> <object#>; ::= ::= ::= ::= ::= ::= ::= ::= ::= <s1 > <zahl>; "/"; <zifferOhneNull> { <ziffer> } "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"; "0"| <zifferOhneNull>; <s1 > <zifferOhneNull>, 9 * <ziffer>; <s1 > <ziffer> { <ziffer> }; "/ "; <s2 > <ziffer> { <ziffer> };
69
A Anhang Persistent
<MICO-pkey> <orb> <s1 > <poa-h> <poa> <s2 > <object#> <timeorb > <process-id> <s3 >
a
::= <orb> <poa-h> <process-id> <time orb > <object#>; ::= ::= ::= ::= ::= ::= ::= ::= ::= <ascii-zeichen>a { <ascii-zeichen> } <s1 >; "/"; <poa> { <s1 > <poa> }; <ascii-zeichen> { <ascii-zeichen> } <s 2 > ; "%5C"b , <s1 >; <ziffer> { <ziffer> }; <ziffernOhneNull> 9 * <ziffer> <s2 >; <zahl>c <s2 >; "/ ";
Auf die Darstellung aller ASCII Zeichen ist an dieser Stelle zu Gunsten der Ubersichtlichkeit verzichtet worden. b Der Aufbau folgt der URL-Form. Ausdrcke wie %5C deuten auf einen nicht daru stellbares Byte hin, dessen Hexwert statt dessen benutzt wird. c Denition im vorherigen Abschnitt.
A.2.2 ORBacus
Transient
<ORBacus-tey> ::= <magicorb > <timeorb > <poa-h> <magicjava > <timepoa > <object#>; "AB AC AB 30"; 10 * <ascii-number>; "30"|"31"|"32"|"33"|"34"|"35"|"36"|"37"| "38"|"39"; "5F"; <s> <poa> { <nullbyte> <poa> } 2 * <nullbyte>; <ascii-zeichen>1 ; 4 * <byte>2 ; "00"; 4 * <byte>; "CA FE BA BE";
<magicorb > <timeorb > <ascii-number> <s> <poa-h> <poa> <timepoa > <nullbyte> <object#> <magicjava >
::= ::= ::= ::= ::= ::= ::= ::= ::= ::=
70
A Anhang Persistent
<ORBacus-pkey> <magicorb > <s> <poa-h> <poa> <timepoa > <nullbyte> <object#> <magicjava >
a
::= ::= ::= ::= ::= ::= ::= ::= ::=
<magicorb > <poa-h> <magicjava > <timepoa > <object#>; "AB AC AB 30"; "00 5F"; <s> <poa> { <nullbyte> <poa> } 2 * <nullbyte>; <ascii-zeichen>a ; 4 * <byte>; "00"; 4 * <byte>; "CA FE BA BE";
Auf die Darstellung aller ASCII Zeichen ist auch an dieser Stelle verzichtet worden.
A.2.3 Orbix
<Orbix-key> <magicorb > <poapolicy > <lenpolicy > <poa-id> <lenpoaid > <object#> <lenobject# >
a b
::= ::= ::= ::= ::= ::= ::= ::=
<magicorb > <poapolicy > <poa-id> <object#>; "3A 3E"; <lenpolicy >, "31 31"|"31 32"a ; "02"; <lenpoaid >, 12 * <byte>b ; "0C"; <lenobject# >, 8 * <byte>c ; "08";
Je nachdem, ob der POA persistente oder transiente Objekte verwaltet. Es handelt dich oensichtlich um eine Zufallsfolge. c Als ein bei Null beginnender, inkrementierender Zhler. a
71
A Anhang
A.2.4 SUN-ORB
<Sun5-tkey> ::= <magicorb > <poaltpolicy > <orb-id> <const1 > <poa-h> <object#> <const2 >; "AF AB CD 00";a "00 00 00", "20"|"22"; 4 * <byte>; "00 00 00 01 00 00 00 00"; <poadeep > <poa> { <poa> }; 4 * <byte>; <poastrlen > <poaname >; 4 * <byte>; <ascii-char> { <ascii-char> }; <lenobject# > 8 * <byte> <const2 >; "08"; "14";b
<magicorb > <poaltpolicy > <orb-id> <const1 > <poa-h> <poadeep > <poa> <poastrlen > <poaname > <object#> <lenobject# > <const2 >
a b
::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::=
In Java 1.4.x betrug dieser Wert AF AB CB 00. In Java 1.4.x betrug dieser Wert 0A.
A.2.5 Visibroker
Transient
<VB-tkey> <magicorb > <poa-h> <poa> <poaname > <object#> <lenobject# > <timepoa > <t1 > <t2 > ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= <magicorb > <poa-h> <object#> <timepoa >; "00 56 42 01"; <lenpoah > <poa> { <poa> }; "2F" <poaname >; <ascii-char> { <ascii-char> }; <lenobject# > 4 * <byte>; "00 00 00 04"; <t1 > <t2 >; 4 * <byte>; 4 * <byte>;
Persistent
<VB-pkey> <magicorb > <const> <poa-h> <poa> <poaname > <object#> <lenobject# > ::= ::= ::= ::= ::= ::= ::= ::= <magicorb > <const> <poa-h> <object#> ; "00 56 42 01"; "00 00 00 04"; <lenpoah > <poa> { <poa> }; "2F" <poaname >; <ascii-char> { <ascii-char> }; <lenobject# > 4 * <byte>; "00 00 00 04";
72
A Anhang
A.2.6 Weblogic
Zusammenfassend ergibt sich folgender Schlsselaufbau: u <WL-tkey> ::= <magicorb1 > <const1 > <IDL> <poa> <magicorb2 > <lenpart2 > <const2 > <orb-id> <const3 > <object#>; <magicorb1 > ::= "00 42 45 41"; <const1 > ::= "08 01 03 00 00 00 00 01"8 * <nullbyte>; <nullbyte> ::= "00"; <IDL> ::= <lenIDL > <type> <nullbyte>; <lenIDL > ::= 4 * <byte>; <type> ::= DL:" <ascii-char> { <ascii-char> }; I <poa> ::= <lenpoa# > <poa#>; <poa#> ::= <zifferOhneNull> { <ziffer> }; <magicorb2 > ::= "42 45 41 11"; <lenpart2 > ::= 4 * <byte>; <const2 > ::= 8 * <nulbyte>; <orb-id> ::= "00 00 00 00"|"FF FF FF FF", 4 * <byte>;; <const3 > ::= "7F FF FF 02 rmi>; <rmi> ::= "00 00 00 18 52 4D 49 3A 5B 42 3A 30 30 30", "30 30 30 30 30 30 30 30 30 30 30 00"; <object#> ::= <lenobject# > <zifferOhneNull> { <ziffer> };
A.2.7 WebSphere
Der Aufbau in EBNF: <WB-key> ::= <magicorb > ::= <LC-policy> ::= <poa-h> ::= <lenprefix > ::= <lenpoah > ::= <poa> ::= <lenpoa ::= <poaname > ::= <object#> ::= <lenobject# > ::= <magicorb > <LC-policy> <poa-h> <object#>; "4C 4D 42 49"; "00 00 00 15"|"00 00 00 16"; <lenprefix > <lenpoah > <poa> { <poa> }; 2 * <byte>; 2 * <byte>; <lenpoa > <poaname >; <byte>; <ascii-char> { <ascii-char> }; <lenobject# > 4 * <byte>; "00 04";
73
Erklrung a
Ich erklre, diese Arbeit selbststndig angefertigt und die benutzten Una a terlagen vollstndig angegeben zu haben. a
Berlin, 20. September 2006
Christoph Becker
74
Literaturverzeichnis
[Bec06]
Christoph Becker.
Vorhersage von Objektidentikationen in
CORBA, February 2006. Studienarbeit. [BS02] Gerald Brose and Sebastian Staamann. Application Security Gateways: Eine Komplettlsung fr die Sicherheit von Applikao u tionsservern. Objektspektrum, pages 5053, July 2002. [BVD01] Gerald Brose, Andreas Vogel, and Keith Duddy. Java Programming with CORBA. Wiley, 3rd edition, 2001. [Eck06] Claudia Eckert. IT-Sicherheit: Konzepte Verfahren Protokolle. Oldenbourg, 2006. [HJS01] Johann Hofmann, Fritz Jobst, and Roland Schabenberger. Programmieren mit COM und CORBA. Hanser, 2001. [Jet01] Thomas Jetzler. IIOP rewalls. Masters thesis, University of Zurich, July 2001. [Kli00] William Ruh; Thomas Herron; Paul Klinker. IIOP Complete - Understanding CORBA and Middleware Interoperability. Addison-Wesley, 2000.
75
Literaturverzeichnis [OMG04] Object Management Group OMG. Common object re-
quest broker architecture: Core specication, version 3.0.3. http://www.omg.org, March 2004. formal document 04-03-01. [Say97] Michael Sayegh. CORBA - Standard, Spezikationen, Entwicklung. OReilly Verlag, Kln, 1997. o [SB06] Sebastian Staamann and Christoph Becker. Using corba object references as authorization tokens using a good idea or not? http://www.omg.org/news/meetings/workshops/, February 2006. Realtime Workshop, Arlington. [Sie96] Jon Siegel. CORBA - Fundamentals ans Programming. Wiley, 1996. [TvS03] Andrew S Tanenbaum and Maarten van Steen. Verteilte Systeme: Grundlagen und Paradigmen. Addison Wesley, 2003.
76

Analyse Der Sicherheit Impliziter Autorisierung Durch Referenzenvergabe Bei CORBA Object Request Brokern

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Analyse Der Sicherheit Impliziter Autorisierung Durch Referenzenvergabe Bei CORBA Object Request Brokern

Hochgeladen von

Copyright:

Verfügbare Formate

Diplomarbeit

Institut fr Angewandte Mikroelektronik und Datentechnik u Universitt Rostock a

Inhaltsverzeichnis 4.7 4.8 WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . Komplexitt der Objektschlssel . . . . . . . . . . . . . . . a u 51 53 56 56 58 60 63 65 65 69

5 Diskussion 5.1 5.2 5.3 Komplexitt . . . . . . . . . . . . . . . . . . . . . . . . . . . a Machbarkeitsstudie . . . . . . . . . . . . . . . . . . . . . . . Lsungsmglichkeiten . . . . . . . . . . . . . . . . . . . . . o o

6 Zusammenfassung A Anhang A.1 Quelltextauszge . . . . . . . . . . . . . . . . . . . . . . . . u A.2 Aufbau der Objektschlssel . . . . . . . . . . . . . . . . . . u

4.10 Orbix Objektschlsselabschnitte u

Tabellenverzeichnis 4.22 Umrechnung Komplexitt in Zeitaufwand . . . . . . . . . . a 55

4.10 Aufbau transienter WebSphere-Objektschlssel . . . . . . . u

1.1 Thematischer Hintergrund

engl.: distributed computing

1.2 Motivation und Zielstellung

1.3 Gliederung der Arbeit

2.1 Was ist CORBA

Abbildung 2.1: Scheinbarer und tatschlicher Weg eines Objektaufrufs a

Abbildung 2.2: Aufbau einer Interoperablen Objektreferenz

Das Beispiel ist ktiv.

http://de.wikipedia.org/wiki/Autorisierung, Stand 09:54, 20. Jul 2006

2.3.3 Verbindung zu CORBA

Abbildung 2.3: Komponenten der corbaloc-URL

Dies wird oft auch als security by obscurity bezeichnet. http://www.bastille-linux.org/jay/obscurity-revisited.html

2.5 Bestehende Lsungen o

Betrit Mico 2.3.12 ohne Security Fix 001.

Erst zweifeln, dann untersuchen, dann entdecken. Henry Thomas Buckle

Material, Methoden und Werkzeuge

3.1 Betrachtete Produkte

http://www.objectsecurity.com http://www.opengroup.org/press/7jun99 a.htm 3 http://www.iona.com

3 Material, Methoden und Werkzeuge

3.1.4 Sun JDK

Java Platform Enterprise Edition Siehe http://en.wikipedia.org/wiki/WebSphere Application Server, 25.08.2006

3 Material, Methoden und Werkzeuge

Abbildung 3.1: Anordnung der POA

3 Material, Methoden und Werkzeuge

Abbildung 4.1: Aufbau transienter MICO-Objektschlssel u

4.1.2 Persistente Objekte

Abbildung 4.2: Aufbau persistenter MICO-Objektschlssel u

4.2.1 Transiente Objekte

07 6E) in Dezimaldarstellung, so erhlt man 1146423150. Beachtet man a

Abbildung 4.3: Aufbau transienter ORBacus-Objektschlssel u

Die vollstndige und detailliertere Darstellung bendet sich ebenfalls im a Anhang.

4.2.2 Persistente Objekte

tenter ORBacus Objektschlssel kann nach folgender Bildungsvorschrift u

4 Ergebnisse erzeugt werden:

Abbildung 4.4: Aufbau persistenter ORBacus-Objektschlssel u

5 60 1, 28 106 = 3, 8 108 3, 8 108 1000 3600 24 = 4, 444d

Jeweils Byte sieben bis 18 Byte.

Abbildung 4.5: Aufbau Orbix-Objektschlssel u

4.4 Sun ORB

Siehe Tabelle 4.12

In Datei com/sun/corba/se/impl/orbutil/ORBConstants.java, Zeile 87f.

Abbildung 4.6: Aufbau von SUN-ORB Objektschlsseln u

Bezogen auf den Schlsselaufbau. u

Tabelle 4.16: Persistenter Visibroker Objektschlssel u HEX 00 50 4D 43 00 00 00 04 00 00 00 06 2F 6E 75 6C 6C 00 20 20 00 00 00 04 00 00 00 00 URL .PMC......../ null......... ..

Abbildung 4.7: Aufbau transienter Visibroker-Objektschlssel u

Die Hexadezimalwerte wurden in das Dezimalsystem uberfhrt. u

Abbildung 4.8: Aufbau persistenter Visibroker-Objektschlssel u

Abbildung 4.9: Aufbau transienter Weblogic-Objektschlssel u

In diesem Fall doch, da sich die Zeit um 20% erhht. o

Abbildung 4.10: Aufbau transienter WebSphere-Objektschlssel u

4.8 Komplexitt der Objektschlssel a u

********************************* Statistic =========

5.3.1 Zeitstempel - Bereichserweiterung

5.3.2 ORB-basiertes Signieren

5.3.4 IIOPProxy, IIOPFirewall