1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Linuxtag-Keynote: Lehren aus…

Programmiersprachen C und C++ == Grundsätzliches Problem

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: BRDiger 10.05.14 - 17:41

    >Auch in den Programmiersprachen C und C++ sehen Lindner und Kopf ein grundsätzliches
    > Problem. C-Code ohne Buffer Overflows oder andere Fehler in der Speicherverwaltung zu
    >schreiben, sei fast unmöglich. Deswegen solle sicherheitskritischer Code in
    >Programmiersprachen geschrieben werden, die derartige Speicherprobleme von
    >vornherein verhindern.

    Welche Sprache stellen, sich die Herren denn vor? Java?
    Übrigens finde ich die Behauptung "C-Code ohne Buffer Overflows oder andere Fehler in der Speicherverwaltung zu schreiben, sei fast unmöglich" schon mehr als eigenartig.

    Was sagt ihr dazu?

  2. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: muh3 10.05.14 - 18:11

    BRDiger schrieb:
    --------------------------------------------------------------------------------
    > >Auch in den Programmiersprachen C und C++ sehen Lindner und Kopf ein
    > grundsätzliches
    > > Problem. C-Code ohne Buffer Overflows oder andere Fehler in der
    > Speicherverwaltung zu
    > >schreiben, sei fast unmöglich. Deswegen solle sicherheitskritischer Code
    > in
    > >Programmiersprachen geschrieben werden, die derartige Speicherprobleme von
    >
    > >vornherein verhindern.
    >
    > Welche Sprache stellen, sich die Herren denn vor? Java?

    naja aufjedenfall eine welche direkt in Maschinencode compiliert. Und genau da liegt das Problem. Eine Sprache welche keine VM hat, hat das gleiche Problem wie C. Da ist die Sprache letztendlich egal. Wenn der C-Compiler sich nicht um den Speicherschutz kümmern kann, warum sollte das ein anderer Compiler können?

    Vielleicht Vala? compiliert in C. Vielleicht kann man auf der Ebene etwas einbauen.

    Ich denke das sollte Aufgabe des OS bzw. der CPU sein auf den Speicher aufzupassen.
    (Ich denke unter 64Bit übernimmt das sogar die CPU, bzw. mit PAE)

    > Übrigens finde ich die Behauptung "C-Code ohne Buffer Overflows oder andere
    > Fehler in der Speicherverwaltung zu schreiben, sei fast unmöglich" schon
    > mehr als eigenartig.
    >
    > Was sagt ihr dazu?

    "fast unmöglich" ist natürlich verwaschen ;)
    aber man glaubt garnicht wieviel Bugs allein schon in einem 3-Zeiler drin sein können.
    Außerdem ist man ja auch noch von der Qualität der Standardbibliotek abhängig.
    Ein großes Problem an C ist auch noch, dass es hunderttausend Jahre alt ist.
    Es ist richtig schwer herrauszufinden was in C "best practise" ist. Mit jeder Version werden alte Funktionen durch neue (sicherere) ersetzt aber die alten nicht deprecated.
    (im Web findet man ja meistens auch nur Halbwissen)
    Es gibt 20 Möglichkeiten Text auszugeben, da blickt niemand mehr durch.
    Mit printf kann man sich den Stack ausgeben lassen und trotzdem lässt es sich compilieren. Deswegen gibts eben eine sicherere Alternative, und noch eine und noch eine...
    Sowas macht auch den Compiler unnötig kompliziert und natürlich macht der dann Fehler.
    Außerdem haben ja die Geheimdienste seit Jahrzehnten bei soetwas die Finger im Spiel ;)

    Und ja, unter 32-Bit halte ich die Aussage "fast unmöglich" für wahr.

    P.S.: ich habe übrigens kaum Ahung von dem Thema



    1 mal bearbeitet, zuletzt am 10.05.14 18:13 durch muh3.

  3. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: LucifersChild 10.05.14 - 18:46

    Es gibt zahlreiche Sprachen mit Maschinencode-Compiler, die die Probleme mit der expliziten Speicherverwaltung nicht aufweisen (historisch ist da z.B. Pascal zu nennen). C wird deshalb verwendet, weil es historisch im Unix-Umfeld praktisch alle einsetzen. Das heisst nicht, dass es eine sichere Wahl ist. Als Argument für C gilt eher die Performance, jedoch ist das heutzutage (und wenn man Java/PHP/Python... als die Alternative sieht) eigentlich nicht mehr relevant. Wenn man in C sehr sicher programmiert, ist es eben auch nicht mehr so schnell.

  4. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: grorg 10.05.14 - 18:51

    BRDiger schrieb:
    --------------------------------------------------------------------------------
    > Welche Sprache stellen, sich die Herren denn vor? Java?
    http://de.wikipedia.org/wiki/Ada_(Programmiersprache)

  5. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: LucifersChild 10.05.14 - 18:52

    BTW sind viele Interpreter-Sprachen (z.B. JavaScript) und insbesondere auch Java selbst in C geschrieben. Wenn man großes Glück hat, ist es C++ oder Objective C, aber auf jeden Fall etwas, das auf möglichst vielen Computer-Architekturen zur Verfügung steht.

    Die Verwendung von Java oder JavaScript bietet also einen kleinen Sicherheitsvorteil, weil der Code relativ stabil und gut maintained ist, jedoch hat man dennoch die Probleme von C am Hals (insbesondere, wenn man nicht etablierte Erweiterungen/VMs/Browser verwendet).

  6. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: Paykz0r 10.05.14 - 19:25

    BRDiger schrieb:
    --------------------------------------------------------------------------------
    > >Auch in den Programmiersprachen C und C++ sehen Lindner und Kopf ein
    > grundsätzliches
    > > Problem. C-Code ohne Buffer Overflows oder andere Fehler in der
    > Speicherverwaltung zu
    > >schreiben, sei fast unmöglich. Deswegen solle sicherheitskritischer Code
    > in
    > >Programmiersprachen geschrieben werden, die derartige Speicherprobleme von
    >
    > >vornherein verhindern.
    >
    > Welche Sprache stellen, sich die Herren denn vor? Java?
    > Übrigens finde ich die Behauptung "C-Code ohne Buffer Overflows oder andere
    > Fehler in der Speicherverwaltung zu schreiben, sei fast unmöglich" schon
    > mehr als eigenartig.
    >
    > Was sagt ihr dazu?

    das ist nicht nur übertrieben sondern auch inkorrekt.
    ich kannte ein gameboy advanced entwickler der komplett auf
    allokation verzichtete (aus performance gründen)
    das war urhässliger code aber speicherprobleme waren da ausgeschlossen.
    gegen bufferoverflows helfen tests.

    und auch java vms können overflows in deren code haben.
    nix ist sicher.

  7. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: BRDiger 10.05.14 - 19:38

    LucifersChild schrieb:
    --------------------------------------------------------------------------------
    > Als Argument für C gilt eher die Performance, jedoch ist
    > das heutzutage (und wenn man Java/PHP/Python... als die Alternative sieht)
    > eigentlich nicht mehr relevant. Wenn man in C sehr sicher programmiert, ist
    > es eben auch nicht mehr so schnell.

    Ja das sagt man dauernd und irgendwann habe ich sogar dran geglaubt, als ich es zum 1000. mal gehört habe aber trotzdem erlebe ich immer wieder, dass *simpelste* Anwendungen in Java meine CPU vergewaltigen. Darin willst du auch noch Krypto-Algorithmen implementieren?
    Sehr merkwürdig, dass einfachste Java-Anwendungen die Systemlast in ungeahnte Höhen schnellen lassen.

    @muh3:

    Deine Kritik an C kann ich irgendwie nicht ganz nachvollziehen - nenne doch mal noch ein paar Funktionen außer printf(). Das Problem mit printf() tritt übrigens nur bei falscher Benutzung auf. (format string vulnerability)

    Ich finde bei Dingen wie *Kryptographie* sollte man schon Sprachen benutzen, die in Maschinencode kompilieren.

    Ich werde nie verstehen, wie man immer über C und C++ herzieht, weil es soooo unsicher ist. Ja vermutlich machen selbst die besten C/C++-Programmierer Fehler aber das Gute an C ist z.B. dass es ziemlich schnell ist und auf so gut wieder Architektur verfügbar ist und man muss keiner VM oder einem Interpreter trauen. Wann gibts schon mal Sicherheitslücken in binaries die durch den gcc (oder clang) verursacht wurden? In Interpretern oder VMs gibts hingegen öfter mal Lücken und die Geschwindigkeit ist auch noch so eine Sache....

  8. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: BRDiger 10.05.14 - 19:41

    Paykz0r schrieb:
    --------------------------------------------------------------------------------
    > BRDiger schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > >Auch in den Programmiersprachen C und C++ sehen Lindner und Kopf ein
    > > grundsätzliches
    > > > Problem. C-Code ohne Buffer Overflows oder andere Fehler in der
    > > Speicherverwaltung zu
    > > >schreiben, sei fast unmöglich. Deswegen solle sicherheitskritischer
    > Code
    > > in
    > > >Programmiersprachen geschrieben werden, die derartige Speicherprobleme
    > von
    > >
    > > >vornherein verhindern.
    > >
    > > Welche Sprache stellen, sich die Herren denn vor? Java?
    > > Übrigens finde ich die Behauptung "C-Code ohne Buffer Overflows oder
    > andere
    > > Fehler in der Speicherverwaltung zu schreiben, sei fast unmöglich"
    > schon
    > > mehr als eigenartig.
    > >
    > > Was sagt ihr dazu?
    >
    > das ist nicht nur übertrieben sondern auch inkorrekt.
    > ich kannte ein gameboy advanced entwickler der komplett auf
    > allokation verzichtete (aus performance gründen)
    > das war urhässliger code aber speicherprobleme waren da ausgeschlossen.
    > gegen bufferoverflows helfen tests.
    >
    > und auch java vms können overflows in deren code haben.
    > nix ist sicher.

    Das trifft es wirklich sehr gut.
    Komplett ohne Allokationen? Ich kanns mir ganz gut vorstellen aber kommt
    man wirklich *komplett* ohne Allokationen aus? Klingt krass und wirklich "urhässlich"^^

  9. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: kazhar 10.05.14 - 20:07

    Ja, kann man machen.
    Aber nur, wenn man sich SEHR sicher ist, dass man der einzige Nutzer des RAM Bereichs ist.

    Unter WinXP konnte man so als Treiber den Speicher über 3,Trallala GB ansprechen - und zwar bis 64 GB wenn ich mich recht erinnere.
    Blöd nur, wenn man in dem Speicherbereich der internen Grafik erwischt...

  10. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: BRDiger 10.05.14 - 20:38

    Kann das noch jemand *genauer* ausführen? Wie genau kommt man in C ohne explizite Allokationen aus? Stelle mir da nur sehr kruden Code vor....

  11. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: barforbarfoo 10.05.14 - 21:09

    BRDiger schrieb:
    --------------------------------------------------------------------------------
    > Kann das noch jemand *genauer* ausführen? Wie genau kommt man in C ohne
    > explizite Allokationen aus? Stelle mir da nur sehr kruden Code vor....

    C läuft auf Maschinen ohne Betriebssystem.

  12. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: Dumpfbacke 10.05.14 - 21:10

    BRDiger schrieb:
    --------------------------------------------------------------------------------
    > Übrigens finde ich die Behauptung "C-Code ohne Buffer Overflows oder andere
    > Fehler in der Speicherverwaltung zu schreiben, sei fast unmöglich" schon
    > mehr als eigenartig.
    >
    > Was sagt ihr dazu?
    Eigentlich nicht, da meistens nicht sauber überprüft wird, ob bei einem String die Länge passt. Kannst auch gerne mal einen Variable von x Bytes reservieren und y Bytes (größer als die Variable) auslesen und schauen, was passiert. Wenn der Compiler "dumm" ist, klappt es und du hast irgendwie Schrott ausgelesen. ;)
    Oder bau ein Array, nimm einen Pointer und geh damit den Array durch und dann einfach +1. Mal gucken, was dann passiert.

    http://de.wikipedia.org/wiki/Zeiger_%28Informatik%29
    mfg

  13. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: bstea 10.05.14 - 21:26

    Hast wohl nie in Pascal programmiert?

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  14. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: __destruct() 10.05.14 - 21:27

    Paykz0r schrieb:
    --------------------------------------------------------------------------------
    > gegen bufferoverflows helfen tests.

    Der Angreifer findet dann eine Situation, die nicht getestet wurde. Sowas kann immer vorkommen.

  15. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: bstea 10.05.14 - 21:36

    Wozu brauchst du denn malloc? Dein Programm stattet mit einem hohen Speicherverbrauch wegen stat. Arrays, die du dann nutzt.
    Den Quark dass dann nur ein Programm gleichzeitig laufen darf, ist nat. Mumpitz.
    Für die Emulation ist es generell recht sinnlos etwas dyn. zu machen, da bleibt der Speicher nach dem einlesen des Moduls konstant, da wächst nix bzw. verkleinert sich.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  16. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: Paykz0r 10.05.14 - 23:23

    BRDiger schrieb:
    --------------------------------------------------------------------------------
    > Paykz0r schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > BRDiger schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > >Auch in den Programmiersprachen C und C++ sehen Lindner und Kopf ein
    > > > grundsätzliches
    > > > > Problem. C-Code ohne Buffer Overflows oder andere Fehler in der
    > > > Speicherverwaltung zu
    > > > >schreiben, sei fast unmöglich. Deswegen solle sicherheitskritischer
    > > Code
    > > > in
    > > > >Programmiersprachen geschrieben werden, die derartige
    > Speicherprobleme
    > > von
    > > >
    > > > >vornherein verhindern.
    > > >
    > > > Welche Sprache stellen, sich die Herren denn vor? Java?
    > > > Übrigens finde ich die Behauptung "C-Code ohne Buffer Overflows oder
    > > andere
    > > > Fehler in der Speicherverwaltung zu schreiben, sei fast unmöglich"
    > > schon
    > > > mehr als eigenartig.
    > > >
    > > > Was sagt ihr dazu?
    > >
    > > das ist nicht nur übertrieben sondern auch inkorrekt.
    > > ich kannte ein gameboy advanced entwickler der komplett auf
    > > allokation verzichtete (aus performance gründen)
    > > das war urhässliger code aber speicherprobleme waren da ausgeschlossen.
    > > gegen bufferoverflows helfen tests.
    > >
    > > und auch java vms können overflows in deren code haben.
    > > nix ist sicher.
    >
    > Das trifft es wirklich sehr gut.
    > Komplett ohne Allokationen? Ich kanns mir ganz gut vorstellen aber kommt
    > man wirklich *komplett* ohne Allokationen aus? Klingt krass und wirklich
    > "urhässlich"^^

    jo klar. aber vermutlich nur auf solchen geräten ohne betriebsystem usw.
    legst einfach ein globales array mit fester grösse an
    und nutzt den speicher einfach.
    oder halt ein riesen struct wo alles drin aufgeteilt ist.

    immerhin konnte dem code nie der speicher ausgehen,
    er musste nie den ram nach freien blöcken durchsuchen,
    keine garbage collection, nix.

    für manche spiele passte das so.
    auch die grafiken konnte man sich direkt rein linken wenn man bock hatte.
    aber das ist halt echt nix was ich irgend jemanden empfehlen würde.
    eigentpich sollte ich den vorgang nicht mal beschreiben xD

  17. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: Paykz0r 10.05.14 - 23:27

    __destruct() schrieb:
    --------------------------------------------------------------------------------
    > Paykz0r schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > gegen bufferoverflows helfen tests.
    >
    > Der Angreifer findet dann eine Situation, die nicht getestet wurde. Sowas
    > kann immer vorkommen.

    auf jeden fall.
    ich sag ja: nichts ist sicher.

    ich errinnere mich an den gloreichen wii hack,
    wo man im savegame von zelda das pferd von ihn nur
    ein längeren namen als vorgesehen verpassen musste
    und schon landete die wii auf der nase und frass den binärcode
    der dahinter lag.

    theoretisch müsste man alle werte immer auf erwartete inhalte prüfen und und und.
    überall und bedingungslos.
    das wäre eine scheissarbeit und kaum wartbar

  18. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: __destruct() 10.05.14 - 23:30

    Also helfen Testst doch nicht gegen Bufferoverflows.

  19. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: Julius Csar 10.05.14 - 23:57

    Für sicherheitskritische Anwendungen wäre (Object) Pascal als Programmiersprache sicherlich eine bessere Wahl.

    Auszug aus Wikipedia:
    "Heute findet Pascal [...] in sicherheitskritischen Bereichen (z. B. Verkehrstechnik, Energieversorgung, Medizintechnik, Raumfahrt, Militär, teilweise im Banken- und Versicherungswesen) Anwendung. Dies beruht hauptsächlich auf der guten Prüfbarkeit und Wartbarkeit des Codes und der klaren Zuordnung der Variablen. So ist die 2005 eingeführte Betriebsleittechnik IV der Transrapid-Versuchsanlage Emsland in Pascal programmiert. [...] es seien hier die Typstrenge, hohe Fehlersicherheit und frei verfügbare portierbare Pascalcompiler (Free Pascal, GNU Pascal) genannt"

    Einige Unterscheide zu C:
    * Sehr hohe Prozesssicherheit
    * Keine nullterminierten Zeichenketten
    * Strikte Trennung zwischen Programm, Funktionen und Prozeduren
    * Deklarationen
    * Strenge Typentrennung



    2 mal bearbeitet, zuletzt am 11.05.14 00:00 durch Julius Csar.

  20. Re: Programmiersprachen C und C++ == Grundsätzliches Problem

    Autor: Flexy 11.05.14 - 01:45

    BRDiger schrieb:

    > Welche Sprache stellen, sich die Herren denn vor? Java?
    > Übrigens finde ich die Behauptung "C-Code ohne Buffer Overflows oder andere
    > Fehler in der Speicherverwaltung zu schreiben, sei fast unmöglich" schon
    > mehr als eigenartig.
    >
    > Was sagt ihr dazu?


    Ich würde Ada vorschlagen.
    Das ist nebenbei auch die Sprache, die man mittlerweile in sicherheitskritischen Bereichen derzeit meist einsetzt, also in der Medizintechnik, in der Raumfahrt, in der Luffahrt usw. und eben beim Militär usw.
    Der Vorteil ist, dass man eben "sicherer" programmieren kann als bei anderen Sprachen - und sogar automatisch auf Korrektheit prüfen.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Deutsche Rentenversicherung Bund, Berlin
  2. STRABAG BRVZ GMBH & CO.KG, Stuttgart
  3. Stadtwerke München GmbH, München
  4. operational services GmbH & Co. KG, Frankfurt am Main, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Acer Predator XN3, 24,5 Zoll, für 299,00€ und Acer KG1, 24 Zoll, für 179,00€)
  2. Nach Gratismonat 5,99€ - jederzeit kündbar
  3. 389,00€ (Bestpreis)
  4. 379,00€ (Bestpreis)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Sicherheitslücken: Microsoft-Parkhäuser ungeschützt im Internet
Sicherheitslücken
Microsoft-Parkhäuser ungeschützt im Internet

Eigentlich sollte die Parkhaussteuerung nicht aus dem Internet erreichbar sein. Doch auf die Parkhäuser am Microsoft-Hauptsitz in Redmond konnten wir problemlos zugreifen. Nicht das einzige Sicherheitsproblem auf dem Parkhaus-Server.
Von Moritz Tremmel

  1. Office 365 Microsoft testet Werbebanner in Wordpad für Windows 10
  2. Application Inspector Microsoft legt Werkzeug zur Code-Analyse offen
  3. Support-Ende Neben Windows 7 ist jetzt auch Server 2008 unsicher

Digitalisierung: Aber das Faxgerät muss bleiben!
Digitalisierung
Aber das Faxgerät muss bleiben!

"Auf digitale Prozesse umstellen" ist leicht gesagt, aber in vielen Firmen ein komplexes Unterfangen. Viele Mitarbeiter und Chefs lieben ihre analogen Arbeitsmethoden und fürchten Veränderungen. Andere wiederum digitalisieren ohne Sinn und Verstand und blasen ihre Prozesse unnötig auf.
Ein Erfahrungsbericht von Marvin Engel

  1. Arbeitswelt SAP-Chef kritisiert fehlende Digitalisierung und Angst
  2. Deutscher Städte- und Gemeindebund "Raus aus der analogen Komfortzone"
  3. Digitalisierungs-Tarifvertrag Regelungen für Erreichbarkeit, Homeoffice und KI kommen

Lovot im Hands-on: Knuddeliger geht ein Roboter kaum
Lovot im Hands-on
Knuddeliger geht ein Roboter kaum

CES 2020 Lovot ist ein Kofferwort aus Love und Robot: Der knuffige japanische Roboter soll positive Emotionen auslösen - und tut das auch. Selten haben wir so oft "Ohhhhhhh!" gehört.
Ein Hands on von Tobias Költzsch

  1. Orcam Hear Die Audiobrille für Hörgeschädigte
  2. Viola angeschaut Cherry präsentiert preiswerten mechanischen Switch
  3. Consumer Electronics Show Die Konzept-Messe

  1. Quartalszahlen: Intel macht Rekord bei Umsatz und Gewinn
    Quartalszahlen
    Intel macht Rekord bei Umsatz und Gewinn

    Allen Lieferschwierigkeiten und Sicherheitslücken zum Trotz: Intel setzte im vierten Quartal 2019 über 20 Milliarden US-Dollar bei fast 7 Milliarden US-Dollar Gewinn um, gerade die Xeons waren stark.

  2. Satellit: SD-Abschaltung der ARD kommt erst nächstes Jahr
    Satellit
    SD-Abschaltung der ARD kommt erst nächstes Jahr

    Obwohl kein Geld mehr dafür bewilligt ist, will die ARD die SD-Abschaltung im Jahr 2020 nicht vollziehen. Sie wird wohl auf das zweite Halbjahr 2021 verschoben.

  3. Disney+: Darth Maul kehrt in Star Wars: The Clone Wars zurück
    Disney+
    Darth Maul kehrt in Star Wars: The Clone Wars zurück

    Die siebte und letzte Staffel der Animationsserie Star Wars: The Clone Wars kommt im Februar. Fans können sich auf Mace Windu, Obi Wan Kenobi, Anakin Skywalker und andere Charaktere freuen. Ein Highlight: das Duell zwischen Ahsoka Taano und Darth Maul.


  1. 22:45

  2. 17:52

  3. 17:30

  4. 17:15

  5. 17:00

  6. 16:50

  7. 16:18

  8. 15:00